I apologize... <C-K> in (:set) nohlsearch, opened the help in the command :nohlsearch, not the option.
Tired I guess... Gonna rest. BTW. found an 'exclude post' option in the: https://groups.google.com/forum/#!topic/vim_use/SDaInEL82nM Does it work? Should I exclude these last 3 messages? best, r. Em quinta-feira, 8 de março de 2018 09:53:32 UTC-3, Renato Fabbri escreveu: > oh, it is an error in the help files: > > > :noh[lsearch] > gives error until :nohls > > > (the same questions hold) > > > On Thu, Mar 8, 2018 at 9:50 AM, Renato Fabbri <[email protected]> wrote: > (screenshot attached.) > > > > option 'noh' not highlighted as expected. > > > > other options related to the > > [''vimSet'', [''vimOption'', ''PreProc'']]' > > highlighting groups while > > noh is only related to > > [''vimSet'']' > > > > Is this information relevant? > > Is this the right place to post this kind > > of 'problem'? > > Is it considered a problem? > > > > best, > > r. > > > > > > Em quarta-feira, 7 de março de 2018 22:16:58 UTC-3, Renato Fabbri escreveu: > > > 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 a topic in the Google > Groups "vim_use" group. > > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/vim_use/SDaInEL82nM/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > > > > > > > > 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.
