> > [...] > > In what context would consecutive whitespace separated identifiers not > represent a single tag?
Wrong thinking on my side. (Tired and severe lack of coffee probably.) > > [...] > > 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. You are right. And if your patch addresses that, even better. - Given your previous comment I also see why the simple test data file wouldn't work. (I suppose the test file could be syntactically changed to fit, perhaps by interspersing spurious "X" characters?) > > <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. :) All these 'space_error' things were probably a remnant of Neville's version; I haven't checked. - To understand the behavior of that feature or your proposed change I'd have to load the newest version and play with it. (I never considered processing trailing space.) Personally I would focus just on the highlighting of the identifiers. > 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. I've no opinion on that, but what you say sounds reasonable. > 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. Sounds sensible what you say. Feel free to change it as you think. :-) > > > 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. Yes, sure, preprocessor directives (and similar) are a different thing. The question I had was whether they need differentiation anyway. > 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. Well, yet I haven't pondered about it. I was basically just having a conservative stance here, as said. - What I was concerned about were primarily the condition-conjunctions that, if I recall correctly, seem to have a different role and handling than the standard conjunctions; they are neither operators nor part of or like the IF-construct keywords. This might make them worthwhile to differentiate them. - Yet I can't say that I would have a strong feeling about that. - If you think it makes sense to (as I understand it) streamline the highlighting let's do it. (If in future we feel it needs differentiation we can open a change request and then re-discuss it in the light of those new experiences or insights.) 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/DU0PR02MB10422A959C7FE107E50D34D94F3202%40DU0PR02MB10422.eurprd02.prod.outlook.com.
