Doug, I noticed an issue but could not sensibly resolve it. - Maybe you have an
idea?
The problem is as follows...
In these testcases
bitswidth
bits width
maxbits
max bits
all but the second one are correctly highlighted as predefined (yellow), where
the
second one is blue (first word) and non-highlighted (second word) respectively.
The rule that should cover the first two entries is
syn match algol68Predefined
"\<\%(\%(long\s*\)\?long\s*\)\?\%(bits\|bytes\|exp\|int\|real\)\s*width\>"
And according to the (later appearing!) rule
syn match algol68Function "\<\%(bits\|whole\|fixed\|float\|real\)\>"
the function 'bits' is highlighted (blue). - For a standalone 'bits' that's as
desired!
So for 'bits width' the first rule seems to be overwritten/invalidated by the
second.
And moving the latter rule above the former will "fix" the observable behavior.
But that's IMO not as it should be.
(Apparently there's no return "longest match" principle between different
rules.)
A cleaner solution might need to formulate some context dependency?
But I'm not familiar enough with Vim's syntax rules to suggest something here.
Do you have an idea for a clean/cleaner solution to fix that?
Thanks!
Janis
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/vim_dev/DU0PR02MB10422086D75D3FB2C22DC2E27F3222%40DU0PR02MB10422.eurprd02.prod.outlook.com.
