Em terça-feira, 27 de fevereiro de 2018 15:08:21 UTC-3, Christian Brabandt escreveu: > On Di, 27 Feb 2018, Renato Fabbri wrote: > > > On Mon, Feb 26, 2018 at 4:06 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...) > > Yes, because the end keyword triggers reindentation. That is mostly a > good thing. If you don't want that, disable indent scripts. > > > > 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. > > I think this is fixed with > https://github.com/vim/vim/releases/tag/v8.0.1544 > > > 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. > > That means, if there is highlighting group that has no Gui attributes, > use the terminal colors and I think that is what the patch mentioned > above does. > > > 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). > > I do not get that one. > > > - 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. > > Neither do I understand that one. What kind of context are you talking > about? > > > - 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. > > Non-default settings are not a reason for after/ files. plugins should > work with whatever setting you have set (which might include giving > error messages). But I don't see how the after/ directory comes into > this one. > > > - 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). > > Why would a plugin directory have a after directory? That is mostly for > the users convenience. If a plugin needs a functionality it can simply > put it in plugin/ > > > If you cloned into opt/, not executing packadd in vimrc might raise errors. > > Not calling packadd should mean the whole directory not added to the > runtime path. That would not raise an error.
if you put : cal PLUGINXDoThat() in after/ but did not execute :pa pluginx, that will function call will raise na error. tx for the other answers, they really helped me get the context. As soon as I have something more substantial, i might post back so the points get clear. For now: https://github.com/ttm/prv (ongoing work) > > > 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) > > Yes that's what plugins nowadays consist of. The times of single plugin > files are over for about 10 years now. > > > Best, > Christian > -- > Wie man sein Kind nicht nennen sollte: > Karl Ender -- -- 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.
