2015-10-27 18:04 GMT+03:00 Christian Brabandt <cbli...@256bit.org>: > Hi Nikolay! > > On Di, 27 Okt 2015, Nikolay Pavlov wrote: >> Somewhere in the Neovim bug tracker I suggested that it would be >> better to do another thing: > > Is there anything you haven't thought about it yet? > >> When syntax file is being loaded >> save user &iskeyword setting then >> at the each :syn statement save :syn-statement-specific &iskeyword >> setting, attached to :syn statement. >> After syntax file was loaded restore user &iskeyword setting. >> >> From your description this is going to work like if all syntax authors >> replaced :setl isk with :syn option iskeyword. But note the >> differences: >> >> 1. No need to change existing syntax files. >> 2. &iskeyword setting is attached to *:syn statement*, not buffer or >> window structure. Note that user &iskeyword setting is not the only >> cause for highlighting breakage: there is also :syn include and files >> included this way may have different &iskeyword setting (:syn include >> should also save/restore &iskeyword thus). > > Yes this is true. But I believe that the 'isk' setting should be > specific to a single language and not to each statement. And I think, > this would really bloat Vims memory footprint and possibly slow down > syntax highlighting. OTOH I don't know, how well my proposal would work > with syn include.
Not much if implemented properly. This is 1. One pointer per synpat_T item. On my system sizeof(synpat_T) == 160, sizeof(void*) == 8: +5%. 2. One additional chartab per one &iskeyword setting switch: 32 bytes. 3. One integer (refcount) per one chartab: 4 bytes. 4. Increase of the binary due to added code: unknown number of bytes. Though nobody counts this. It is not going to bloat much. Also &iskeyword setting in my variant will be specific to the *language* because nobody changes &iskeyword in the middle of the syntax file. In your variant it is *not* specific to the language, it is specific to the *buffer*. And with :syn include buffer may contain more then one language. Also I do not see why my variant should slow down the highlighting more then your variant. (BTW, I expected you to modify `vim_iswordc_*` and places where it is called to accept a pointer to custom chartab and not mess with `memcpy`.) > >> Note that my approach is not fixing syntax highlighting affected by >> user &iskeyword setting. My approach is fixing syntax files, messing >> with my &iskeyword setting. :syn option iskeyword is not going to >> solve this because it is not currently used. And with policies >> “runtime file updates can only be sent by file maintainers” (like if >> they can’t pull in the changes) and “other people commits are too ? to >> merge them into the master” with “squash the world before updating >> runtime files” (so that it is harder to maintain a parrallel branch, >> and there are no explanations “why was this change made” in commit >> messages and “who made this change” in other metadata) this is not >> going to happen ever. > > That is true with many patches however. It works only well, if > contributors do use it. And a lot of syntax files need to be maintained, > if only because the language evolves within times. Problem is not that they need to be maintained. Problem is that your change generates to much hassle and thus is going to be used by almost nobody a long time. > > Best, > Christian > -- > > -- > -- > 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 vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
