Renato Fabbri wrote: > > > Would you call these bugs? > > > > > > 1) > > > vim script (vimL) syntax highlighting highlights on (:only) as an option > > > value, e.g. > > > if a ==# 'banana' > > > on > > > en > > > > Doesn't happen for me. > > > > Thanks. I could not reproduce it either, maybe context dependent > or a previously messy .vim tree. > But I found other things as such (that's why I made this thread and item 1). > Just tested this one: > > if 1==2 > ec 'x' > en (<--- this guy only unindent when I put the d at the end. I write d > and delete it. And abbrev might resolve, but...)
Correct, you need to type "end". Why would you write anything else? > (at the end of the msg is my :version) > > > > > > > 2) > > > termguicolors was (AFAIU) mostly or only for GUI, including the > > > colorscheme gui= guibg= and guibf= settings.... > > > in terminal vim, if you set termguicolors, you loose the > > > SpellBad visual cue, which entail an impaired spell check. > > > One have to execute > > > :hi SpellBad cterm=undercurl > > > to achieve what is probably desired by Vim developers. > > > > That's a tricky one. When 'termguicolors' was introduced the idea was > > to keep using the cterm attributes and only get the colors from guifg > > and guibg. But for this highlight that doesn't work. And I don't see a > > workaround. > > > > We could add the "termgui" attributes, which would then only be used > > when 'termguicolors' is set. I don't like adding another attribute > > though. > > > > Another solution would be to not use the GUI colors if there aren't any. > > Maybe a bit inconsistent, but it would work. > > > > > Why not just add cterm=undercurl to SpellBad's basic settings? Because it's not what we want, only works on a few terminals. > Also, it should be fairly simple to loop though syntax groups > and copy the gui=X to cterm=X > I almost made a one-liner for this, but I don't need it now, > so maybe when I do I post back, but it entails that > the user will get a consistent tgc context, right? No, the color names are different. > i am also not all about a new attribute, but one other value in the > syntax (hi SpellBad cterm=undercurl), at least in this case, > seems valuable from here. > Another idea is an option or flag to make cterm=NONE use cterm={whats X on > gui=X} > > I was not able to follow you on this sentence: > "Another solution would be to not use the GUI colors if there aren't any." > When I try, I touch the void. This was implemented in patch 8.0.1544. So far it works. > > 3) > > > pack/xxx/opt/yyy/after/ > > > are not run after :packadd yyy > > > (which is just tear-jerking) > > > > Was already reported (by you). Still wondering why you would have an > > "after" directory, why not load the script there right away? > > Some reasons which I came across: > - If I am using opt/ (or packs in general) to organize things, load this > and not that, > some after/ commands might be only for stuff x (plugin, workflow, > experiments etc). > - If I want to assure that such commands are executed with as much of the > final context as possible., > but don't fell convenient to make a function with them, and run them > afterwards, nor detach > them from the associated file tree. > - Non-default settings. > I am trying to move away from these after/ files, but they are too > convenient, > so I repeatedly find myself sourcing these after files by hand. > - One might clone a plugin repo (the whole tree) into pack/xx/(start/ or > opt/), > and be happy with loading auto or keeping things lean and > having an easy way to loading it if wanted. > Fantastic weather, but there is a catch: if the tree has an after/ dir, you > keep > the whole tree in opt/ but copy the after files into the working after > (usually .vim/after). > If you cloned into opt/, not executing packadd in vimrc might raise errors. > - Another one: the pack/*/*/*/after are added to rtp, but are not working > as other after/ dirs (actually, I only trust the .vim/after/ dir at the > moment). > > I get that in the manual most often (or always?) a "plugin" is considered > a one file add-on that stays in plugin/. > In practice, as Vimball allows and we all make them, plugins are very often > file trees in the template decribed at :h 'rtp'. > Right? (I am really asking, of course) > > A more explicit ordering of the files sourcing is also something I miss not > understanding still. I made some tests on this with global variables, > but found my way out before grasping the issue well. I don't read a real reason here, only that it's just what you expected to happen. -- NEIL INNES PLAYED: THE FIRST SELF-DESTRUCTIVE MONK, ROBIN'S LEAST FAVORITE MINSTREL, THE PAGE CRUSHED BY A RABBIT, THE OWNER OF A DUCK "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.