Closed GoogleCodeExporter closed 9 years ago
The Korn shell has . in variable names; bash doesn't AFAICT, but sh.vim
anticipates the problem: if you put this in your .vimrc
let g:sh_noisk = 1
"." will no longer be part of keywords.
Regards, John Little
Original comment by John.B.L...@gmail.com
on 8 Apr 2014 at 10:24
Setting g:sh_noisk doesn't seem to affect the syntax highlighting of '.' using
Vim 7.4.236 and syntax/sh.vim version 132.
Regards,
Gary
Original comment by gary....@gmail.com
on 8 Apr 2014 at 3:11
"""
The Korn shell has . in variable names; bash doesn't AFAICT, but sh.vim
anticipates the problem: if you put this in your .vimrc
let g:sh_noisk = 1
"." will no longer be part of keywords.
"""---John.B
It seems to me that the Korn shell is far less common than the Bourne Shell or
the Bourne Again Shell, both of which do not allow '.'. As such, the Korn shell
is the special case, for which something like 'let g:sh_nu_metal = 1' should be
necessary to /add/ '.' to variable names. The default behaviour should not
include '.'.
Original comment by ewtoo...@gmail.com
on 8 Apr 2014 at 6:52
Gary commented:
>Setting g:sh_noisk doesn't seem to affect the syntax highlighting of '.' using
Vim >7.4.236 and syntax/sh.vim version 132.
I tested it carefully, sh.vim 132 and 133. Maybe:
- Changing it after loading sh.vim has no effect, even reloading sh.vim won't work. Did you put the setting in .vimrc?
- g:sh_isk overrides it too, if you have that set it will use that.
- on some colour schemes, the change is subtle.
ewtoo...@gmail.com commented:
...The default behaviour should not include '.'.
I agree; even with ksh a dot is only seen as part of a variable name within a
${...}
construct, in your example $PATH.text is parsed as ${PATH}.text even with ksh.
Note that a syntax colouring file for .sh files IMO is a heroic undertaking,
mind boggling in difficulty for even one flavour of shell script, let alone one
that copes with the old Bourne shell, bash, ksh, dash, ash, and zsh.
Regards, John
Original comment by John.B.L...@gmail.com
on 8 Apr 2014 at 11:11
I tested it two ways: using my standard setup, which includes the setting of
g:sh_noisk in my .vimrc, and the following command, which should eliminate
anything unique to my environment.
vim -N -u NORC -i NONE --cmd 'let &rtp=$VIMRUNTIME' --cmd 'let g:is_bash=1' --cmd 'let g:sh_noisk=1' --cmd 'syntax on' foo.sh
The file foo.sh contained the line
FOO.BAR=hello
I used the command from http://vim.sourceforge.net/tips/tip.php?tip_id=99 to
determine the syntax highlighting under the cursor. Putting the cursor over
the "FOO", the "." and the "BAR" all gave the same result:
hi<shVariable> trans<shVariable> lo<Identifier>
Regards,
Gary
Original comment by gary....@gmail.com
on 9 Apr 2014 at 12:42
Please try syntax/sh.vim v133, available at my website as
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH
I haven't inflicted it on Bram and the broader vim community yet, so I'm still
entertaining feedback on it.
Gary: g:sh_noisk affects whether or not syntax/sh.vim will change isk for that
buffer. When one does a "dw" while atop a foo.bar using ksh, one wants foo.bar
to be deleted, not just the foo or bar. It doesn't affect shVariable
highlighting, as your experiments noted.
ewtoombs: you have a common misperception about the "popularity" of bash vs
ksh; although bash is more common than ksh, posix is largely the same as ksh,
and hence shares (mostly) the same highlighting as does ksh. The posix shell
is also very popular.
Original comment by drc...@campbellfamily.biz
on 9 Apr 2014 at 7:00
Thanks for the new version. With syntax/sh.vim v133, the line "FOO.BAR=hello"
(without the quotes) has only "BAR" highlighted. However, the line
"FOO,BAR=hello" has all of "FOO,BAR" highlighted as shVariable. A bash variable
name cannot contain a comma, either.
Regards,
Gary
Original comment by gary....@gmail.com
on 9 Apr 2014 at 8:10
Thanks, Gary -- I'm not sure why that comma was there, even for the
ksh/posix shells. So, its gone! Well, in v134, anyway.
Original comment by drc...@campbellfamily.biz
on 9 Apr 2014 at 11:34
This problem has been fixed awhile back. Just closing it now.
Original comment by drc...@campbellfamily.biz
on 24 Oct 2014 at 8:05
Original issue reported on code.google.com by
ewtoo...@gmail.com
on 7 Apr 2014 at 7:35