[m-rev.] for review: rewrite of vim syntax file

[Sebastian Godelet]

Hi Paul,

thanks for looking into this so promptly. For what its worth, I've used
my Vim file for a couple of month now so in my opinion the syntax file
is rather stable (of course there is always room for improvement)

On 04/04/2015 21:12, Paul Bone wrote:
 > On Sat, Apr 04, 2015 at 12:52:05PM +0800, Sebastian Godelet wrote:
 >> Hi,
 >>
 >> after trying to improve some aspects of the existing Vim
 >> syntax file provided in the Mercury distribution,
 >> I came to the conclusion that it might be better to do a rewrite
 >> which tries to be as backwards compatible as possible while still
 >> allowing to add features to both the syntax file and the Vim
 >> plugin script.
 >> Do to the size of the diff I attached it rather than inlining it into
 >> the email.
 >
 > This looks really promising. I have some minor questions however since I
 > (and I doubt anyone else on the team) knows this much about vim scripting
 > I cannot review it critically. Therefore I propose to test it out and see
 > how it goes.
 >
 >
 >> - support underlining of local variables within function or
 >> predicate bodies,
 >> which is a feature found in SWI-Prolog. Additionally one can use
 >> <C-K>r and <C-K>R to rename the underlined variable.
 >
 > What does this mean? This sounds like a vim feature that I didn't know
 > existed.
In SWI-Prolog, which uses a version of Emacs, one just has to put the
cursor over a variable and it will mark all local usages.
In vim script, I implemented that as follows:
in plugin/mercury.vim, there is a function s:Highlight_Matching_Variables()
which is invoked by CursorMoved event.
So my code just looks backwards (from current cursor position) for the
approximate matching predicate or function start /^[:a-z']/ and the
terminal /./ then it uses a feature in Vim called 2match to underline
all matches in the range (see s:CreateVariableMatch(variable, start, end).
Since Vim script is a full-fledged programming language, lots of
problems can be solved by using it.
 >
 >> - Different way of supporting transparent comment highlighting, such
 >> that spell checking works only on comments in both fully highlighted
 >> and partially highlighted comments, this works best if comment
 >> markup is enables (see above).
 >> Without this, spell checking would have to be enabled
 >> for Mercury code as well which Vim is not good at.
 >
 > I also want to learn more about this. I might check the manual while I
 > experiment with the new vim files.
Well due to the extensive use of syntax regions which contain the
special @Spell group (which is enabled for comments and strings now,
both in native code and Mercury code),
so in my .vimrc I just have to put:

" Spelling (comes after encoding, to reduce load time, see :help spell)
:setlocal spell spelllang=en_gb " I guess en_au works as well

I will put that information into the vim readme. A current limitation of
the editor itself is that only the first loaded buffer is spell-checked.
I have not yet found a way around that.
 >
 >
 >> diff --git a/vim/ftplugin/mercury.vim b/vim/ftplugin/mercury.vim
 >> index 917e46c..2083d4c 100644
 >> --- a/vim/ftplugin/mercury.vim
 >> +++ b/vim/ftplugin/mercury.vim
 >> @@ -1,6 +1,7 @@
 >> " Vim syntax file
 >> " Language: Mercury
 >> -" Maintainer: Ralph Becket <rafe at cs.mu.oz.au>
 >> +" Maintainer: Mercury Team <mercury at mercurylang.org>
 >> +" Last Change: 2014-07-07
 >> " vim: ts=2 sw=2 et
 >
 > 2015-04-04
 >
 > Feel free to put your name there, it looks like you're the new maintainer
 > and best person to contact if anyone has any questions.
Ok, will do.
 >
 >
 >> if exists("b:did_mercury_ftplugin")
 >> @@ -17,7 +18,7 @@ setlocal 
tags+=$HOME/mercury/tags.library,$HOME/mercury/tags.compiler
 >>
 >> " Handy if you use `:make'.
 >> "
 >> -setlocal makeprg=mmake
 >> +setlocal makeprg="mmake"
 >
 > Should that be mmc --make?
 >
 > mmake is deprecated in favor of mmc --make but mmake is still used to 
build
 > Mercury itself.
Yes you are right, I forgot to change that (I use that in my local test
file already)
 >
 >
I'll create a GitHub pull request once you finished reviewing this, that
is easier than emailing kilobytes of diffs around.

Cheers, Sebastian.