I have some PowerShell cmdlets for which I've created in-code documentation. All works fine except for one thing. If I have a long description for any of the documentation sections I'm splitting it into multiple lines so that it can be easily read from code. However I've noticed that those new line characters are then also represented as new lines in the PowerShell system.
As an example, here's part of the documentation
.PARAMETER MyParam
This parameter has a long documentation that does not fit into single line,
so I'm breaking it down to several lines.
Now once I run Get-Help on a cmdlet that contains this sort of comments I'll get something like.
-MyParam [<SwitchParameter>]
This parameter has a long documentation that does not fit
into single line,
so I'm breaking it down to several lines.
Required? true
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
Notice that the first line gets wrapped correctly, but then the second line (starting with the word so) also starts on a new line.
I could overcome this problem by putting my whole documentation block in one line but that wouldn't be too good for readability point of view.
Is there a way to treat the whole documentation block as it was part of the same text block but have the comments organized into multiple lines at the same time? Any way that I could tell in the documentation that I don't intend to make a new paragraph and I want to continue previous one?
I don't think this is possible apart from preprocessing help strings with external script.
Use word-wrap in your editor and keep everything on the one line. Keep a hotkey accessible for WW so you can quickly switch from one line to block of text when you need to edit it. Some editors (such as vim) are extremely good in navigating wrapped text (basically the same as it is not wrapped).
Related
I'm making a custom .tmLanguage file to highlight the syntax I'm using correctly and generally make coding with it easier. I'm almost done, and I got the autocompletion working using a .sublime-completions file.
There's just one minor flaw I'd like to change. I have a pretty long list of functions, and almost all of them contain an abbreviation of the word 'parameter', PAR. When I start typing that word, the following are all in the list of completions:
PAR command
DEFPAR command
JDATA command (because the description contains PAR)
SPAA command (because there's a P in the command and an A and an R in the description)
What I want is only for the commands that begin with PAR to show up, so from the list above, only the first item.
So, like this:
In other words, I want the completions to show up based on the literal string I'm typing, and only from the trigger part of my completions file, before the \t only.
That completions file looks like this:
Highlighted in orange is what I want my completions list to be based on.
I hope this is understandable. Any help is greatly appreciated.
This is not possible. By design Sublime's autocomplete feature uses fuzzy matching, so if there are a number of options that all contain the same pattern, but you don't quite remember which one you want, you can type the pattern and have all of the options available. The more you type, the smaller the list of possible options becomes. This is a good thing®, otherwise you'd have to remember the exact command you're looking for, which kind of defeats the purpose of autocomplete and code hinting.
Something that has always burned me up in programming, not just VB, is how inefficient it is to make multi-line comments. I'm not exactly a neat freak, but I do like comments to all be about the same length, around 80 characters including leading whitespace. But, to do this, I have to manually control how long the comments are. And the really frustrating part is when the change to only a few words requires an unreasonable amount of work.
I have found many questions on StackOverflow asking about multi-line commenting, but none to actually address this feature.
Wouldn't it make sense to have a commenting feature in VB, Eclipse, etc. to enter a a mini word processing mode mode that would low simple features like word wrap that would format the comment automatically? Is there one available that I'm just missing?
Or am I just being lazy? But, if it is a good idea, how can it be suggested to Microsoft, Eclipse.org, and others.
The only way to do multi-line comments in VB.NET is to do a lot of single line comments.
Really, the only option you have is the single tick (') in front of a line.
You can use Ctrl+K, Ctrl+C and Ctrl+K, Ctrl+U to comment or uncomment selected lines of text. In C# you can use /* ... */ to comment an entire block of code.
Look for more information on Custom Writing
I am trying to convert my documents into vector-space format using doc2mat
On the website, it says I can use my specified text file where words are white-space separated or on multiple lines. So, I use some code similar to this one:
./doc2mat -mystoplist=stopword.txt -skipnumeric mydocuments.txt myvectorspace.txt
However, when I check the output .clabel file, it still has stop words that's in stopword.txt.
I really do not know how to do this. Someone help me out please? Thank you!
There's one important thing I should remember: I should include ALL the unwanted words in my stop list. This is somewhat difficult since there's always some variations available...
For example, if I want to exclude method I add it to my list. However, the resulting vocabulary may also contain method since there are words like methodist, methods, etc. Then doc2mat by default stems these words and I will still get method in the output.
Another thing is to make sure that "-nostop" option must be provided for user-specified stop list.
Powershell supports typing commands in lowercase. However, powershell's tab completion will camelcase all commands, which I personally find difficult to parse visually. Is there any way to let powershell's tab expansion/completion default to all lowercase instead of camelcase?
There's no way to change this preference today, but you can pretty well easily hook into the PowerShell ISE if you like. One thing you could do is grab the text off the editor, split on new-line chars ("`n"), and then iterate over the resulting array to parse out cmdlet names, make them lower-case, and append onto a new script-body. This all sounds fairly complex, but it is actually fairly simple to do. I've got something similar in an alias-resolution add-in I wrote, which can be found at https://github.com/briandrennan/PowerShellISE/blob/Edit/Resolve-ScriptAliases.ps1. Basically, you'd want to create some kind of an index (hash table would work well) that stores commands, and then just call ToLower() on the name, and insert in your script over the previous one. That script has all the bits you need to do what you're trying to do.
So I have some formatting rule to follow, such as :
Space on each side of operator (*, =, +, %, etc)
No space at the end of a line
No more than 80 chars per line
Is there a way to highlight in red line containing formating error?
The eclipse auto-formating tool is no good because either :
It will change to many line (old code not written by me)
or it won't (only my code)
Because I must follow some "colorfull" guideline :
You must change formating error relative to operators in old code but nothing else
Your code must be correctly formated.
Any ideas?
Thanks
You can select which lines of code you want to format. The Eclipse formatting tool doesn't have to run across the entire file. To do this: select the lines you want to format, then press Ctrl-Shift-F.
You could try using the Eclipse Checkstyle Plugin.
You'll need to configure it with just the rules that you need (the default configuration is very strict, so create a new one with just the rules you care about).
This will highlight all lines with formatting issues. I don't think it's possible to ignore old code using the plugin.
Talk to whoever created that coding guideline. It does not make sense in the long run, because editing code in Eclipse will always apply all current formatting rules (which violates that guideline) or none, if you disable the formatter (which leads to you writing bad code).
If there is really no way around that guideline, then you should split your workflow into 2 phases: Reformat all existing code one time to fulfill that operator guideline. You may use any tool you like, even just a regular expression search and replace might be fine.
After that has been done, configure Eclipse to auto-format only changed lines, but always apply all formattings to each changed line. There is no good reason to not re-format the other 75 characters in an existing line of code, if you already touched 5 characters of it.