Re: bugs?

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

Correct, you need to type "end". Why would you write anything else?

> (at the end of the msg is my :version)
>
>
> >
> > > 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.
> >
> >
> Why not just add cterm=undercurl to SpellBad's basic settings?

Because it's not what we want, only works on a few terminals.

> Also, it should be fairly simple to loop though syntax groups
> and copy the gui=X to cterm=X
> I almost made a one-liner for this, but I don't need it now,
> so maybe when I do I post back, but it entails that
> the user will get a consistent tgc context, right?

No, the color names are different.

> i am also not all about a new attribute, but one other value in the
> syntax (hi SpellBad cterm=undercurl), at least in this case,
> seems valuable from here.
> Another idea is an option or flag to make cterm=NONE use cterm={whats X on
> gui=X}
>
> 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.

This was implemented in patch 8.0.1544. So far it works.

> > 3)
> > > pack/xxx/opt/yyy/after/
> > > are not run after :packadd yyy
> > > (which is just tear-jerking)
> >
> > Was already reported (by you). Still wondering why you would have an
> > "after" directory, why not load the script there right away?
>
> 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).
> - 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.
> - 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.
> - 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).
> If you cloned into opt/, not executing packadd in vimrc might raise errors.
> - Another one: the pack/*/*/*/after are added to rtp, but are not working
> as other after/ dirs (actually, I only trust the .vim/after/ dir at the
> moment).
>
> 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)
>
> A more explicit ordering of the files sourcing is also something I miss not
> understanding still. I made some tests on this with global variables,
> but found my way out before grasping the issue well.

I don't read a real reason here, only that it's just what you expected
to happen.

--
NEIL INNES PLAYED: THE FIRST SELF-DESTRUCTIVE MONK, ROBIN'S LEAST FAVORITE
MINSTREL, THE PAGE CRUSHED BY A RABBIT, THE OWNER OF A DUCK
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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