On Sat, 18 Apr 2026 at 00:38, Janis Papanagnou <[email protected]> wrote:
<snip> > > 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. > > With all what I say please keep in mind that I'm not familiar with > the Vim syntax highlighting "programming", so take it with a grain > of salt... > > Below code seems to look for context. If you say it doesn't work > with the columnar data in the test suite then I fear it doesn't > qualify as solution since I think we cannot rule out consecutive > function identifiers (i.e. those without arguments and syntactic > parenthesis, for example) in Algol 68 programs. In what context would consecutive whitespace separated identifiers not represent a single tag? > Pondering about the issue I meanwhile reached the point where I'd > value _correct highlighting in all cases_ as highly desirable. For > that I'd accept the "structuring flaw" and collect all the single > word entities (that appear as prefix before) at top, instrumented > with a comment; so that the implicit "later appearing beats former" > match-rule will address that. - What do you think? It doesn't help because a user-defined tag of, say, `my special newline` will always have `newline` incorrectly highlighted. This doesn't happen with my proposed fix. <snip> > > I've pushed some more commits recently. Can you please check them? > > I'm unsure about what the following changes will do; could you please > explain: > > *algol68_space_errors* trailing white space and spaces before a <Tab> > *algol68_no_trail_space_error* ... but no trailing spaces > *algol68_no_tab_space_error* ... but no spaces before a <Tab> > > I'm asking because Algol 68 is very permissible about tabs and spaces > (even in identifiers), and I wouldn't like restrictions. Sorry, I thought you had added that feature. It just highlights trailing space (at the end of a line) or tabs with unnecessary leading spaces as errors. These are usually considered stylistically undesirable, some people get quite worked up about it. :) The "algol68_no_tabs" variable adds error highlighting for any tabs so if it's to be included I think it should be nested under control of the global "algol68_space_errors" variable as well. If you didn't add these and aren't interested in the feature we could just rip it all out. Personally I think this whitespace error highlighting belongs in a separate plugin that can be conditionally applied to any syntax file rather than added to each of them separately. > > 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. > > Frankly, I'm not sure. (Myself I haven't touched that with my additions.) > > The PreProc seems to describe some "technical semantics". Various things > are marked as those; for example language basics like MODE OP PRIO PROC, > specific extensions that have a slight semantic difference to related > keywords like ANDF ORF ANDTH OREL ANDTHEN ORELSE, and a couple other > additions which I cannot really judge about. > > Programming Algol 68 I'm (personally) used to have the former two groups > (MODE... and ANDF...) differentiated from other Statements/Keywords. > > I'll ponder about that, but for the moment I'd suggest to keep the > existing differentiation. The highlight groups are also semantic and it's a bit of a stretch to consider MODE OP PRIO PROC and boolean operators as preprocessor directives like PRAGMAT. It can be jarring to read if you attach meaning to the highlighting as I do. We have the Operator highlight group for the bold word boolean operators like ANDTHEN but there's not currently enough granularity to assign a definition keyword highlight group as opposed to the more general Statement or Keyword. It looks, as with quite a lot of the file, like it was modelled on the ancient Ruby syntax file but I think it was a mistake there too. <snip> 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/CAJ1uvoCHYofSnuA93np48SDR8fU7AQ4zyTXQiLU5nzdKWccU_g%40mail.gmail.com.
