Not every command in Vim allows you to add end-of-line comments. Sometimes the " is valid as an argument, so it would be ambiguous. However, if you insert a pipe, the command is ended and you can insert a comment. So you can actually achieve reliable end of line comments in vim thusly:
noremap ' ` |" Use single quote as alternate range key
Neat, right? But the syntax/vim.vim file doesn't recognize this as an end of line comment. How do I tell Vim to recognize this syntax?
I found this in syntax/vim.vim:
syn match vimLineComment +^[ \t:]*".*$+ contains=#vimCommentGroup,vimCommentString,vimCommentTitle
I tried adding something like this to my ~/.vimrc, but there is no effect. VimScript is hard. :/
syntax match vimLineComment '|".*$+'
Any ideas?
you cannot use in-line comments for maps
:h map-comments
you will see:
*map-comments*
It is not possible to put a comment after these commands, because the '"'
character is considered to be part of the {lhs} or {rhs}.
I hope this answers your question.
hack
Okay， you may have good reason to do that.
Only define syn match vimLineComment is not enough, you have to overwrite the vimMapRhs syntax. so these two lines will make |"foo bar highlighted as comment:
syn match vimMapRhs '.*\ze|\s*".*'
syn match vimLineComment '|\s*".*$'
this may change the "comment" highlight, but I don't recommend to do it.
Background
vim 7.3 all platforms
vimscript language (used in vim files)
Problem
The vimscript language supports comments, but end of line comments do not always work predictably, because end of line comments can be mistakenly interpreted by vim as part of the command.
Adding end of line comments is problemmatic in vimscript, because it does not work with all commands.
Solutions
1) use the pipe character :help :bar to create a separate Ex command
this is the solution enumerated by #sidewaysmilk
2) simply add the comment below the relevant vimscript command on the next line
3) use the execute command (see :help :execute )
Pitfalls
Solution 1) is a somewhat unconventional use of the pipe (aka :bar)
Not all commands support the pipe character (see e.g. :help :execute)
Solution 2) may not be desirable for the readability of the vimscript, and it does not directly solve the issue in the OP
searching for this feature on the internet is tricky because it turns up links related to comments in general-purpose programming contexts, unrelated to vimscript
See also
Vim help links (enter these directly into vim Cmdline-mode):
:help vim-script-intro | /comments for some commands
:help :bar
:help Command-line-mode
Web links:
https://en.wikipedia.org/wiki/Vimscript
https://duckduckgo.com/?q=vim+vim-script-intro+comments
+1 fot "This is not "neat" at all":
noremap ' ` |" Use single quote as alternate range key
My preference is to use end of line comment (without adding |) where vimL allows.
The pain point is:
It's hard to remember when vimL allows that. (so some people never uses end of line comment in vimL, which may narrow his choice of formating)
Inspired by the OP, we can utilize the syntax highlight. (But I don't know how to implement yet)
Below is some information which seems to be needed:
Relevant lines in the syntax.vim:
/home/linuxbrew/.linuxbrew/Cellar/neovim/0.6.1/share/nvim/runtime/syntax/syntax.vim
syn region vimString start="^\s*\\\z(['"]\)" skip='\\\\\|\\\z1' end="\z1" oneline keepend contains=#vimStringGroup,vimContinue
syn match vimComment excludenl +\s"[^\-:.%#=*].*$+lc=1 contains=#vimCommentGroup,vimCommentString
syn match vimComment +\<endif\s\+".*$+lc=5 contains=#vimCommentGroup,vimCommentString
syn match vimComment +\<else\s\+".*$+lc=4 contains=#vimCommentGroup,vimCommentString
syn region vimCommentString contained oneline start='\S\s\+"'ms=e end='"'
hi def link vimCommentString vimString
" end of line comment
syn match vimLineComment +^[ \t:]*".*$+ contains=#vimCommentGroup,vimCommentString,vimCommentTitle
hi def link vimLineComment vimComment
syn match vim9LineComment +^[ \t:]\+#.*$+ contains=#vimCommentGroup,vimCommentString,vimCommentTitle
hi def link vim9Comment Comment
syn match vimCommentTitle '"\s*\%([sS]:\|\h\w*#\)\=\u\w*\(\s\+\u\w*\)*:'hs=s+1 contained contains=vimCommentTitleLeader,vimTodo,#vimCommentGroup
hi def link vimCommentTitle PreProc
syn match vimCommentTitleLeader '"\s\+'ms=s+1 contained
syn match vimContinue "^\s*\\"
Related
I have recently started studying shell script and I'd like to be able to comment out a set of lines in a shell script. I mean like it is in case of C/Java :
/* comment1
comment2
comment3
*/`
How could I do that?
Use : ' to open and ' to close.
For example:
: '
This is a
very neat comment
in bash
'
Multiline comment in bash
: <<'END_COMMENT'
This is a heredoc (<<) redirected to a NOP command (:).
The single quotes around END_COMMENT are important,
because it disables variable resolving and command resolving
within these lines. Without the single-quotes around END_COMMENT,
the following two $() `` commands would get executed:
$(gibberish command)
`rm -fr mydir`
comment1
comment2
comment3
END_COMMENT
Note: I updated this answer based on comments and other answers, so comments prior to May 22nd 2020 may no longer apply. Also I noticed today that some IDE's like VS Code and PyCharm do not recognize a HEREDOC marker that contains spaces, whereas bash has no problem with it, so I'm updating this answer again.
Bash does not provide a builtin syntax for multi-line comment but there are hacks using existing bash syntax that "happen to work now".
Personally I think the simplest (ie least noisy, least weird, easiest to type, most explicit) is to use a quoted HEREDOC, but make it obvious what you are doing, and use the same HEREDOC marker everywhere:
<<'###BLOCK-COMMENT'
line 1
line 2
line 3
line 4
###BLOCK-COMMENT
Single-quoting the HEREDOC marker avoids some shell parsing side-effects, such as weird subsitutions that would cause crash or output, and even parsing of the marker itself. So the single-quotes give you more freedom on the open-close comment marker.
For example the following uses a triple hash which kind of suggests multi-line comment in bash. This would crash the script if the single quotes were absent. Even if you remove ###, the FOO{} would crash the script (or cause bad substitution to be printed if no set -e) if it weren't for the single quotes:
set -e
<<'###BLOCK-COMMENT'
something something ${FOO{}} something
more comment
###BLOCK-COMMENT
ls
You could of course just use
set -e
<<'###'
something something ${FOO{}} something
more comment
###
ls
but the intent of this is definitely less clear to a reader unfamiliar with this trickery.
Note my original answer used '### BLOCK COMMENT', which is fine if you use vanilla vi/vim but today I noticed that PyCharm and VS Code don't recognize the closing marker if it has spaces.
Nowadays any good editor allows you to press ctrl-/ or similar, to un/comment the selection. Everyone definitely understands this:
# something something ${FOO{}} something
# more comment
# yet another line of comment
although admittedly, this is not nearly as convenient as the block comment above if you want to re-fill your paragraphs.
There are surely other techniques, but there doesn't seem to be a "conventional" way to do it. It would be nice if ###> and ###< could be added to bash to indicate start and end of comment block, seems like it could be pretty straightforward.
After reading the other answers here I came up with the below, which IMHO makes it really clear it's a comment. Especially suitable for in-script usage info:
<< ////
Usage:
This script launches a spaceship to the moon. It's doing so by
leveraging the power of the Fifth Element, AKA Leeloo.
Will only work if you're Bruce Willis or a relative of Milla Jovovich.
////
As a programmer, the sequence of slashes immediately registers in my brain as a comment (even though slashes are normally used for line comments).
Of course, "////" is just a string; the number of slashes in the prefix and the suffix must be equal.
I tried the chosen answer, but found when I ran a shell script having it, the whole thing was getting printed to screen (similar to how jupyter notebooks print out everything in '''xx''' quotes) and there was an error message at end. It wasn't doing anything, but: scary. Then I realised while editing it that single-quotes can span multiple lines. So.. lets just assign the block to a variable.
x='
echo "these lines will all become comments."
echo "just make sure you don_t use single-quotes!"
ls -l
date
'
what's your opinion on this one?
function giveitauniquename()
{
so this is a comment
echo "there's no need to further escape apostrophes/etc if you are commenting your code this way"
the drawback is it will be stored in memory as a function as long as your script runs unless you explicitly unset it
only valid-ish bash allowed inside for instance these would not work without the "pound" signs:
1, for #((
2, this #wouldn't work either
function giveitadifferentuniquename()
{
echo nestable
}
}
Here's how I do multiline comments in bash.
This mechanism has two advantages that I appreciate. One is that comments can be nested. The other is that blocks can be enabled by simply commenting out the initiating line.
#!/bin/bash
# : <<'####.block.A'
echo "foo {" 1>&2
fn data1
echo "foo }" 1>&2
: <<'####.block.B'
fn data2 || exit
exit 1
####.block.B
echo "can't happen" 1>&2
####.block.A
In the example above the "B" block is commented out, but the parts of the "A" block that are not the "B" block are not commented out.
Running that example will produce this output:
foo {
./example: line 5: fn: command not found
foo }
can't happen
Simple solution, not much smart:
Temporarily block a part of a script:
if false; then
while you respect syntax a bit, please
do write here (almost) whatever you want.
but when you are
done # write
fi
A bit sophisticated version:
time_of_debug=false # Let's set this variable at the beginning of a script
if $time_of_debug; then # in a middle of the script
echo I keep this code aside until there is the time of debug!
fi
in plain bash
to comment out
a block of code
i do
:||{
block
of code
}
I found a great answer for how to comment in bash script (by #sunny256):
#!/bin/bash
echo before comment
: <<'END'
bla bla
blurfl
END
echo after comment
The ' and ' around the END delimiter are important, otherwise things inside the block like for example $(command) will be parsed and executed.
This may be ugly, but it works and I'm keen to know what it means. Can anybody explain it simply? I did already find an explanation for : that it is no-op or true. But it does not make sense to me to call no-op or true anyway....
I'm afraid this explanation is less "simple" and more "thorough", but here we go.
The goal of a comment is to be text that is not interpreted or executed as code.
Originally, the UNIX shell did not have a comment syntax per se. It did, however, have the null command : (once an actual binary program on disk, /bin/:), which ignores its arguments and does nothing but indicate successful execution to the calling shell. Effectively, it's a synonym for true that looks like punctuation instead of a word, so you could put a line like this in your script:
: This is a comment
It's not quite a traditional comment; it's still an actual command that the shell executes. But since the command doesn't do anything, surely it's close enough: mission accomplished! Right?
The problem is that the line is still treated as a command beyond simply being run as one. Most importantly, lexical analysis - parameter substitution, word splitting, and such - still takes place on those destined-to-be-ignored arguments. Such processing means you run the risk of a syntax error in a "comment" crashing your whole script:
: Now let's see what happens next
echo "Hello, world!"
#=> hello.sh: line 1: unexpected EOF while looking for matching `''
That problem led to the introduction of a genuine comment syntax: the now-familiar # (which was first introduced in the C shell created at BSD). Everything from # to the end of the line is completely ignored by the shell, so you can put anything you like there without worrying about syntactic validity:
# Now let's see what happens next
echo "Hello, world!"
#=> Hello, world!
And that's How The Shell Got Its Comment Syntax.
However, you were looking for a multi-line (block) comment, of the sort introduced by /* (and terminated by */) in C or Java. Unfortunately, the shell simply does not have such a syntax. The normal way to comment out a block of consecutive lines - and the one I recommend - is simply to put a # in front of each one. But that is admittedly not a particularly "multi-line" approach.
Since the shell supports multi-line string-literals, you could just use : with such a string as an argument:
: 'So
this is all
a "comment"
'
But that has all the same problems as single-line :. You could also use backslashes at the end of each line to build a long command line with multiple arguments instead of one long string, but that's even more annoying than putting a # at the front, and more fragile since trailing whitespace breaks the line-continuation.
The solution you found uses what is called a here-document. The syntax some-command <<whatever causes the following lines of text - from the line immediately after the command, up to but not including the next line containing only the text whatever - to be read and fed as standard input to some-command. Here's an alternate shell implementation of "Hello, world" which takes advantage of this feature:
cat <<EOF
Hello, world
EOF
If you replace cat with our old friend :, you'll find that it ignores not only its arguments but also its input: you can feed whatever you want to it, and it will still do nothing (and still indicate that it did that nothing successfully).
However, the contents of a here-document do undergo string processing. So just as with the single-line : comment, the here-document version runs the risk of syntax errors inside what is not meant to be executable code:
#!/bin/sh -e
: <<EOF
(This is a backtick: `)
EOF
echo 'In modern shells, $(...) is preferred over backticks.'
#=> ./demo.sh: line 2: bad substitution: no closing "`" in `
The solution, as seen in the code you found, is to quote the end-of-document "sentinel" (the EOF or END or whatever) on the line introducing the here document (e.g. <<'EOF'). Doing this causes the entire body of the here-document to be treated as literal text - no parameter expansion or other processing occurs. Instead, the text is fed to the command unchanged, just as if it were being read from a file. So, other than a line consisting of nothing but the sentinel, the here-document can contain any characters at all:
#!/bin/sh -e
: <<'EOF'
(This is a backtick: `)
EOF
echo 'In modern shells, $(...) is preferred over backticks.'
#=> In modern shells, $(...) is preferred over backticks.
(It is worth noting that the way you quote the sentinel doesn't matter - you can use <<'EOF', <<E"OF", or even <<EO\F; all have the same result. This is different from the way here-documents work in some other languages, such as Perl and Ruby, where the content is treated differently depending on the way the sentinel is quoted.)
Notwithstanding any of the above, I strongly recommend that you instead just put a # at the front of each line you want to comment out. Any decent code editor will make that operation easy - even plain old vi - and the benefit is that nobody reading your code will have to spend energy figuring out what's going on with something that is, after all, intended to be documentation for their benefit.
It is called a Here Document. It is a code block that lets you send a list of commands to another command or program
The string following the << is the marker determining the end of the block. If you send commands to no-op, nothing happens, which is why you can use it as a comment block.
That's heredoc syntax. It's a way of defining multi-line string literals.
As the answer at your link explains, the single quotes around the END disables interpolation, similar to the way single-quoted strings disable interpolation in regular bash strings.
What character can I use to put comments in an Exuberant Ctags .ctags file?
I would like to add comments with explanations, and perhaps to disable some regexps.
But I can't find any comment character which ctags-exuberant accepts!
I keep getting the warning:
ctags: Warning: Ignoring non-option in /home/joey/.ctags
which is better than an error, but still a little annoying.
I have tried # // /* ... */ and ; as comments, but ctags tries to parse them all!
Here is an example file with some comments which ctags will complain about:
# Add some more rules for Javascript
--langmap=javascript:+.jpp
--regex-javascript=/^[ \t]*var ([a-zA-Z_$][0-9a-zA-Z_$]*).*$/\1/v,variable/
--regex-javascript=/^[ \t]*this\.([a-zA-Z_$][0-9a-zA-Z_$]*)[ \t]*=.*$/\1/e,export/
--regex-javascript=/^[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*):.*$/\1/p,property/
--regex-javascript=/^\<function\>[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*)/\1/f,function/
# Define tags for the Coffeescript language
--langdef=coffee
--langmap=coffee:.coffee
--regex-coffee=/^class #?([a-zA-Z_$][0-9a-zA-Z_$]*)( extends [a-zA-Z_$][0-9a-zA-Z_$]*)?$/\1/c,class/
--regex-coffee=/^[ \t]*(#|this\.)([a-zA-Z_$][0-9a-zA-Z_$]*).*$/\2/e,export/
--regex-coffee=/^[ \t]*#?([a-zA-Z_$][0-9a-zA-Z_$]*):.*[-=]>.*$/\1/f,function/
--regex-coffee=/^[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*)[ \t]+=.*[-=]>.*$/\1/f,function/
--regex-coffee=/^[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*)[ \t]+=[^->\n]*$/\1/v,variable/
--regex-coffee=/^[ \t]*#?([a-zA-Z_$][0-9a-zA-Z_$]*):.*$/\1/p,property/
You can't! I looked through the source code (thanks to apt-get source). There are no checks for lines to ignore. The relevant code is in parseFileOptions() in options.c
But sometimes comments are a neccessity, so as a workaround I put a comment in as a regexp, in such as way that it is unlikely to ever match anything.
--regex-coffee=/^(COMMENT: Disable next line when using prop tag)/\1/X,XXX/
The ^ helps the match to fail quickly, whilst the ( ) wrapper is purely for visual effect.
Your comment should be a valid regexp, to avoid warnings on stderr. (That means unescaped /s must be avoided, and if you use any [ ] ( or )s they should be paired up.) See Tom's solution to avoid these restrictions.
As #joeytwiddle points out, comments are not supported by the parser, but there is a work-around.
Example .ctags file:
--regex-C=/$x/x/x/e/ The ctags parser currently doesn't support comments
--regex-C=/$x/x/x/e/ This is a work-around which works with '/' characters
--regex-C=/$x/x/x/e/ http://stackoverflow.com/questions/10973224/how-to-add-comments-to-an-exuberant-ctags-config-file
--regex-C=/$x/x/x/e/
--regex-C=/$x/x/x/e/ You can add whatever comment text you want here.
You can use '#' as the start of comment if you are using Universal-ctag(https://ctags.io).
Given that comments don't work, what about a .ctags.readme file...
For most things you don't actually need a comment, e.g. you don't really need the comment below.
# Define tags for the Coffeescript language
--langdef=coffee
--langmap=coffee:.coffee
I can see however that you might want to add comments explaining some mind bending regex, so for each line that absolutely needs it you can copy paste it into the .ctags.readme file as a markdown file:
Forgive me father for I have regexed
It was purely because I wanted some lovely coffee properties
```
--regex-coffee=/^[ \t]*#?([a-zA-Z_$][0-9a-zA-Z_$]*):.*$/\1/p,property/
```
Keeping .ctags.readme and .ctags in sync
You could have a block at the bottom of the ctags file separated with a line break, then delete this final block.
If you only have the one line break in your .ctags file this sed will delete all the lines after the line break.
Then do some grepping for the --regex lines to append the lines from .ctags.readme into .ctags.
sed -i '/^\s*$/,$d' .ctags
grep "^--regex" .ctags.readme >> .ctags
I'm having a problem with jumping to a Ruby bang method using Exhuberant Ctags. I have searched for others having a similar problem and am unable to find anything. An example of the problem can be shown using the following small Ruby class:
class Hello
def start
method!
end
def method
# Blah
end
def method!
# Blah
end
end
When ctags -R . is run on this file the resulting tags file contains the following 2 lines demonstrating that both methods are discovered at generation:
method test.rb /^ def method$/;" f class:Hello
method! test.rb /^ def method!$/;" f class:Hello
However, if I place my cursor on the call to method! on line 3 and press ^] then the cursor jumps to the method definition rather than to the correct bang version. It seems as if the exclamation mark is not being included in the identifier that is searched for.
Is there a way to fix this so the correct method is jumped to?
I realize this is super-old, but I ran into the same thing in both Vim 8.0 and Neovim. If I enter :tag mymethod! from vim's command-line, it finds the relevant tag, but if I try <C-]> with my cursor on the method name, it errors E426: tag not found: mymethod (note the lack of ! in the name it searched for).
You can fix this by adding ! to the list of characters recognized as keyword characters in Ruby syntax:
:set iskeyword+=!
You could add this to ~/.vim/after/syntax/ruby.vim to apply it in any Ruby file you open. I haven't tested this though, so can't say whether it will adversely affect anything else. I know it will change word jumping behavior. w will, for instance, treat the ! as part of the "small" word.
On second thought, it will definitely mishandle things like !some_test. If you were to hit <C-]> with the cursor anywhere in there, it would search for a method named !some_test, which is definitely not what you want. A better solution would be to write a wrapper function around the tag lookup for Ruby files. I'm actually working on something for that, so I'll post when I have something that presentable.
Update: I found a surprisingly simple workaround:
nnoremap <buffer><silent> <C-]> :tag <C-R><C-W><CR>
For some reason, the behavior of <C-R><C-W> in command-line mode differs from that of expand('<cword>'), and arguably from the documentation. Even though ! is not an 'iskeyword' character, and expand('<cword>') results in mymethod, <C-R><C-W> results in mymethod!. The same applies to is_this_your_method?. You could apply this workaround by putting the following in ~/.vim/ftplugin/ruby.vim:
nnoremap <buffer><silent> <C-]> :tag <C-R><C-W><CR>
nnoremap <buffer><silent> g] :tselect <C-R><C-W><CR>
nnoremap <buffer><silent> g<C-]> :tjump <C-R><C-W><CR>
Update 2
It turns out the special behavior of <C-R><C-W> was provided by vim-ruby (and included in Vim's runtime files by default). That script customizes <C-R><C-W> and also adds a <Plug><cword> mapping to correctly identify the Ruby cursor identifier. I only ran into the mishandling of ! because I had inadvertently clobbered the mappings already provided by vim-ruby when adding what I find to be more a comfortable keybinding:
nnoremap <C-.> <C-]>
If I'd done nmap instead, vim-ruby's mapping could have done its job. Alternatively, you could leverage what vim-ruby provides by doing (in a ruby ftplugin file):
nnoremap <buffer><silent> <C-]> :<C-U>exe v:count1."tag <Plug><cword>"<CR>
nnoremap <buffer><silent> g] :<C-U>tselect <Plug><cword><CR>
nnoremap <buffer><silent> g<C-]> :<C-U>tjump <Plug><cword><CR>
You can always use :tag:
:tag method!
Or visual mode - if you highlight any text (with v + movement) before you hit ^], it will use the highlighted text as the tag instead of trying to find an 'identifier' under the cursor. So if your cursor is on the m in method!, then
vE^]
should do the trick. If your cursor is elsewhere in the word, then hit b first.
I was using MacVim snapshot 63 at the time I posted this question. I'm now using snapshot 72 and the problem has gone. The only advice I can give here is to upgrade the version of Vim that you are using.
I am writing a shell (bash) script and I'm trying to figure out an easy way to accomplish a simple task.
I have some string in a variable.
I don't know if this is relevant, but it can contain spaces, newlines, because actually this string is the content of a whole text file.
I want to replace the last occurence of a certain substring with something else.
Perhaps I could use a regexp for that, but there are two moments that confuse me:
I need to match from the end, not from the start
the substring that I want to scan for is fixed, not variable.
for truncating at the start: ${var#pattern}
truncating at the end ${var%pattern}
${var/pattern/repl} for general replacement
the patterns are 'filename' style expansion, and the last one can be prefixed with # or % to match only at the start or end (respectively)
it's all in the (long) bash manpage. check the "Parameter Expansion" chapter.
amn expression like this
s/match string here$/new string/
should do the trick - s is for sustitute, / break up the command, and the $ is the end of line marker. You can try this in vi to see if it does what you need.
I would look up the man pages for awk or sed.
Javier's answer is shell specific and won't work in all shells.
The sed answers that MrTelly and epochwolf alluded to are incomplete and should look something like this:
MyString="stuff ttto be edittted"
NewString=`echo $MyString | sed -e 's/\(.*\)ttt\(.*\)/\1xxx\2/'`
The reason this works without having to use the $ to mark the end is that the first '.*' is greedy and will attempt to gather up as much as possible while allowing the rest of the regular expression to be true.
This sed command should work fine in any shell context used.
Usually when I get stuck with Sed I use this page,
http://sed.sourceforge.net/sed1line.txt