I use Sublime Text 3 Plug-in called AlignTab to align my code like this:
Version : 1.4.1
Author : Ken Wheeler
Website : http://kenwheeler.github.io
Docs : http://kenwheeler.github.io/slick
Repo : http://github.com/kenwheeler/slick
Issues : http://github.com/kenwheeler/slick/issues
Now, I want to my texts to stay next to the colon like this:
Version: 1.4.1
Author: Ken Wheeler
Website: http://kenwheeler.github.io
Docs: http://kenwheeler.github.io/slick
Repo: http://github.com/kenwheeler/slick
Issues: http://github.com/kenwheeler/slick/issues
How do I accomplish that ?
You can do this with AlignTab, no need for a different plugin. You just need to use the more advanced regex functionality as described on the GitHub page.
Bring up the Command Palette (Ctrl+Shift+P on Windows or cmd+shift+P on Mac), type in "AlignTab", press enter, and type this in and hit enter:
:/r0clf1
Props to #Hank for including 0 spaces option, didn't even realize he didn't want the space.
Explanation:
the : finds the colon
the / says okay now here come some arguments about what I want you to do with the colon
the r means right-justify the first column
the 0 means 0 spaces after the right column
the c means center the middle column (which is just the colon, so it doesn't do anything)
the l means left-justify the right column
the f1 means only do this for the first match on the line
The AlignTab docs or the linked examples have enough info to cover what you need.
If you highlight the original text, then Cmd + Shift + P (or Ctrl Shift P on windows) and enter AlignTab Live Preview mode, you can enter a regex and use the special rlc syntax.
The syntax is:
\s+:/r0c1l
The regex are \s+ (greater than 1 spaces) to the first :, then r0 (align right, 0 spaces), c1 (center mark with 1 padding to the right), then l (left align the remaining text). There's no need for an 'f1' at the end of the expression since the regex matches the leading spaces before your first colon (per your example).
If you had newly written text without the pre-formatting that you've already done, like:
Version: 1.4.1
Author: Ken Wheeler
Website: http://kenwheeler.github.io
Docs: http://kenwheeler.github.io/slick
Repo: http://github.com/kenwheeler/slick
Issues: http://github.com/kenwheeler/slick/issues
Then to convert to your desired format below, will be:
:/r0c1lf1
Converted below:
Version: 1.4.1
Author: Ken Wheeler
Website: http://kenwheeler.github.io
Docs: http://kenwheeler.github.io/slick
Repo: http://github.com/kenwheeler/slick
Issues: http://github.com/kenwheeler/slick/issues
This result is actually better than your original question text, because there's no leading space.
P.S. I found that the Tablular examples from the AlignTab docs to be slighty more helpful, although it doesn't represent the real implementation of AlignTab.
Related
I'm parsing some nasty files - you know, mix comma, space and tab delimiters in a single line, and then run it through a text editor that word wraps at column 65 with CRLF. Ugh.
As part of my efforts to parse this in Cocoa, I use Apple's whitespaceAndNewlineCharacterSet. But what, exactly is in that set? The documentation says "Unicode General Category Z*, U000A ~ U000D, and U0085". I was able to find the last three (85 is interesting, but what does the ~ mean, and what is General Category Z*?
Any Unicode gurus out there?
The ~ means "thru"; thus, U000A, B, C, and D.
The phrase "General Category Z*" is shorthand for "any character whose General Category property is one of the three categories that start with Z." Thus, various forms of space (0020, 00A0, 1680, 2000 thru 200A, 202F, 205F, 3000), plus the line separator (2028) and the paragraph separator (2029).
NSCharacterSet is an opaque class that does not expose its content easily. You have to see it more as a "membership" rule service than a list of characters.
This may be a somewhat brutal approach, but you can get the list of members in an NSCharacterSet by going through all 16 bit scalar values and checking for membership in the set:
let charSet = NSCharacterSet.whitespaceAndNewlineCharacterSet()
for i in 0..<65536
{
let u:UInt16 = UInt16(i)
if charSet.characterIsMember(u)
{ print("\(u): \(Character(UnicodeScalar(u)))") }
}
This gives surprising results for non-displayable character sets but it can probably answer your question.
When connected to a remote BASH session via SSH (with the terminal type set to vt100), the console command line will soft-wrap when the cursor hits column 80.
What I am trying to discover is if the <space><carriage return> sequence that gets sent at this point is documented anywhere?
For example sending the following string
std::string str = "0123456789" // 1
"0123456789"
"0123456789" // 3
"0123456789"
"0123456789" // 5
"012345678 9"
"0123456789_" // 7
"0123456789"
"0";
gets the following response back from the host (Linux Mint as it happens)
01234567890123456789012345678901234567890123456789012345678<WS><WS><CR>90123456789_01234567890
The behaviour observed is not really part of bash; rather, it is part of the behaviour of the readline library. It doesn't happen if you simply use echo (which is a bash builtin) to output enough text to force an automatic line wrap, nor does it happen if bash produces an error message which is wider than the console. (Try, for example, the command . with an argument of more then 80 characters not corresponding to any existing file.)
So it's not an official "soft-wrap sequence", nor is it part of any standard. Rather, it's a pragmatic solution to one of the many irritating problems related to console display management.
There is an ambiguity in terminal implementation of line wrapping:
The terminal wraps after a character is inserted at the rightmost position.
The terminal wraps just before the next character is sent.
As a result, it is not possible to reliably send a newline after the last column position. If the terminal had already wrapped (option 1 above), then the newline will create an extra blank line. Otherwise (option 2), the following newline will be "eaten".
These days, almost all terminals follow some variant of option 2, which was the behaviour of the DEC VT-100 terminal. In the vocabulary of the terminfo terminal description database, this is called xenl: the "eat-newline-glitch".
There are actually two possible subvariants of option 2. In the one actually implemented by the VT-100 (and xterm), the cursor ends up in an anomalous state at the end of the line; effectively, it is one character position off the screen, so you can still backspace the cursor in the same line. Other historic terminals "ate" the newline, but positioned the cursor at the beginning of the next line anyway, so that a backspace would not be possible. (Unless the terminal has the bw capability.)
This creates a problem for programs which need to accurately keep track of the cursor position, even for apparently simple applications like echoing input. (Obviously, the easiest way to echo input is to let the terminal do that itself, but that precludes being able to implement extra control characters like tab completion.) Suppose the user has entered text right up to the right margin, and then types the backspace character to delete the last character typed. Normally, you could implement a backspace-delete by outputting a cub1 (move left 1) code and then an el (clear to end of line). (It's more complicated if the deletion is in the middle of a line, but the principle is the same.)
However, if the cursor could possibly be at the beginning of the next line, this won't work. If you knew the cursor was at the beginning of the next, you could move up and then to the right before doing the el, but that wouldn't work if the cursor was still on the same line.
Historically, what was considered "correct" was to force the cursor to the next line with a hard return. (Following quote is taken from the file terminfo.src found in the ncurses distribution. I don't know who wrote it or when):
# Note that the <xenl> glitch in vt100 is not quite the same as on the Concept,
# since the cursor is left in a different position while in the
# weird state (concept at beginning of next line, vt100 at end
# of this line) so all versions of vi before 3.7 don't handle
# <xenl> right on vt100. The correct way to handle <xenl> is when
# you output the char in column 80, immediately output CR LF
# and then assume you are in column 1 of the next line. If <xenl>
# is on, am should be on too.
But there is another way to handle the issue which doesn't require you to even know whether the terminal has the xenl "glitch" or not: output a space character, after which the terminal will definitely have line-wrapped, and then return to the leftmost column.
As it turns out, this trick has another benefit if the terminal emulator is xterm (and probably other such emulators), which allows you to select a "word" by double-clicking on it. If the automatic line wrap happens in the middle of a word, it would be ideal if you could still select the entire word even though it is split over two lines. If you follow the suggestion in the terminfo file above, then xterm will (quite reasonably) treat the split word as two words, because they have an explicit newline between them. But if you let the terminal wrap automatically, xterm treats the result as a single word. (It does this despite the output of the space character, presumably because the space character was overwritten.)
In short, the SPCR sequence is not in any way a standardized feature of the VT100 terminal. Rather, it is a pragmatic response to a specific feature of terminal descriptions combined with the observed behaviour of a specific (and common) terminal emulator. Variants of this code can be found in a variety of codebases, and although as far as I know it is not part of any textbook or formal documentation, it is certainly part of terminal-handling folkcraft [note 2].
In the case of readline, you'll find a comment in the code which is much more telegraphic than this answer: [note 1]
/* If we're at the right edge of a terminal that supports xn, we're
ready to wrap around, so do so. This fixes problems with knowing
the exact cursor position and cut-and-paste with certain terminal
emulators. In this calculation, TEMP is the physical screen
position of the cursor. */
(xn is the short form of xenl.)
Notes
The comment is at line 1326 of display.c in the current view of the git repository as I type this answer. In future versions it may be at a different line number, and the provided link will therefore not work. If you notice that it has changed, please feel free to correct the link.
In the original version of this answer, I described this procedure as "part of terminal handling folklore", in which I used the word "folklore" to describe knowledge passed down from programmer to programmer rather than being part of the canon of academic texts and international standards. While "folklore" is often used with a negative connotation, I use it without such prejudice. "lore" (according to wiktionary) refers to "all the facts and traditions about a particular subject that have been accumulated over time through education or experience", and is derived from an Old Germanic word meaning "teach". Folklore is therefore the accumulated education and experience of the "folk", as opposed to the establishment: in Eric S. Raymond's analogy of the Cathedral and the Bazaar, folklore is the knowledge base of the Bazaar.
This usage raised the eyebrows of at least one highly-skilled practitioner, who suggested the use of the word "esoteric" to describe this bit of information about terminal-handling. "Esoteric" (again according to wiktionary) applies to information "intended for or likely to be understood by only a small number of people with a specialized knowledge or interest, or an enlightened inner circle", being derived from the Greek ἐσωτερικός, "inner circle". (In other words, the knowledge of the Cathedral.)
While the semantic discussion is, at least, amusing, I changed the text by using the hopefully less emotionally-charged word "folkcraft".
There is more than one reason for making line-wrapping a special case (and "folklore" seems an inappropriate term):
The xterm FAQ That description of wrapping is odd, say more? is one of many places discussing vt100 line-wrapping.
vim and screen both take care to not use cursor-addressing to avoid the wrapping, since that would interfere with selecting a wrapped line in xterm. Instead (and the sample seems to show bash doing this too) they send a series of printable characters which step across the margin before sending other control sequences which would prevent the line-wrapping flag from being set in xterm. This is noted in xterm's manual page:
Logical words and lines selected by double- or triple-clicking may wrap
across more than one screen line if lines were wrapped by xterm itself
rather than by the application running in the window.
As for "comments in code" - there certainly are, to explain to maintainers what should not be changed. This from Sven Mascheck's XTerm resource file gives a good explanation:
! Wether this works also with _wrapped_ selections, depends on
! - the terminal emulator: Neither MIT X11R5/6 nor Suns openwin xterm
! know about that. Use the 'xfree xterm' or 'rxvt'. Both compile on
! all major platforms.
! - It only works if xterm is wrapping the line itself
! (not always really obvious for the user, though).
! - Among the different vi's, vim actually supports this with a
! clever and little hackish trick (see screen.c):
!
! But before: vim inspects the _name_ of the value of TERM.
! This must be similar to "xterm" (like "xterm-xfree86", which is
! better than "xterm-color", btw, see his FAQ).
! The terminfo entry _itself_ doesn't matter here
! (e.g.: 'xterm' and 'vs100' are the same entry, but with
! the latter it doesn't work).
!
! If vim has to wrap a word, it appends a space at the first part,
! this space will be wrapped by xterm. Going on with writing, vim
! in turn then positions the cursor again at the _beginning_ of this
! next line. Thus, the space is not visible. But xterm now believes
! that the two lines are actually a single one--as xterm _has_ done
! some wrapping also...
The comment which #rici quotes came from the terminfo file which Eric Raymond incorporated from SCO in 1995. The history section of the terminfo source refers to this. Some of the material in that is based on the BSD termcap sources, but differs, as one would notice when comparing the BSD termcap in this section with ncurses. The four paragraphs beginning with the "not quite" are the same (aside from line-wrapping) with the SCO file. Here is a cut/paste from that file:
# # --------------------------------
#
# dec: DEC (DIGITAL EQUIPMENT CORPORATION)
#
# Manufacturer: DEC (DIGITAL EQUIPTMENT CORP.)
# Class: II
#
# Info:
# Note that xenl glitch in vt100 is not quite the same as concept,
# since the cursor is left in a different position while in the
# weird state (concept at beginning of next line, vt100 at end
# of this line) so all versions of vi before 3.7 don't handle
# xenl right on vt100. The correct way to handle xenl is when
# you output the char in column 80, immediately output CR LF
# and then assume you are in column 1 of the next line. If xenl
# is on, am should be on too.
#
# I assume you have smooth scroll off or are at a slow enough baud
# rate that it doesn't matter (1200? or less). Also this assumes
# that you set auto-nl to "on", if you set it off use vt100-nam
# below.
#
# The padding requirements listed here are guesses. It is strongly
# recommended that xon/xoff be enabled, as this is assumed here.
#
# The vt100 uses rs2 and rf rather than is2/tbc/hts because the
# tab settings are in non-volatile memory and don't need to be
# reset upon login. Also setting the number of columns glitches
# the screen annoyingly. You can type "reset" to get them set.
#
# smkx and rmkx, given below, were removed.
# smkx=\E[?1h\E=, rmkx=\E[?1l\E>,
# Somtimes smkx and rmkx are included. This will put the auxilliary keypad in
# dec application mode, which is not appropriate for SCO applications.
vt100|vt100-am|dec vt100 (w/advanced video),
If you compare the two, the ncurses version has angle brackets added around the terminfo capability names, and a minor grammatical change was made in the first sentence. But the author of the comment clearly was not Raymond.
I'm using Sphinx to document a command line utility written in Python. I want to be able to document a command line option, such as --region like this:
**--region** <region_name>
in ReST and then use Sphinx to to generate my HTML and man pages for me.
This works great when generating man pages but in the generated HTML, the -- gets turned into - which is incorrect. I have found that if I change my source ReST document to look like this:
**---region** <region_name>
The HTML generates correctly but now my man pages have --- instead of --. Also incorrect.
I've tried escaping the dashes with a backslash character (e.g. \-\-) but that had no effect.
Any help would be much appreciated.
This is a configuration option in Sphinx that is on by default: the html_use_smartypants option (http://sphinx-doc.org/config.html?highlight=dash#confval-html_use_smartypants).
If you turn off the option, then you will have to use the Unicode character '–' if you want an en-dash.
With
**-\\-region** <region_name>
it should work.
In Sphinx 1.6 html_use_smartypants has been deprecated, and it is no longer necessary to set html_use_smartypants = False in your conf.py or as an argument to sphinx-build. Instead you should use smart_quotes = False.
If you want to use the transformations formerly provided by html_use_smartypants, instead it is recommended to use smart_quotes, e.g., smart_quotes = True.
Note that at the time of this writing Read the Docs pins sphinx==1.5.3, which does not support the smart_quotes option. Until then, you'll need to continue using html_use_smartypants.
EDIT It appears that Sphinx now uses smartquotes instead of docutils smart_quotes. h/t #bad_coder.
To add two dashes, add the following:
.. include:: <isotech.txt>
|minus|\ |minus|\ region
Note the backward-slash and the space. This avoids having a space between the minus signs and the name of the parameter.
You only need to include isotech.txt once per page.
With this solution, you can keep the extension smartypants and write two dashes in every part of the text you need. Not just in option lists or literals.
As commented by #mzjn, the best way to address the original submitter's need is to use Option Lists.
The format is simple: a sequence of lines that start with -, --, + or /, followed by the actual option, (at least) two spaces and then the option's description:
-l long listing
-r reversed sorting
-t sort by time
--all do not ignore entries starting with .
The number of spaces between option and description may vary by line, it just needs to be at least two, which allows for a clear presentation (as above) on the source, as well as on the generated document.
Option Lists have syntax for an option argument as well (just put an additional word or several words enclosed in <> before the two spaces); see the linked page for details.
The other answers on this page targeted the original submitter's question, this one addresses their actual need.
Notepad++ obviously recognizes all comments as such. Is there a way to simply delete all?
Edit: Stat-R's bookmark method has helped greatly, not only for removing comments but for conditionally removing lines in general.
For a general file, first of all you need to know the comment operator of the language you are writing the file in. For example, in java script the comment operator is //.
For the following code...
In NP++, you need to
Mark the lines that contains '//'. Make sure the bookmark option is enabled.
Then, choose from NP++ menu Search>Bookmark>Remove Bookmarked lines
EDIT:
Another solution after #Chris Mirno 's suggestion is as follows:
Use regular expression. See the image below. It is self explanatory
To understand it better, refer to these
In the Find & Replace Dialog, put the following regex and adjust the search options as depicted.
/\*.*?\*/
Replace with: (empty)
Select Mode: Regular Expression AND .(dot) matches newline
This should remove all your C style comments spanned across lines.
Star-R and Chris Mirno Answer are also Correct and Good.
But For Line Comment:
//.*?(?=\r?$)
Explanation:
// will be the Starting Position
.*? Will be any character
(?=\r?$) will search to the end of the line (as it is required in line comment)
Note:
But Still check each of the line because for example if your code contains soap format like
//www.w3.org/2001/XMLSchema-instance\x2......");
it will capture this line because the starting is // and it goes to end of the line so watch out for this :)
Warning to all using Stat-R's solution:
This method will remove lines of code if formatted like this:
echo "hello"; //This comment will be detected
Following his method, the entire line will be removed.
Therefore make sure to go through and make these comments, their own line before doing this method.
I have had some luck running a macro for the above. Basically:
search for // (F3)
select to end of line (shift+end)
delete (delete)
Put // into the search dialog by just searching for it once. Then record the three steps in a macro, then play it back until EOF.
The first time I did it I had a problem, but then it worked, not sure what I did differently.
Anton Largiader's answer was the most reliable one, including complex inline comments.
However, it will leave many empty lines, including ones with empty characters (space, tabs...) so I would just add another step to make it almost perfect:
After running the macro, just do:
Edit > Line Operations > Remove Empty Lines
OR
Edit > Line Operations > Remove Empty Lines (Containing Blank Characters)
1st option is good if you wish to remove only really empty lines
2nd options will remove every empty line even containing space etc. so there will be no more actual spacing left between code blocks. 1st option might be the safest with some manual cleanup afterwards.
As someone suggested in another post, the simplest and most reliable is maybe to export the all text in .RTF format using Menu Plugin-->NppExport-->Export to RTF and then:
-Open the newly created file in Word
-Select any part of any comment
-On the top-right side of Word clic Select--> Select all texts with similar formatting
-Remove the selected comments all at once (del or cut if doesn't work)
To remove Powershell comments if someone find it handy:
Removing Comment in a Powershell using Notepad ++
To find just lines beginning with # (and not with # elsewhere in the line).
Notepad++ SEARCH Menu > Find
‘Mark‘ Tab – fill in as below.
Select ‘Mark All’ (clear all marks if used previously).
Regex ^[#}
enter image description here
SEARCH Menu > bookmark > Remove (or do anything on the list with
them)
Clear all marks to reset
You can select no comments just code by doing the following:
Regex ^[^#}
enter image description here
Enter ctrl+shift+K to remove comment
This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
How do I comment a block of lines in YAML?
YAML supports inline comments, but does not support block comments.
From Wikipedia:
Comments begin with the number sign ( # ), can start anywhere on a line, and continue until the end of the line
A comparison with JSON, also from Wikipedia:
The syntax differences are subtle and seldom arise in practice: JSON allows extended charactersets like UTF-32, YAML requires a space after separators like comma, equals, and colon while JSON does not, and some non-standard implementations of JSON extend the grammar to include Javascript's /* ... */ comments. Handling such edge cases may require light pre-processing of the JSON before parsing as in-line YAML.
# If you want to write
# a block-commented Haiku
# you'll need three pound signs
The specification only describes one way of marking comments:
An explicit comment is marked by a “#” indicator.
That's all. There aren't any block comments.
I am not trying to be smart about it, but if you use Sublime Text for your editor, the steps are:
Select the block
Cmd + / on Mac or Ctrl + / on Linux and Windows
Profit
I'd imagine that other editors have similar functionality too. Which one are you using? I'd be happy to do some digging.
In Vim you can do one of the following:
Comment all lines: :%s/^/#
Comment lines 10 - 15: :10,15s/^/#
Comment line 10 to current line: :10,.s/^/#
Comment line 10 to end: :10,$s/^/#
or using visual block:
Select a multiple-line column after entering visual block via Ctrl+v.
Press r followed by # to comment out the multiple-line block replacing the selection, or Shift+i#Esc to insert comment characters before the selection.
An alternative approach:
If
your YAML structure has well defined fields to be used by your app
AND you may freely add additional fields that won't mess up with your app
then
at any level you may add a new block text field named like "Description" or "Comment" or "Notes" or whatever
Example:
Instead of
# This comment
# is too long
use
Description: >
This comment
is too long
or
Comment: >
This comment is also too long
and newlines survive from parsing!
More advantages:
If the comments become large and complex and have a repeating pattern, you may promote them from plain text blocks to objects
Your app may -in the future- read or update those comments
One way to block commenting in YAML is by using a text editor like Notepad++ to add a # (comment) tag to multiple lines at once.
In Notepad++ you can do that using the "Block Comment" right-click option for selected text.
Emacs has comment-dwim (Do What I Mean) - just select the block and do a:
M-;
It's a toggle - use it to comment AND uncomment blocks.
If you don't have yaml-mode installed you will need to tell Emacs to use the hash character (#).
If you are using Eclipse with the YEdit plugin (an editor for .yaml files), you can comment-out multiple lines by:
selecting lines to be commented, and then
Ctrl + Shift + C
And to uncomment, follow the same steps.
For RubyMine users on Windows:
Open the file in the editor.
Select the block and press:
Ctrl + /,
And you will have the selected block starting with #.
Now if you want to uncomment the commented block, press the same key combination Ctrl + forward slash again.
In the Azure DevOps browser (pipeline YAML editor),
Ctrl + K + C Comment Block
Ctrl + K + U Uncomment Block
There also a 'Toggle Block Comment' option, but this did not work for me.
There are other 'weird' ways too: Right-click to see 'Command Palette' or F1
Then choose a cursor option.
Now it is just a matter of #.
Or even smarter [Ctrl + K] + [Ctrl + C]
In a .gitlab-ci.yml file, the following works:
To comment out a block (multiline): Select the whole block section >
Ctrl K C
To uncomment already commented out block (multiline): Select the
whole block section > Ctrl K U