ops... email sent only for you... I apologise and am sending to the list as well.
On Tue, Feb 27, 2018 at 3:16 PM, Bram Moolenaar <[email protected]> wrote: > >> >> 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? >> > > because the comand is en[dif] > > >> >> > (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. >> > > Well, that I expected it to happen we agree on. > > But your answer raises many questions here... > Just one: > Why is then opt/x/after/ added to rtp? > > > > >> >> -- >> 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 -- [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 >> /// >> > > > > -- > Renato Fabbri > GNU/Linux User #479299 > labmacambira.sourceforge.net > -- Renato Fabbri GNU/Linux User #479299 labmacambira.sourceforge.net -- -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
