Bug in sync grouphere?
Gustavo Niemeyer
I'm trying to sync up a very simple syntax and being unable to
do so. It feels a bit like a bug, but it's quite possible that I just
misunderstand how it works.
I've nailed down the problem to a very simple example:
syn sync match fooSync grouphere NONE /^foo\>/
syn region fooString start=+"+ end=+"+
hi def link fooString String
Now, put something like this in a file
foo = "
(50 lines)
"
Opening the file at the bottom doesn't sync up properly.
Is this a bug, or do I misunderstand how it works?
Thanks,
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter
Lech Lorens
> Greetings,
>
> I'm trying to sync up a very simple syntax and being unable to
> do so. It feels a bit like a bug, but it's quite possible that I just
> misunderstand how it works.
>
> I've nailed down the problem to a very simple example:
>
> syn sync match fooSync grouphere NONE /^foo\>/
> syn region fooString start=+"+ end=+"+
> hi def link fooString String
>
> Now, put something like this in a file
>
> foo = "
> (50 lines)
> "
>
> Opening the file at the bottom doesn't sync up properly.
>
> Is this a bug, or do I misunderstand how it works?
Have a look at help for:
:syn-sync
You might want to add ":syn sync fromstart" to an file type plugin.
--
Cheers,
Lech
Gustavo Niemeyer
> :syn-sync
>
> You might want to add ":syn sync fromstart" to an file type plugin.
Thanks for the suggestion, but that's of course already been done way
before posting the bug report here, and fromstart is not an option.
The code looks correct, but I'm probably missing some detail there.
Gustavo Niemeyer
Charles Campbell
> Greetings,
>
> I'm trying to sync up a very simple syntax and being unable to
> do so. It feels a bit like a bug, but it's quite possible that I just
> misunderstand how it works.
>
> I've nailed down the problem to a very simple example:
>
> syn sync match fooSync grouphere NONE /^foo\>/
> syn region fooString start=+"+ end=+"+
> hi def link fooString String
>
> Now, put something like this in a file
>
> foo = "
> (50 lines)
> "
>
> Opening the file at the bottom doesn't sync up properly.
>
> Is this a bug, or do I misunderstand how it works?
>
> Thanks,
>
>
syn on
syn clear
syn region fooString start=+"+ end=+"+
syn sync match fooSync grouphere NONE /^foo\>/
hi def link fooString String
Regards,
Chip Campbell
Gustavo Niemeyer
Sorry, but I don't understand what you mean. You've provided exactly
the same syntax logic I did, but reordered, and your version continues
to expose the same bug.
Benjamin R. Haskell
> (Charles Campbell wrote:)
>> Perhaps the following will be of interest:
>>
>> syn on
>> syn clear
>>
>> [ed. followed by your original :syn/:hi commands]
>
> Sorry, but I don't understand what you mean. You've provided exactly
> the same syntax logic I did, but reordered, and your version continues
> to expose the same bug.
How are you testing this?
I have a file identical to what you've provided for your syntax:
===> /tmp/test-vim-syntax.vim <===
syn sync match fooSync grouphere NONE /^foo\>/
syn region fooString start=+"+ end=+"+
hi def link fooString String
==================================
And a sample file:
===> /tmp/foo.txt <===
foo = "
asdf (<-- this line repeated 50 times)
"
======================
Then, running:
vim -u NONE -i NONE -N +'so /tmp/test-vim-syntax.vim' + ~/tmp/foo.txt
The double quotes aren't colorized.
Running:
vim -u NONE -i NONE -N +'syn on' +'syn clear' +'so /tmp/test-vim-syntax.vim' + ~/tmp/foo.txt
They are.
You'll have to be more precise about your set up to reproduce the "bug".
In the other thread, I don't understand why you think ':help syn-sync'
isn't applicable. If your sync settings are such that 50 lines is too
many to sync across, it's not going to work. E.g. Adding:
+'syn sync minlines=10 maxlines=30' to my working example above:
vim -u NONE -i NONE -N +'syn on' +'syn clear' +'syn sync minlines=10 maxlines=30' +'so /tmp/test-vim-syntax.vim' + ~/tmp/foo.txt
the colors are wrong, as explained in ':help syn-sync'
See:
:help :syn-sync-second
and
:help :syn-sync-third
for more.
--
Best,
Ben
Gustavo Niemeyer
> How are you testing this?
>
> I have a file identical to what you've provided for your syntax:
(...)
> The double quotes aren't colorized.
It is not the double quotes that should be colorized, it is the string
itself. This is a *region*. Open the file in the beginning to see the
proper syntax highlighting.
> Running:
>
> vim -u NONE -i NONE -N +'syn on' +'syn clear' +'so /tmp/test-vim-syntax.vim'
> + ~/tmp/foo.txt
>
> They are.
Yes, but the string is not.
> You'll have to be more precise about your set up to reproduce the "bug".
Your steps above work as a reproducer.
> In the other thread, I don't understand why you think ':help syn-sync' isn't
> applicable. If your sync settings are such that 50 lines is too many to
I didn't say it wasn't applicable. The documentation is awesome. I said
I already have read it entirely long ago.
Charles Campbell
>> Perhaps the following will be of interest:
>>
> Sorry, but I don't understand what you mean. You've provided exactly
> the same syntax logic I did, but reordered, and your version continues
> to expose the same bug.
>
>
and the "..." are all highlighted as String. That's with the cursor at
the top of the file. If one repeats this with the cursor at the bottom
of the file, then just the ' " ' is highlighted as String, which is
expected (see :help syn-sync-minlines).
I re-ordered it because, in my experimentation, I gave it "fooString"
instead of NONE, and the highlighting syntax needed to be defined before
the sync.
It also needed to have syntax highlighting turned on, and the syn clear
was needed to get a clean start at every sourcing; your example had
neither the syntax on nor the syn clear.
Chip Campbell
Gustavo Niemeyer
> then just the ' " ' is highlighted as String, which is expected (see :help
> syn-sync-minlines).
No, it's not expected. Let's read the help together:
"""
If the "minlines={N}" argument is given, the parsing always starts at least
that many lines backwards. This can be used if the parsing may take a few
lines before it's correct, or when it's not possible to use syncing.
"""
There's no use in this case. You can set it to 0, and it should work.
> It also needed to have syntax highlighting turned on, and the syn clear was
> needed to get a clean start at every sourcing; your example had neither the
> syntax on nor the syn clear.
Yes, I assumed I was talking to the developers of vim, which don't
need explanations about the basics of syntax highlighting.
Lech Lorens
[...]
> > It also needed to have syntax highlighting turned on, and the syn clear was
> > needed to get a clean start at every sourcing; your example had neither the
> > syntax on nor the syn clear.
>
> Yes, I assumed I was talking to the developers of vim, which don't
> need explanations about the basics of syntax highlighting.
I must admit that for someone who's just joined the list you seem pretty
arrogant.
First of all you are talking to people who sacrifice their precious time
to help you. And you neither bothered to prepare an easily reproducible
test case, nor to explain clearly what your problem was (have a look
here: http://llorens.visualserver.org/vim.png).
Here's your answer:
#v+
syn region fooString start=+"+ end=+"+
syn sync match fooSync grouphere fooString /^foo\>/
hi def link fooString String
#v-
Good luck with getting further help! You might need it.
--
Cheers,
Lech
Gustavo Niemeyer
> arrogant.
I'm fine with people calling me an arrogant for no reason and crying
about investing their time on me, but first they must provide some
kind of useful information Lech. ;-)
> Here's your answer:
Your answer is incorrect, since you're forcefully defining a highlighting
group to exist in a moment when it doesn't. Here is the documentation:
Define a match that is used for syncing. {group-name} is the
name of a syntax group that follows just after the match. Parsing
of the text for highlighting starts just after the match.
In the provided file, the match group is *not* in effect right after /foo\>/.
It is only in effect after the region starts, so NONE is the appropriate
value there.
If you want to observe the problem in practice, change your example
file to this:
foo = "oops"
asdf
asdf
...
asdf
"
Then observe the highlighting at the top, and at the bottom while your
syntax definition is in effect.
Note that, while explaining that to you, I haven't offended you in any
way, nor am I crying about my time, which in fact is being spent here
to help an open source project to sync their file type syntax properly.
> Good luck with getting further help! You might need it.
Thanks! I'm also wishing for better luck. :-)
Gustavo Niemeyer
For lack of luck, below is a patch to fix the bug.
The problem is caused by the fact that the syncing processes the line
til the end, so the second call to sync_finish_line() refuses to
process it again (current_finished == TRUE).
Sorry for the trouble.
--- syntax.c 2011-01-26 20:08:25.620861002 -0200
+++ syntax.c.orig 2011-01-26 20:07:44.710861007 -0200
@@ -927,8 +927,6 @@
update_si_end(cur_si, (int)current_col, TRUE);
check_keepend();
}
- // Must restart the line to process highlighting now.
- syn_start_line();
current_col = found_m_endpos.col;
current_lnum = found_m_endpos.lnum;
(void)syn_finish_line(FALSE);
Gustavo Niemeyer
> - syn_start_line();
Sorry, the patch is reversed.
Bram Moolenaar
Gustavo Niemeyer wrote:
> For lack of luck, below is a patch to fix the bug.
>
> The problem is caused by the fact that the syncing processes the line
> til the end, so the second call to sync_finish_line() refuses to
> process it again (current_finished == TRUE).
>
> Sorry for the trouble.
>
> --- syntax.c 2011-01-26 20:08:25.620861002 -0200
> +++ syntax.c.orig 2011-01-26 20:07:44.710861007 -0200
> @@ -927,8 +927,6 @@
> update_si_end(cur_si, (int)current_col, TRUE);
> check_keepend();
> }
> - // Must restart the line to process highlighting now.
> - syn_start_line();
> current_col = found_m_endpos.col;
> current_lnum = found_m_endpos.lnum;
> (void)syn_finish_line(FALSE);
That doesn't look like the right solution, since it restarts from the
start of the line instead of using the column from the match.
You say that current_finished is set. I wonder where it gets set.
If it's not set correctly that should be fixed. Otherwise perhaps this
flag needs to be reset.
--
hundred-and-one symptoms of being an internet addict:
155. You forget to eat because you're too busy surfing the net.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Gustavo Niemeyer
> That doesn't look like the right solution, since it restarts from the
> start of the line instead of using the column from the match.
It feels like the right thing to do, since even though the line was
already being processed, it's fully processed with a different goal.
> You say that current_finished is set. I wonder where it gets set.
> If it's not set correctly that should be fixed. Otherwise perhaps this
> flag needs to be reset.
It gets set due to the call of syn_finish_line for synchronization
in the same function right above:
had_sync_point = syn_finish_line(TRUE);
Replacing syn_start_line() with these bits of it also fixes the bug:
current_finished = FALSE;
next_match_idx = -1;
Is there a reason not to simply call syn_start_line() with the goal
of restarting the syntax highlighting processing, though, and then
changing the column to advance until the sync match ends? It felt
like a slightly cleaner solution to me, but both approaches work
to fix the bug.
Gustavo Niemeyer
approaches reasonable or is there anything else to be investigated?
Bram Moolenaar
Gustavo Niemeyer wrote:
> Bram, have you had a moment to ponder about this issue? Is one of the
> approaches reasonable or is there anything else to be investigated?
It's in the todo list, I'll look into it when I get to it.
--
Did you ever see a "Hit any key to continue" message in a music piece?
Gustavo Niemeyer
>> approaches reasonable or is there anything else to be investigated?
>
> It's in the todo list, I'll look into it when I get to it.
Awesome, thank you.
Gustavo Niemeyer
about this fix.