On Thu, 16 Apr 2026 at 22:13, Janis Papanagnou <[email protected]> wrote: > > >> (Apparently there's no return "longest match" principle between different > >> rules.) > > > Latest match wins, by design. See :help :syn-priority > > Yeah, I feared so. > > Would it be a sensible request to ask for a vim-syntax change here? > (I'm aware that this could cause not only severe efforts but might also > have undesired influences on existing syntax files, unless it's an option > that could be chosen/activated in parallel.)
Right, it would have to be another match type and I'm not sure how much capability it would add beyond organisational convenience for matches of predictable length. One can always ask. :) > >> [ context dependency? ] > > > Unfortunately there are no simple tag boundaries with whitespace as > > taggle separators so changing the priorities will only get us so far. [...] > > Okay. - And I see the hassles and suboptimal workarounds. - So I'd > think that we better accept (for the moment) the infelicities with > that handful of tokens that produce inappropriate highlighting in > the special case of using spaces here. I had a look at some real code and the errors are quite common and obvious, even in the small Genie test suite. I think the following would fix it but I may be overlooking some contexts. Note this won't work with the current test file because of the column layout. 181c181 < syn match algol68Function "\<\%(\%(\%(long\s*\)\?long\s*\)\|[qd]\)\?\%(sqrt\|cbrt\|curt\|exp\|ln\|log\)\>" --- > syn match algol68Function > "\%([a-z0-9]\s\+\)\@8<!\<\%(\%(\%(long\s*\)\?long\s*\)\|[qd]\)\?\%(sqrt\|cbrt\|curt\|exp\|ln\|log\)\>\%(\s\+[a-z0-9]\)\@!" 228c228 < syn match algol68Function "\<\%(bits\|whole\|fixed\|float\|real\)\>" --- > syn match algol68Function > "\%([a-z0-9]\s\+\)\@8<!\<\%(bits\|whole\|fixed\|float\|real\)\>\%(\s\+[a-z0-9]\)\@!" <snip> > How could Algol 68's files syntax highlighting be parameterized to > accept various stopping regimes. (I'm not sure but seem to recall > that the GNU Algol 68 project has also an '.a68' file extension but > uses a different stropping as default.) A solution might get tricky? I think we'd probably need a combination of config variables to specify the compiler (for prelude highlighting) and the different stropping regimes. > > 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". > > Frankly, I cannot tell what that means. It's a remnant from Neville's > original version. - Personally I think the term is misleading, given > that all the matches are included in that section, and that there's > not only the "traditional" features supported but also the features > imported from those third-party libraries and all Genie extensions. I've renamed it to "algol68_no_preludes" for now. We could offer an "algol68_preludes" that takes an array of values in the future to make this more granular. > I think a subsequent "0.5" release (that might cover more stropping > regimes or not) could also be cleaned up by more strictly separating > the various feature sets, if possible by technical means (if-sections). > > > I think I've merged all your latest changes. > > Thanks! - When do you think will the Algol 68 support be available in > the repository for public use? I've pushed some more commits recently. Can you please check them? I think that the declarators using PreProc for highlighting should probably just use Statement/Keyword. Are you attached to that? This isn't a blocker, just something I noticed. The only other issue is the "algol68_no_tabs" feature. If we want to keep that it should be folded into the "algol68_space_errors" config. Regards, 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/CAJ1uvoB3b11Yppnaro8Hbdfi5XwuKP_8i0qtYttWuoPcU3EbLw%40mail.gmail.com.
