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

Numeric less than or equal op begins quoting construct #1

Closed
0racle opened this Issue Sep 8, 2016 · 10 comments

Comments

Projects
None yet
3 participants
@0racle
Copy link
Contributor

0racle commented Sep 8, 2016

Description of issue

When using the Numeric less than or equal to operator, the < causes the syntax highlighter to start a <> quoting construct until it sees a >.

Screenshot of the issue:

Screenshot

Above screenshot taken using the 256-color jellybeans color scheme.

Sample code:

if 3 <= 4 {
    say "It now thinks we are inside a '<>' quoting construct";
}

# And will continue to do so until > appears;

if 4 >= 3 { 
    say "No such problem here";
}

Link to vimrc

vimrc

Output of vim --version

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 21 2015 12:30:04)
Included patches: 1-712
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by buildd@
Huge version without 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      -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
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        +mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: gcc   -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim        -lm -ltinfo -lnsl  -lselinux  -lacl -lattr -lgpm -ldl    -L/usr/lib/python2.7/config-i386-linux-gnu -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions   
@hoelzro

This comment has been minimized.

Copy link
Member

hoelzro commented Sep 8, 2016

@0racle Thanks for the report! Which version of the vim-perl6 files are you using? I'm not seeing this on my setup (version e858f8f).

@0racle

This comment has been minimized.

Copy link
Contributor Author

0racle commented Sep 9, 2016

I'm on the same commit. I've also tried on another box (one Ubuntu, one Centos, both Vim7.4) and it is also exhibiting the same issue.

@0racle

This comment has been minimized.

Copy link
Contributor Author

0racle commented Sep 12, 2016

I used git bisect and found that ab2351f is when this issue started for me.

Further narrowing down to the offending line... If I roll back just line 363 in syntax/perl6.vim the problem goes away.

I then attempted minor changes to the line to see what would fix it and found that I can resolve my issue by making the following change

\ start="[<+~=!]\@1<!<\%(\s\|<\|=>\|\%([=-]\{1,2}>\|[=-]\{2}\)\)\@!"       BAD
\ start="[<+~=!]\@1<!<\%(\s\|<\|=>\|\%([=-]\{1,2}>\|[=-]\{1,2}\)\)\@!"     GOOD

but that causes a regression of how the following line highlights...

if < a b c > { ... }
@hoelzro

This comment has been minimized.

Copy link
Member

hoelzro commented Sep 12, 2016

@0racle Does this happen with no vimrc loaded? Ex. vim -u NONE -c 'source syntax/perl6.vim' -c 'syntax on' -c 'setf perl6' example.pl

I tried this after building Vim 7.4 from patch 712 (git checkout v7.4.712 && ./configure --with-features=huge && make install), and am still unable to reproduce the problem.

@0racle

This comment has been minimized.

Copy link
Contributor Author

0racle commented Sep 13, 2016

If I do the following...
vim -u NONE -c 'source syntax/perl6.vim' -c 'syntax on' -c 'setf perl6' example.pl

I don't see an issue... _but_ it looks identical if I do this
vim -u NONE -c 'syntax on' -c 'setf perl6' example.pl

which suggests the syntax file is not being sourced correctly.

However, if I copy syntax/perl6.vim to ~.vim/syntax and then do the second command, then I do see the issue.

Interestingly, if I delete the perl.vim and perl6.vim files from vim's default runtime folder (/usr/share/vim/.../syntax) and then run the first command, I get no syntax highlighting... further providing support that sourcing the syntax file via the cmdline doesn't work (at least on my machine).

I will clone the vim repo and build the same version as you (on Ubuntu and Centos) and do some more testing.

@hoelzro

This comment has been minimized.

Copy link
Member

hoelzro commented Sep 13, 2016

@0racle Ok, that's leading me to believe that your Vim is using an out-of-date perl6.vim file. The first command (with source syntax/perl6.vim) makes sure that only our perl6.vim is loaded. If you try vim -u NONE -c 'syntax on' -c 'setf perl6' example.pl, run :scriptnames in the vim instance that comes up. You should see an entry for syntax/perl6.vim, which is the syntax file your vim is using. If this is not the one you intend, you either don't have &runtimepath set up correctly, or our syntax/perl6.vim isn't on your runtimepath.

@zostay

This comment has been minimized.

Copy link

zostay commented Jun 1, 2017

I am seeing this problem using the latest commit here cloned into my dotfiles: ccef6a3

The attached screenshots show the problem both in vim and neovim (running reasonably recent builds of each o macOS. This was running each with vim -u NONE -c 'syntax on' -c 'setf perl6' example.pl where example.pl is a module I'm porting. I ran :source syntax/perl6.vim in each and then captured the output of :scriptnames.

Here's neovim:

screen shot 2017-05-31 at 22 25 57

And here's vim:

screen shot 2017-05-31 at 22 26 55

@zostay

This comment has been minimized.

Copy link

zostay commented Jun 1, 2017

I can confirm that the reversion @0racle found via bisect does fix the problem with the mentioned regression.

@0racle

This comment has been minimized.

Copy link
Contributor Author

0racle commented Aug 25, 2017

Here's an asciinema from my system showing the issue with no vimrc.

This issue was also called out by Evan Miller in his recent Review of Perl6

Referring the line I mentioned above from commit ab2351f, making the suggested change (adding 2 characters) does not appear to cause a regression with the issue that commit sought to solve (ie. Fix highlighting of <-a -b -c>).

The regression it cause with regards to if < a b c > ... is, I think, a more acceptable corner case, as it is not likely to be a common expression. Importantly, for < a b c > ... is unaffected by this change and highlights properly.

Given that the issue has been confirmed on multiple systems, and the high visibility of the issue due to Evan's review, I have created a pull request to merge this change.

@hoelzro

This comment has been minimized.

Copy link
Member

hoelzro commented Aug 31, 2017

Thanks for the fix @0racle - I just merged your PR!

@hoelzro hoelzro closed this Aug 31, 2017

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