bugs?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

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 -- [hidden email] -- 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

Renato Fabbri
On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <[hidden email]> 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 -- [hidden email] -- 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           '


--
Renato Fabbri
GNU/Linux User #479299

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

Christian Brabandt

On Di, 27 Feb 2018, Renato Fabbri wrote:

> On Mon, Feb 26, 2018 at 4:06 PM, Bram Moolenaar <[hidden email]> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

Bram Moolenaar
In reply to this post by Renato Fabbri

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 -- [hidden email] -- 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

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 <[hidden email]> 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]
 

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

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 -- [hidden email] -- 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



--
Renato Fabbri
GNU/Linux User #479299

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

Renato Fabbri
In reply to this post by Christian Brabandt
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 <[hidden email]> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

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.

Em quarta-feira, 7 de março de 2018 22:16:58 UTC-3, Renato Fabbri  escreveu:

> 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 <[hidden email]> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

Screenshot from 2018-03-08 09-41-50.png (146K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

Renato Fabbri
oh, it is an error in the help files:

:noh[lsearch]
gives error until :nohls

(the same questions hold)

On Thu, Mar 8, 2018 at 9:50 AM, Renato Fabbri <[hidden email]> 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'']'

Is this information relevant?
Is this the right place to post this kind
of 'problem'?
Is it considered a problem?

best,
r.

Em quarta-feira, 7 de março de 2018 22:16:58 UTC-3, Renato Fabbri  escreveu:
> 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 <[hidden email]> 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 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Renato Fabbri
GNU/Linux User #479299

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

Christian Brabandt
In reply to this post by Renato Fabbri

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

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: bugs?

Renato Fabbri
In reply to this post by 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)
>
>
> On Thu, Mar 8, 2018 at 9:50 AM, Renato Fabbri <[hidden email]> 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'']'
>
>
>
> Is this information relevant?
>
> Is this the right place to post this kind
>
> of 'problem'?
>
> Is it considered a problem?
>
>
>
> best,
>
> r.
>
>
>
>
>
> Em quarta-feira, 7 de março de 2018 22:16:58 UTC-3, Renato Fabbri  escreveu:
>
> > 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 <[hidden email]> 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 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 [hidden email].
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
> Renato Fabbri
> GNU/Linux User #479299
> labmacambira.sourceforge.net
--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.