Charles Campbell wrote: > Thilo Six wrote: > > Hello > > > >>>> ,----[ :h syn-pattern ]--------------------- > >>>> Syntax patterns are always interpreted like the 'magic' option is set, > >>>> no matter what the actual value of 'magic' is. And the patterns are > >>>> interpreted like the 'l' flag is not included in 'cpoptions'. This > >>>> was done to make syntax files portable and independent of 'compatible' > >>>> and 'magic' settings. > >>>> `--------------------------------------------- > >>>> > > -- <snip> -- > > > > > >>> Test: > >>> :new > >>> :put = \"abc\tdef\" > >>> :set cpo+=l > >>> :syn match Test /c[\t]d/ > >>> :hi link Test StatusLine > >>> " I can see highlighted text > >>> /c[\t]d > >>> E486: Pattern not found: c[\t]d > >>> > >>> > > -- <snip> -- > > > > ,----[ src/syntax.c ]----------------------- > > > > /* Make 'cpoptions' empty, to avoid the 'l' flag */ > > cpo_save = p_cpo; > > p_cpo = (char_u *)""; > > ci->sp_prog = vim_regcomp(ci->sp_pattern, RE_MAGIC); > > p_cpo = cpo_save; > > > > `--------------------------------------------- > > > > Bram i do not speak any C but to me it seems that something like this > > should be > > doable without great afford to cover all runtime files, too. > > IIRC when we have discussed this topic here last year it had been suggested > > to > > use a function to fix it once for all. Can't something like this be used to > > a > > broader scope, too? > > > > > The exceptions for syntax files are (without having tested) likely to > apply to the user's syntax files, too ($HOME/.vim/syntax, etc). > Applying this exception to plugins would, for consistency, also apply to > user-written plugins, and so vim would not behave in the manner to which > some users are accustomed. Also, making such a change might break > user-written, personal plugins. > > What I'd like to see is something akin to > > vimstatepush() > vimstdstate() > (optional plugin author state modifications (settings) here) > vimstatepop() > > The problem here is when a plugin does something (like return, exit on > error, etc) and doesn't do the vimstatepop(). Thus, vimstatepush() and > vimstatepop() could be done automatically by vim (instead of explicitly > by plugin authors).
There is a big difference between behavior depending on the command and depdinging on how the command was invoked. The last one quickly becomes unpredictable, e.g., when definign autocommands. > And, while I'm at it: I'd like beval to be a local rather than global. That's an implementation problem. -- Despite the cost of living, have you noticed how it remains so popular? /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- 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
