Re: bugs?

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 <renato.fabbri@gmail.com> 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 <Bram@moolenaar.net> 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 vim_use+unsubscribe@googlegroups.com.
>
> 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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.