On Wed, 15 Apr 2026 at 11:37, Janis Papanagnou <[email protected]> wrote: > > 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.)
Latest match wins, by design. See :help :syn-priority > 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? Unfortunately there are no simple tag boundaries with whitespace as taggle separators so changing the priorities will only get us so far. The best solution, as you suggest, is to try and match the grammar by :syn-contain-ing tags and using a combination of :syn-nextgroup and pattern look-aheads. As I'm sure you're aware, these highlighted groups also wreak havoc with user defined tags, e.g., clear bits. SUPPER stropping avoids this so things will be simpler there. I'd like to eventually support all stropping regimes so that even the ancient code can at least be read comfortably even if none of the modern compilers support it. However, it appears this file was only ever intended to support Genie's default UPPER stropping so I think it's fine to just target that for now. It would be nice if we could fully support ga68 for the release of GCC 16 but I suspect we're out of time. What exactly is the "algol68_traditional" variable attempting to achieve? I assume the "traditional" refers to the highlighting and not the language? If so, that would normally be called something like "algol68_prelude". I think I've merged all your latest changes. Thanks, Doug -- -- 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/CAJ1uvoDAvzptPzFR5fejsUaVNbNior_R0Ssicu8%2BoVYKrDMANw%40mail.gmail.com.
