Re: bugs?

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.

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