Em terça-feira, 27 de fevereiro de 2018 15:08:21 UTC-3, Christian Brabandt
> On Di, 27 Feb 2018, Renato Fabbri wrote:
> > On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <b...@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
> > 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
> > - 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:
> > 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.
> 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.