> > >> [ 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.
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. 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? > 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. If you think it's possible to achieve in principle that's good news! :-) I also think it might not be as bulky as I initially imagined since most of the identifiers are exempt from stropping; it's mainly only the keywords of the language and the operators I think, a comparable small data-set. (It would be perfect if an implicit heuristic could determine the used stropping variant, or an optional modelines argument for example like 'syntax=algol68(upper)', but I'm probably expecting too much.) > > 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. > 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 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. Is this related to my "space-error" question above? - Yet I'm unable to recognize the implications. Thanks! Regards, 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/DU0PR02MB104229E73D5CD9EFE5BED86FBF3202%40DU0PR02MB10422.eurprd02.prod.outlook.com.
