Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ft=sh highlighting thinks . is a valid character in variable names. #215

Closed
GoogleCodeExporter opened this issue Aug 18, 2015 · 9 comments
Closed

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
0. Start vim without a configuration:
$ vim -u NONE test.sh
1. :set ft=sh
2. :syntax on
3. insert the following:
echo "$PATH.text"
echo "$PATH/text"

What is the expected output?
.text and /text should be the same colour.

What do you see instead?
.text is the same colour as PATH, incorrectly suggesting the variable name is 
PATH.text, when it is not. Just run
$ sh test.sh
if you are unsure yourself. If the variable name was PATH.text, the first line 
in the script would only write a newline to stdout.

What version of the product are you using? On what operating system?
7.4.214-1 on archlinux x86_64. (-1 is the archlinux package release number.)

Please provide any additional information below.
$ vim --version
returns
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 24 2014 19:36:05)
Included patches: 1-214
Compiled by Arch Linux
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
+balloon_eval    +float           +mouse_urxvt     -tag_any_white
+browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      +toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  +lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      +X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      -sniff           +xsmp_interact
+eval            +mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        +mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread 
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
-I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz  
-D_FORTIFY_SOURCE=2  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector 
--param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector 
-rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE  
-Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o 
vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo 
-lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 
-lfontconfig -lfreetype  -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm 
-lncurses -lelf -lnsl   -lacl -lattr -lgpm -ldl  -L/usr/lib -llua -Wl,-E 
-Wl,-rpath,/usr/lib/perl5/core_perl/CORE 
-Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -L/usr/local/lib  
-L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread 
-lc -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker 
-export-dynamic   -lruby -lpthread -lgmp -ldl -lcrypt -lm  -L/usr/lib   

Original issue reported on code.google.com by ewtoo...@gmail.com on 7 Apr 2014 at 7:35

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

"""
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

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

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

@GoogleCodeExporter
Copy link
Author

This problem has been fixed awhile back.  Just closing it now.

Original comment by drc...@campbellfamily.biz on 24 Oct 2014 at 8:05

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant