bugs?

[Renato Fabbri]

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

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.

3)

pack/xxx/opt/yyy/after/

are not run after :packadd yyy

(which is just tear-jerking)

--

Renato Fabbri

GNU/Linux User #479299

labmacambira.sourceforge.net

[Bram Moolenaar]

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.

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

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

--
My Go, this amn keyboar oesn't have a .

/// Bram Moolenaar -- Br...@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 ///

[Renato Fabbri]

On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <Br...@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...)

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

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?

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.

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

Thank you for your reply and time.

 

--
My Go, this amn keyboar oesn't have a .

 /// Bram Moolenaar -- Br...@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    ///

=====
my :version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Feb 24 2018 10:17:16)

Included patches: 1-1532

Compiled by renato@xps

Huge version with GTK2 GUI.  Features included (+) or not (-):

+acl               +comments          +file_in_path      +linebreak         +mouse_urxvt       +quickfix          +terminal          +windows

+arabic            +conceal           +find_in_path      +lispindent        +mouse_xterm       +reltime           +terminfo          +writebackup

+autocmd           +cryptv            +float             +listcmds          +multi_byte        +rightleft         +termresponse      +X11

-autoservername    +cscope            +folding           +localmap          +multi_lang        -ruby              +textobjects       -xfontset

+balloon_eval      +cursorbind        -footer            -lua               -mzscheme          +scrollbind        +timers            +xim

+balloon_eval_term +cursorshape       +fork()            +menu              +netbeans_intg     +signs             +title             -xpm

+browse            +dialog_con_gui    +gettext           +mksession         +num64             +smartindent       +toolbar           +xsmp_interact

++builtin_terms    +diff              -hangul_input      +modify_fname      +packages          +startuptime       +user_commands     +xterm_clipboard

+byte_offset       +digraphs          +iconv             +mouse             +path_extra        +statusline        +vertsplit         -xterm_save

+channel           +dnd               +insert_expand     +mouseshape        -perl              -sun_workshop      +virtualedit       

+cindent           -ebcdic            +job               +mouse_dec         +persistent_undo   +syntax            +visual            

+clientserver      +emacs_tags        +jumplist          -mouse_gpm         +postscript        +tag_binary        +visualextra       

+clipboard         +eval              +keymap            -mouse_jsbterm     +printer           +tag_old_static    +viminfo           

+cmdline_compl     +ex_extra          +lambda            +mouse_netterm     +profile           -tag_any_white     +vreplace          

+cmdline_hist      +extra_search      +langmap           +mouse_sgr         +python/dyn        -tcl               +wildignore        

+cmdline_info      +farsi             +libcall           -mouse_sysmouse    +python3/dyn       +termguicolors     +wildmenu          

   system vimrc file: "$VIM/vimrc"

     user vimrc file: "$HOME/.vimrc"

 2nd user vimrc file: "~/.vim/vimrc"

      user exrc file: "$HOME/.exrc"

  system gvimrc file: "$VIM/gvimrc"

    user gvimrc file: "$HOME/.gvimrc"

2nd user gvimrc file: "~/.vim/gvimrc"

       defaults file: "$VIMRUNTIME/defaults.vim"

    system menu file: "$VIMRUNTIME/menu.vim"

  fall-back for $VIM: "/usr/local/share/vim"

Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2   -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       

Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl    -ldl           '

[Christian Brabandt]

On Di, 27 Feb 2018, Renato Fabbri wrote:

> On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <Br...@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

[Bram Moolenaar]

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.

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

[Renato Fabbri]

ops... email sent only for you... I apologise and am sending to the list as well.

On Tue, Feb 27, 2018 at 3:16 PM, Bram Moolenaar <Br...@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...)

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

because the comand is en[dif]

Well, that I expected it to happen we agree on.

But your answer raises many questions here...

Just one:

Why is then opt/x/after/ added to rtp?

 

--
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 -- Br...@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    ///

--

Renato Fabbri

GNU/Linux User #479299

labmacambira.sourceforge.net

[Renato Fabbri]

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)

[Renato Fabbri]

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

[Renato Fabbri]

oh, it is an error in the help files:

:noh[lsearch]

gives error until :nohls

(the same questions hold)

--
--
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 a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/SDaInEL82nM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Brabandt]

On Do, 08 Mär 2018, Renato Fabbri wrote:

> (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'']'

:noh is the command. The option is called `:set nohls`


Best,
Christian
--
Wahrheitsliebe zeigt sich darin, dass man überall das Gute zu
finden und zu schätzen weiß.
-- Goethe, Maximen und Reflektionen, Nr. 56

[Renato Fabbri]

I apologize...

<C-K> in (:set) nohlsearch, opened the
help in the command :nohlsearch, not the
option.

Tired I guess... Gonna rest.

BTW. found an 'exclude post' option in the:
https://groups.google.com/forum/#!topic/vim_use/SDaInEL82nM
Does it work? Should I exclude these last 3 messages?

best,
r.

Em quinta-feira, 8 de março de 2018 09:53:32 UTC-3, Renato Fabbri escreveu:
> oh, it is an error in the help files:
>
>
> :noh[lsearch]
> gives error until :nohls
>
>
> (the same questions hold)
>
>

> To unsubscribe from this group and all its topics, send an email to vim_use+u...@googlegroups.com.