Re: bugs?

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.