Re: bugs?

(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 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.