[m-rev.] for review: rewrite of vim syntax file
sebastian.godelet at outlook.com
Sun Apr 5 12:20:41 AEST 2015
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:
>> 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
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
> 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
>> " 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
> Mercury itself.
Yes you are right, I forgot to change that (I use that in my local test
I'll create a GitHub pull request once you finished reviewing this, that
is easier than emailing kilobytes of diffs around.
More information about the reviews