Hi all,
I have updated the grep.vim plugin to use the new asynchronous
features in Vim 8.0. Now the grep commands are run in the
background and the results are added to the quickfix list.
I have also updated the plugin to integrate ripgrep, ack and ag
search tools.
You can download the plugin from:
https://github.com/yegappan/grep
Let me know if you any see issues with these new features.
Thanks,
Yegappan
--
--
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.
Tuesday, February 27, 2018
Re: bugs?
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 <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...)
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.
I don't read a real reason here, only that it's just what you expected
> > 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.
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 -- 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.
Re: Just another little note of "woah, vim already does that"
On Tue, Feb 27, 2018 at 10:34 AM, Tim Chase <vim@tim.thechases.com> wrote:
I've got a rather large source file for an ETL process containing
several functions (one for each of the files it processes). There's
enough similarity between the file processing that it's easy to do a
search and end up in the wrong function without noticing.
Knowing vim supported matching/colorizing based on line-numbers, I
started out with
:match Error /\%<50l\|\%>120l/
to match anything outside the function I was focused on. But as I'd
edit, those boundaries would change. So I start grumbling, wishing
that vim supported similar functionality for marks instead of
absolute line numbers. BUT HO! It DOES!
So I dropped mark "a" at the beginning of my function, dropped mark
"b" at the end of my function, issued
:match Error /\%<'a\|\%>'b/
and lo, it updates automatically, highlighting the regions outside
the current function. And when I move to the next function, I drop
the "this is the beginning" and "this is the end" marks, and it
updates.
It continues to delight me that vim still holds new/undiscovered
tricks, even after using vim for ~18yrs now.
Anyways, thought I'd share in case it was useful for anybody else.
Very true, vim always amazes me. The learning is always there which keeps
it ever interesting.
As for the above issue, "folds" are good too.
- goto just before start of function and: zfgg
- after end of function: zfG
To prevent search from opening folds:
:set foldopen-=search
For running commands that skips closed folds
:foldd {cmd}
Regards,
-Arun
--
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.
Just another little note of "woah, vim already does that"
I've got a rather large source file for an ETL process containing
several functions (one for each of the files it processes). There's
enough similarity between the file processing that it's easy to do a
search and end up in the wrong function without noticing.
Knowing vim supported matching/colorizing based on line-numbers, I
started out with
:match Error /\%<50l\|\%>120l/
to match anything outside the function I was focused on. But as I'd
edit, those boundaries would change. So I start grumbling, wishing
that vim supported similar functionality for marks instead of
absolute line numbers. BUT HO! It DOES!
So I dropped mark "a" at the beginning of my function, dropped mark
"b" at the end of my function, issued
:match Error /\%<'a\|\%>'b/
and lo, it updates automatically, highlighting the regions outside
the current function. And when I move to the next function, I drop
the "this is the beginning" and "this is the end" marks, and it
updates.
It continues to delight me that vim still holds new/undiscovered
tricks, even after using vim for ~18yrs now.
Anyways, thought I'd share in case it was useful for anybody else.
-tim
--
--
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.
several functions (one for each of the files it processes). There's
enough similarity between the file processing that it's easy to do a
search and end up in the wrong function without noticing.
Knowing vim supported matching/colorizing based on line-numbers, I
started out with
:match Error /\%<50l\|\%>120l/
to match anything outside the function I was focused on. But as I'd
edit, those boundaries would change. So I start grumbling, wishing
that vim supported similar functionality for marks instead of
absolute line numbers. BUT HO! It DOES!
So I dropped mark "a" at the beginning of my function, dropped mark
"b" at the end of my function, issued
:match Error /\%<'a\|\%>'b/
and lo, it updates automatically, highlighting the regions outside
the current function. And when I move to the next function, I drop
the "this is the beginning" and "this is the end" marks, and it
updates.
It continues to delight me that vim still holds new/undiscovered
tricks, even after using vim for ~18yrs now.
Anyways, thought I'd share in case it was useful for anybody else.
-tim
--
--
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.
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.
> > > 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.
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.
> 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.
Re: bugs?
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...)
(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 -- 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 ///
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 '
--
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.
Prevent the use of italic
Hello, all
I am using GVim with a font that has no italic sub-
set. When I edit markdown (.md) files, however, Vim
tries to render *emphasized* text as italic. How
can I prevent that? Is it configured in a color
file or a syntax file?
--
Please, do not forward replies to the list to my e-mail.
--
--
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.
I am using GVim with a font that has no italic sub-
set. When I edit markdown (.md) files, however, Vim
tries to render *emphasized* text as italic. How
can I prevent that? Is it configured in a color
file or a syntax file?
--
Please, do not forward replies to the list to my e-mail.
--
--
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.
Monday, February 26, 2018
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.
> 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 -- 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.
> 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 -- 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.
Re: making custom key names for mappings
On Mon, Feb 26, 2018 at 5:04 AM, Nikolay Aleksandrovich Pavlov <zyx.vim@gmail.com> wrote:
I know what mappings this will result in. I do not understand how this2018-02-26 4:20 GMT+03:00 Renato Fabbri <renato.fabbri@gmail.com>:
> Em sexta-feira, 23 de fevereiro de 2018 15:51:35 UTC-3, ZyX escreveu:
>> 2018-02-23 18:21 GMT+03:00 Renato Fabbri:
>> > Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX escreveu:
>> >> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
>> >> > Well, from your comments, i put a:
>> >> >
>> >> > let g:aall = mapleader
>> >> > " let mapleader = '<Space>'
>> >> > if exists("g:aa_leader")
>> >> > let mapleader = g:aa_leader
>> >> > el
>> >> > let mapleader = 'anything'
>> >> > en
>> >> >
>> >> >
>> >> > before the mappings, and a:
>> >> >
>> >> > let mapleader = g:aall
>> >> >
>> >> > after them and it is all ok.
>> >> > (only these mappings use the
>> >> > temporarily defined leader key.)
>> >> >
>> >> > I did not understand how SourcePre
>> >> > would be used.
>> >> > Something like:
>> >> > au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', mapleader]
>> >> >
>> >> > in combination with a somewhat SourcePost event to
>> >> > set mapleader to fooleader?
>> >>
>> >> No, you set mapleader for *all* scripts, either to default or to
>> >> something else. There is no SourcePost for some reason; an alternative
>> >> is messing with SourceCmd, but this is harder to do right in general,
>> >> but easier to use for specific use cases.
>> >
>> > hum... try this:
>> > let mapleader = 'a'
>> > nn <leader>j :ec 'a banana'<CR>
>> > let mapleader = 'b'
>> > nn <leader>j :ec 'an apple'<CR>
>> > let mapleader = 'a'
>> > nn <leader>k :ec 'an orange'<CR>
>> >
>> > which work 100% fine here.
>>
>> I do not understand what you are trying to say. I know that `<leader>`
>> is expanded only once, but that is not helpful: SourcePre is run only
>> before some script, so if your script is not the last one you have to
>> create SourcePre command which will set mapleader to one value for
>> your script and to another value for everything else.
>
> so that I understand what you are saying
> (I apologize if being slow),
> does this sequence of commands
> have the expected behavior in your Vim:
>
> " {{{ should make aj ec banana, bj ec apple, ak ec orange, bk not mapped:
> let mapleader = 'a'
> nn <leader>j :ec 'a banana'<CR>
> let mapleader = 'b'
> nn <leader>j :ec 'an apple'<CR>
> let mapleader = 'a'
> nn <leader>k :ec 'an orange'<CR>
> " }}}
sequence is *relevant* to the discussion.
>
>>
>> > ((
>> > :version
>> > VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan 6 2018 23:48:57)
>> > Included patches: 1-1428
>> > Compiled by renato@xps
>> > Huge version without GUI.
>> > )) + python 2-3 and termguicolors
>> >
>> >
>> >>
>> >> >
>> >> > Anyway, I understood that it is not needed to define
>> >> > extra <XXX> key names, but is it possible within Vim standard
>> >> > capabilities?
>> >>
>> >> What is possible? All XXX in `<XXX>` are defined at compile time only,
>> >> you can't evaluate expression inside XXX or something like this.
>> >
>> > Ok, so question closed here.
>> > Notice that <XXX> is surely not completely
>> > defined in compile time, for we use
>> > g:mapleader to set <leader> at run time.
>> >
>> > Am I following things right?
>>
>> You cannot change semantics of `<Leader>` or e.g. evaluate `mapleader`
>> as an expression, so this fact is not helpful. And you also can't add
>> any new keys. So "not completely" is not very helpful.
>
> exe g:mapleader
> evaluates mapleader as an expression, but I don't see the case to do this.
:let g:mapleader = '(expand("<sfile>") =~# ''\mmyscript\.vim$''?"a":"b"')'
will not make `<Leader>` expand to `a` for `myscript.vim` and `b` for
everything else.
Now, that is a piece of work. (thanks)
Well, if ec apple orage example above works,
this should work as well (seems you are not agreeing that it works).
(such line have to be on the file where the mappings are defined,
and it has to be called myscript.vim, but thats that).
And now I better see the point in the SourcePre stuff you where talking about,
the hack shout work by parsing expand("%:p").
I am using a similar solution (less file and autocommand dependent)
that you helped me develop in this thread.
It is working (perfectly smooth).
The plugins each have the mappings with
individual leader and localleader and it is like heaven.
I should post back when things are sane again
(much restructuring on my .vim tree because of many reasons
beyond leader keys).
>
> let mapleader += 'banana'
> should work to add new keys, but I again fail to see the point.
Neither there is a way to create `<banana>` key in runtime.
>
> "not completely" there is in the sense of being dependent also on
> the scripts/commands parsed at runtime, not at compile time.
> Apologies for not being palpable.
>
>>
>> >
>> >>
>> >> >
>> >> >
>> >> > Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX escreveu:
>> >> >> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
>> >> >> > leader and localleader are the standard, so one might
>> >> >> > have conflicts between scripts because
>> >> >> > all of them use leader and localleader.
>> >> >> >
>> >> >> > how would you define, say
>> >> >> > <coolleader>, which you set to the
>> >> >> > leader by default,
>> >> >> > but can be changed to any key
>> >> >> > sequence (including c-v derived).
>> >> >> >
>> >> >> > ==
>> >> >> > ideally, I would have a command mkKeyName with which to define
>> >> >> > <coolleader> such as
>> >> >> >
>> >> >> > :mkKeyName -default=leader coolleader
>> >> >> >
>> >> >> > and might set it to anything such as
>> >> >> > se mapcoolleader=^[
>> >> >> > se mapcoolleader=
>> >> >> > se mapcoolleader!
>> >> >> > se mapcoolleader!=<Space>
>> >> >> >
>> >> >> > (this implies that one would also able to use
>> >> >> > :setlocal mapcoolleader ??
>> >> >> >
>> >> >> > and use it in your mappings
>> >> >> > as in
>> >> >> > nnoremap <coolleader>B :call MyCoolFunction()<CR>
>> >> >>
>> >> >> This is not needed, there is `:execute` as something requiring changes
>> >> >> to plugin code. E.g. my plugins (on my frawor framework) allow
>> >> >> defining plugin-specific leader.
>> >> >>
>> >> >> To override `mapleader` for plugins which are not nice enough to allow
>> >> >> defining plugin-specific leader there is SourcePre event.
>> >> >>
>> >> >> I personally find mapleader and maplocalleader as quite *incomplete*
>> >> >> thing. For plugins much better idea would be key-value store: e.g. in
>> >> >> place of
>> >> >>
>> >> >> nnoremap <Plug>(FooPluginDoBar) :call foo#bar()<CR>
>> >> >> nnoremap <Plug>(FooPluginDoZab) :call foo#zab()<CR>
>> >> >>
>> >> >> nmap <Leader>fb <Plug>(FooPluginDoBar)
>> >> >> nmap <Leader>fz <Plug>(FooPluginDoZab)
>> >> >>
>> >> >> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write just
>> >> >>
>> >> >> mapdefineprefix FooPlugin <Leader>f
>> >> >> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()<CR>
>> >> >> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()<CR>
>> >> >>
>> >> >> and Vim will handle actually substituting values like this: each
>> >> >> `<:prefix:mapname(default)>` expands into a concat of two strings:
>> >> >>
>> >> >> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to `prefix`.
>> >> >> 2. The rhs of the first `:mapdefine` command or the `default` value if
>> >> >> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
>> >> >> issued. Inside `default` `<>` are good as long as they are balanced,
>> >> >> various special characters like `)` may be entered via something like
>> >> >> `<Char-41>`.
>> >> >>
>> >> >> In both cases using bang clears the prefix, so next non-banged command
>> >> >> will define it (normally it is ignored).
>> >> >>
>> >> >> E.g. in this case if user wants mappings of foo plugin start with `,o`
>> >> >> and not `<Leader>f` all he needs would be putting
>> >> >>
>> >> >> mapdefineprefix FooPlugin ,o
>> >> >>
>> >> >> into the vimrc (requirement: before sourcing actual plugin). If
>> >> >> additionally he thinks that `DoZab` command is easier to run with
>> >> >> `,oo` he would need
>> >> >>
>> >> >> mapdefine FooPlugin:DoZab o
>> >> >>
>> >> >> (requirement is the same).
>> >> >>
>> >> >> Currently plugins may do this on top of `:execute`, but nobody
>> >> >> bothers. I normally want this functionality to e.g. make NERDCommenter
>> >> >> mappings all start with `,c` (no, redefining `<Leader>` for all
>> >> >> plugins does not sound like a good idea; `SourcePre` is useful, but
>> >> >> still feels like a hack) or "undefine" (i.e. prefix with something you
>> >> >> would never type, e.g. `<Plug>XXXIWouldNeverTypeThisXXX`) mappings for
>> >> >> plugins I install for functionality other then mappings (not everybody
>> >> >> is nice enough to have g:NERDCreateDefaultMappings setting).
>> >> >>
>> >> >> >
>> >> >> > thanks again,
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > 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 vim_use+unsubscribe@googlegroups.com .
>> >> >> > For more options, visit https://groups.google.com/d/optout .
>> >> >
>> >> > --
>> >> > --
>> >> > 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 .
>> >
>> > --
>> > --
>> > 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 .
>
> --
> --
> 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 .
--
--
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/Y5hhjayfaUM/ .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 .
--
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.
Re: making custom key names for mappings
2018-02-26 4:20 GMT+03:00 Renato Fabbri <renato.fabbri@gmail.com>:
> Em sexta-feira, 23 de fevereiro de 2018 15:51:35 UTC-3, ZyX escreveu:
>> 2018-02-23 18:21 GMT+03:00 Renato Fabbri:
>> > Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX escreveu:
>> >> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
>> >> > Well, from your comments, i put a:
>> >> >
>> >> > let g:aall = mapleader
>> >> > " let mapleader = '<Space>'
>> >> > if exists("g:aa_leader")
>> >> > let mapleader = g:aa_leader
>> >> > el
>> >> > let mapleader = 'anything'
>> >> > en
>> >> >
>> >> >
>> >> > before the mappings, and a:
>> >> >
>> >> > let mapleader = g:aall
>> >> >
>> >> > after them and it is all ok.
>> >> > (only these mappings use the
>> >> > temporarily defined leader key.)
>> >> >
>> >> > I did not understand how SourcePre
>> >> > would be used.
>> >> > Something like:
>> >> > au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', mapleader]
>> >> >
>> >> > in combination with a somewhat SourcePost event to
>> >> > set mapleader to fooleader?
>> >>
>> >> No, you set mapleader for *all* scripts, either to default or to
>> >> something else. There is no SourcePost for some reason; an alternative
>> >> is messing with SourceCmd, but this is harder to do right in general,
>> >> but easier to use for specific use cases.
>> >
>> > hum... try this:
>> > let mapleader = 'a'
>> > nn <leader>j :ec 'a banana'<CR>
>> > let mapleader = 'b'
>> > nn <leader>j :ec 'an apple'<CR>
>> > let mapleader = 'a'
>> > nn <leader>k :ec 'an orange'<CR>
>> >
>> > which work 100% fine here.
>>
>> I do not understand what you are trying to say. I know that `<leader>`
>> is expanded only once, but that is not helpful: SourcePre is run only
>> before some script, so if your script is not the last one you have to
>> create SourcePre command which will set mapleader to one value for
>> your script and to another value for everything else.
>
> so that I understand what you are saying
> (I apologize if being slow),
> does this sequence of commands
> have the expected behavior in your Vim:
>
> " {{{ should make aj ec banana, bj ec apple, ak ec orange, bk not mapped:
> let mapleader = 'a'
> nn <leader>j :ec 'a banana'<CR>
> let mapleader = 'b'
> nn <leader>j :ec 'an apple'<CR>
> let mapleader = 'a'
> nn <leader>k :ec 'an orange'<CR>
> " }}}
I know what mappings this will result in. I do not understand how this
sequence is *relevant* to the discussion.
>
>>
>> > ((
>> > :version
>> > VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan 6 2018 23:48:57)
>> > Included patches: 1-1428
>> > Compiled by renato@xps
>> > Huge version without GUI.
>> > )) + python 2-3 and termguicolors
>> >
>> >
>> >>
>> >> >
>> >> > Anyway, I understood that it is not needed to define
>> >> > extra <XXX> key names, but is it possible within Vim standard
>> >> > capabilities?
>> >>
>> >> What is possible? All XXX in `<XXX>` are defined at compile time only,
>> >> you can't evaluate expression inside XXX or something like this.
>> >
>> > Ok, so question closed here.
>> > Notice that <XXX> is surely not completely
>> > defined in compile time, for we use
>> > g:mapleader to set <leader> at run time.
>> >
>> > Am I following things right?
>>
>> You cannot change semantics of `<Leader>` or e.g. evaluate `mapleader`
>> as an expression, so this fact is not helpful. And you also can't add
>> any new keys. So "not completely" is not very helpful.
>
> exe g:mapleader
> evaluates mapleader as an expression, but I don't see the case to do this.
:let g:mapleader = '(expand("<sfile>") =~# ''\mmyscript\.vim$''?"a":"b"')'
will not make `<Leader>` expand to `a` for `myscript.vim` and `b` for
everything else.
>
> let mapleader += 'banana'
> should work to add new keys, but I again fail to see the point.
Neither there is a way to create `<banana>` key in runtime.
>
> "not completely" there is in the sense of being dependent also on
> the scripts/commands parsed at runtime, not at compile time.
> Apologies for not being palpable.
>
>>
>> >
>> >>
>> >> >
>> >> >
>> >> > Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX escreveu:
>> >> >> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
>> >> >> > leader and localleader are the standard, so one might
>> >> >> > have conflicts between scripts because
>> >> >> > all of them use leader and localleader.
>> >> >> >
>> >> >> > how would you define, say
>> >> >> > <coolleader>, which you set to the
>> >> >> > leader by default,
>> >> >> > but can be changed to any key
>> >> >> > sequence (including c-v derived).
>> >> >> >
>> >> >> > ==
>> >> >> > ideally, I would have a command mkKeyName with which to define
>> >> >> > <coolleader> such as
>> >> >> >
>> >> >> > :mkKeyName -default=leader coolleader
>> >> >> >
>> >> >> > and might set it to anything such as
>> >> >> > se mapcoolleader=^[
>> >> >> > se mapcoolleader=
>> >> >> > se mapcoolleader!
>> >> >> > se mapcoolleader!=<Space>
>> >> >> >
>> >> >> > (this implies that one would also able to use
>> >> >> > :setlocal mapcoolleader ??
>> >> >> >
>> >> >> > and use it in your mappings
>> >> >> > as in
>> >> >> > nnoremap <coolleader>B :call MyCoolFunction()<CR>
>> >> >>
>> >> >> This is not needed, there is `:execute` as something requiring changes
>> >> >> to plugin code. E.g. my plugins (on my frawor framework) allow
>> >> >> defining plugin-specific leader.
>> >> >>
>> >> >> To override `mapleader` for plugins which are not nice enough to allow
>> >> >> defining plugin-specific leader there is SourcePre event.
>> >> >>
>> >> >> I personally find mapleader and maplocalleader as quite *incomplete*
>> >> >> thing. For plugins much better idea would be key-value store: e.g. in
>> >> >> place of
>> >> >>
>> >> >> nnoremap <Plug>(FooPluginDoBar) :call foo#bar()<CR>
>> >> >> nnoremap <Plug>(FooPluginDoZab) :call foo#zab()<CR>
>> >> >>
>> >> >> nmap <Leader>fb <Plug>(FooPluginDoBar)
>> >> >> nmap <Leader>fz <Plug>(FooPluginDoZab)
>> >> >>
>> >> >> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write just
>> >> >>
>> >> >> mapdefineprefix FooPlugin <Leader>f
>> >> >> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()<CR>
>> >> >> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()<CR>
>> >> >>
>> >> >> and Vim will handle actually substituting values like this: each
>> >> >> `<:prefix:mapname(default)>` expands into a concat of two strings:
>> >> >>
>> >> >> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to `prefix`.
>> >> >> 2. The rhs of the first `:mapdefine` command or the `default` value if
>> >> >> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
>> >> >> issued. Inside `default` `<>` are good as long as they are balanced,
>> >> >> various special characters like `)` may be entered via something like
>> >> >> `<Char-41>`.
>> >> >>
>> >> >> In both cases using bang clears the prefix, so next non-banged command
>> >> >> will define it (normally it is ignored).
>> >> >>
>> >> >> E.g. in this case if user wants mappings of foo plugin start with `,o`
>> >> >> and not `<Leader>f` all he needs would be putting
>> >> >>
>> >> >> mapdefineprefix FooPlugin ,o
>> >> >>
>> >> >> into the vimrc (requirement: before sourcing actual plugin). If
>> >> >> additionally he thinks that `DoZab` command is easier to run with
>> >> >> `,oo` he would need
>> >> >>
>> >> >> mapdefine FooPlugin:DoZab o
>> >> >>
>> >> >> (requirement is the same).
>> >> >>
>> >> >> Currently plugins may do this on top of `:execute`, but nobody
>> >> >> bothers. I normally want this functionality to e.g. make NERDCommenter
>> >> >> mappings all start with `,c` (no, redefining `<Leader>` for all
>> >> >> plugins does not sound like a good idea; `SourcePre` is useful, but
>> >> >> still feels like a hack) or "undefine" (i.e. prefix with something you
>> >> >> would never type, e.g. `<Plug>XXXIWouldNeverTypeThisXXX`) mappings for
>> >> >> plugins I install for functionality other then mappings (not everybody
>> >> >> is nice enough to have g:NERDCreateDefaultMappings setting).
>> >> >>
>> >> >> >
>> >> >> > thanks again,
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > 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 vim_use+unsubscribe@googlegroups.com.
>> >> >> > For more options, visit https://groups.google.com/d/optout.
>> >> >
>> >> > --
>> >> > --
>> >> > 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.
>> >
>> > --
>> > --
>> > 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.
>
> --
> --
> 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.
--
--
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.
> Em sexta-feira, 23 de fevereiro de 2018 15:51:35 UTC-3, ZyX escreveu:
>> 2018-02-23 18:21 GMT+03:00 Renato Fabbri:
>> > Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX escreveu:
>> >> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
>> >> > Well, from your comments, i put a:
>> >> >
>> >> > let g:aall = mapleader
>> >> > " let mapleader = '<Space>'
>> >> > if exists("g:aa_leader")
>> >> > let mapleader = g:aa_leader
>> >> > el
>> >> > let mapleader = 'anything'
>> >> > en
>> >> >
>> >> >
>> >> > before the mappings, and a:
>> >> >
>> >> > let mapleader = g:aall
>> >> >
>> >> > after them and it is all ok.
>> >> > (only these mappings use the
>> >> > temporarily defined leader key.)
>> >> >
>> >> > I did not understand how SourcePre
>> >> > would be used.
>> >> > Something like:
>> >> > au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', mapleader]
>> >> >
>> >> > in combination with a somewhat SourcePost event to
>> >> > set mapleader to fooleader?
>> >>
>> >> No, you set mapleader for *all* scripts, either to default or to
>> >> something else. There is no SourcePost for some reason; an alternative
>> >> is messing with SourceCmd, but this is harder to do right in general,
>> >> but easier to use for specific use cases.
>> >
>> > hum... try this:
>> > let mapleader = 'a'
>> > nn <leader>j :ec 'a banana'<CR>
>> > let mapleader = 'b'
>> > nn <leader>j :ec 'an apple'<CR>
>> > let mapleader = 'a'
>> > nn <leader>k :ec 'an orange'<CR>
>> >
>> > which work 100% fine here.
>>
>> I do not understand what you are trying to say. I know that `<leader>`
>> is expanded only once, but that is not helpful: SourcePre is run only
>> before some script, so if your script is not the last one you have to
>> create SourcePre command which will set mapleader to one value for
>> your script and to another value for everything else.
>
> so that I understand what you are saying
> (I apologize if being slow),
> does this sequence of commands
> have the expected behavior in your Vim:
>
> " {{{ should make aj ec banana, bj ec apple, ak ec orange, bk not mapped:
> let mapleader = 'a'
> nn <leader>j :ec 'a banana'<CR>
> let mapleader = 'b'
> nn <leader>j :ec 'an apple'<CR>
> let mapleader = 'a'
> nn <leader>k :ec 'an orange'<CR>
> " }}}
I know what mappings this will result in. I do not understand how this
sequence is *relevant* to the discussion.
>
>>
>> > ((
>> > :version
>> > VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan 6 2018 23:48:57)
>> > Included patches: 1-1428
>> > Compiled by renato@xps
>> > Huge version without GUI.
>> > )) + python 2-3 and termguicolors
>> >
>> >
>> >>
>> >> >
>> >> > Anyway, I understood that it is not needed to define
>> >> > extra <XXX> key names, but is it possible within Vim standard
>> >> > capabilities?
>> >>
>> >> What is possible? All XXX in `<XXX>` are defined at compile time only,
>> >> you can't evaluate expression inside XXX or something like this.
>> >
>> > Ok, so question closed here.
>> > Notice that <XXX> is surely not completely
>> > defined in compile time, for we use
>> > g:mapleader to set <leader> at run time.
>> >
>> > Am I following things right?
>>
>> You cannot change semantics of `<Leader>` or e.g. evaluate `mapleader`
>> as an expression, so this fact is not helpful. And you also can't add
>> any new keys. So "not completely" is not very helpful.
>
> exe g:mapleader
> evaluates mapleader as an expression, but I don't see the case to do this.
:let g:mapleader = '(expand("<sfile>") =~# ''\mmyscript\.vim$''?"a":"b"')'
will not make `<Leader>` expand to `a` for `myscript.vim` and `b` for
everything else.
>
> let mapleader += 'banana'
> should work to add new keys, but I again fail to see the point.
Neither there is a way to create `<banana>` key in runtime.
>
> "not completely" there is in the sense of being dependent also on
> the scripts/commands parsed at runtime, not at compile time.
> Apologies for not being palpable.
>
>>
>> >
>> >>
>> >> >
>> >> >
>> >> > Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX escreveu:
>> >> >> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
>> >> >> > leader and localleader are the standard, so one might
>> >> >> > have conflicts between scripts because
>> >> >> > all of them use leader and localleader.
>> >> >> >
>> >> >> > how would you define, say
>> >> >> > <coolleader>, which you set to the
>> >> >> > leader by default,
>> >> >> > but can be changed to any key
>> >> >> > sequence (including c-v derived).
>> >> >> >
>> >> >> > ==
>> >> >> > ideally, I would have a command mkKeyName with which to define
>> >> >> > <coolleader> such as
>> >> >> >
>> >> >> > :mkKeyName -default=leader coolleader
>> >> >> >
>> >> >> > and might set it to anything such as
>> >> >> > se mapcoolleader=^[
>> >> >> > se mapcoolleader=
>> >> >> > se mapcoolleader!
>> >> >> > se mapcoolleader!=<Space>
>> >> >> >
>> >> >> > (this implies that one would also able to use
>> >> >> > :setlocal mapcoolleader ??
>> >> >> >
>> >> >> > and use it in your mappings
>> >> >> > as in
>> >> >> > nnoremap <coolleader>B :call MyCoolFunction()<CR>
>> >> >>
>> >> >> This is not needed, there is `:execute` as something requiring changes
>> >> >> to plugin code. E.g. my plugins (on my frawor framework) allow
>> >> >> defining plugin-specific leader.
>> >> >>
>> >> >> To override `mapleader` for plugins which are not nice enough to allow
>> >> >> defining plugin-specific leader there is SourcePre event.
>> >> >>
>> >> >> I personally find mapleader and maplocalleader as quite *incomplete*
>> >> >> thing. For plugins much better idea would be key-value store: e.g. in
>> >> >> place of
>> >> >>
>> >> >> nnoremap <Plug>(FooPluginDoBar) :call foo#bar()<CR>
>> >> >> nnoremap <Plug>(FooPluginDoZab) :call foo#zab()<CR>
>> >> >>
>> >> >> nmap <Leader>fb <Plug>(FooPluginDoBar)
>> >> >> nmap <Leader>fz <Plug>(FooPluginDoZab)
>> >> >>
>> >> >> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write just
>> >> >>
>> >> >> mapdefineprefix FooPlugin <Leader>f
>> >> >> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()<CR>
>> >> >> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()<CR>
>> >> >>
>> >> >> and Vim will handle actually substituting values like this: each
>> >> >> `<:prefix:mapname(default)>` expands into a concat of two strings:
>> >> >>
>> >> >> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to `prefix`.
>> >> >> 2. The rhs of the first `:mapdefine` command or the `default` value if
>> >> >> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
>> >> >> issued. Inside `default` `<>` are good as long as they are balanced,
>> >> >> various special characters like `)` may be entered via something like
>> >> >> `<Char-41>`.
>> >> >>
>> >> >> In both cases using bang clears the prefix, so next non-banged command
>> >> >> will define it (normally it is ignored).
>> >> >>
>> >> >> E.g. in this case if user wants mappings of foo plugin start with `,o`
>> >> >> and not `<Leader>f` all he needs would be putting
>> >> >>
>> >> >> mapdefineprefix FooPlugin ,o
>> >> >>
>> >> >> into the vimrc (requirement: before sourcing actual plugin). If
>> >> >> additionally he thinks that `DoZab` command is easier to run with
>> >> >> `,oo` he would need
>> >> >>
>> >> >> mapdefine FooPlugin:DoZab o
>> >> >>
>> >> >> (requirement is the same).
>> >> >>
>> >> >> Currently plugins may do this on top of `:execute`, but nobody
>> >> >> bothers. I normally want this functionality to e.g. make NERDCommenter
>> >> >> mappings all start with `,c` (no, redefining `<Leader>` for all
>> >> >> plugins does not sound like a good idea; `SourcePre` is useful, but
>> >> >> still feels like a hack) or "undefine" (i.e. prefix with something you
>> >> >> would never type, e.g. `<Plug>XXXIWouldNeverTypeThisXXX`) mappings for
>> >> >> plugins I install for functionality other then mappings (not everybody
>> >> >> is nice enough to have g:NERDCreateDefaultMappings setting).
>> >> >>
>> >> >> >
>> >> >> > thanks again,
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > 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 vim_use+unsubscribe@googlegroups.com.
>> >> >> > For more options, visit https://groups.google.com/d/optout.
>> >> >
>> >> > --
>> >> > --
>> >> > 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.
>> >
>> > --
>> > --
>> > 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.
>
> --
> --
> 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.
--
--
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.
Sunday, February 25, 2018
Re: making custom key names for mappings
Em sexta-feira, 23 de fevereiro de 2018 15:51:35 UTC-3, ZyX escreveu:
> 2018-02-23 18:21 GMT+03:00 Renato Fabbri:
> > Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX escreveu:
> >> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
> >> > Well, from your comments, i put a:
> >> >
> >> > let g:aall = mapleader
> >> > " let mapleader = '<Space>'
> >> > if exists("g:aa_leader")
> >> > let mapleader = g:aa_leader
> >> > el
> >> > let mapleader = 'anything'
> >> > en
> >> >
> >> >
> >> > before the mappings, and a:
> >> >
> >> > let mapleader = g:aall
> >> >
> >> > after them and it is all ok.
> >> > (only these mappings use the
> >> > temporarily defined leader key.)
> >> >
> >> > I did not understand how SourcePre
> >> > would be used.
> >> > Something like:
> >> > au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', mapleader]
> >> >
> >> > in combination with a somewhat SourcePost event to
> >> > set mapleader to fooleader?
> >>
> >> No, you set mapleader for *all* scripts, either to default or to
> >> something else. There is no SourcePost for some reason; an alternative
> >> is messing with SourceCmd, but this is harder to do right in general,
> >> but easier to use for specific use cases.
> >
> > hum... try this:
> > let mapleader = 'a'
> > nn <leader>j :ec 'a banana'<CR>
> > let mapleader = 'b'
> > nn <leader>j :ec 'an apple'<CR>
> > let mapleader = 'a'
> > nn <leader>k :ec 'an orange'<CR>
> >
> > which work 100% fine here.
>
> I do not understand what you are trying to say. I know that `<leader>`
> is expanded only once, but that is not helpful: SourcePre is run only
> before some script, so if your script is not the last one you have to
> create SourcePre command which will set mapleader to one value for
> your script and to another value for everything else.
so that I understand what you are saying
(I apologize if being slow),
does this sequence of commands
have the expected behavior in your Vim:
" {{{ should make aj ec banana, bj ec apple, ak ec orange, bk not mapped:
let mapleader = 'a'
nn <leader>j :ec 'a banana'<CR>
let mapleader = 'b'
nn <leader>j :ec 'an apple'<CR>
let mapleader = 'a'
nn <leader>k :ec 'an orange'<CR>
" }}}
>
> > ((
> > :version
> > VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan 6 2018 23:48:57)
> > Included patches: 1-1428
> > Compiled by renato@xps
> > Huge version without GUI.
> > )) + python 2-3 and termguicolors
> >
> >
> >>
> >> >
> >> > Anyway, I understood that it is not needed to define
> >> > extra <XXX> key names, but is it possible within Vim standard
> >> > capabilities?
> >>
> >> What is possible? All XXX in `<XXX>` are defined at compile time only,
> >> you can't evaluate expression inside XXX or something like this.
> >
> > Ok, so question closed here.
> > Notice that <XXX> is surely not completely
> > defined in compile time, for we use
> > g:mapleader to set <leader> at run time.
> >
> > Am I following things right?
>
> You cannot change semantics of `<Leader>` or e.g. evaluate `mapleader`
> as an expression, so this fact is not helpful. And you also can't add
> any new keys. So "not completely" is not very helpful.
exe g:mapleader
evaluates mapleader as an expression, but I don't see the case to do this.
let mapleader += 'banana'
should work to add new keys, but I again fail to see the point.
"not completely" there is in the sense of being dependent also on
the scripts/commands parsed at runtime, not at compile time.
Apologies for not being palpable.
>
> >
> >>
> >> >
> >> >
> >> > Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX escreveu:
> >> >> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
> >> >> > leader and localleader are the standard, so one might
> >> >> > have conflicts between scripts because
> >> >> > all of them use leader and localleader.
> >> >> >
> >> >> > how would you define, say
> >> >> > <coolleader>, which you set to the
> >> >> > leader by default,
> >> >> > but can be changed to any key
> >> >> > sequence (including c-v derived).
> >> >> >
> >> >> > ==
> >> >> > ideally, I would have a command mkKeyName with which to define
> >> >> > <coolleader> such as
> >> >> >
> >> >> > :mkKeyName -default=leader coolleader
> >> >> >
> >> >> > and might set it to anything such as
> >> >> > se mapcoolleader=^[
> >> >> > se mapcoolleader=
> >> >> > se mapcoolleader!
> >> >> > se mapcoolleader!=<Space>
> >> >> >
> >> >> > (this implies that one would also able to use
> >> >> > :setlocal mapcoolleader ??
> >> >> >
> >> >> > and use it in your mappings
> >> >> > as in
> >> >> > nnoremap <coolleader>B :call MyCoolFunction()<CR>
> >> >>
> >> >> This is not needed, there is `:execute` as something requiring changes
> >> >> to plugin code. E.g. my plugins (on my frawor framework) allow
> >> >> defining plugin-specific leader.
> >> >>
> >> >> To override `mapleader` for plugins which are not nice enough to allow
> >> >> defining plugin-specific leader there is SourcePre event.
> >> >>
> >> >> I personally find mapleader and maplocalleader as quite *incomplete*
> >> >> thing. For plugins much better idea would be key-value store: e.g. in
> >> >> place of
> >> >>
> >> >> nnoremap <Plug>(FooPluginDoBar) :call foo#bar()<CR>
> >> >> nnoremap <Plug>(FooPluginDoZab) :call foo#zab()<CR>
> >> >>
> >> >> nmap <Leader>fb <Plug>(FooPluginDoBar)
> >> >> nmap <Leader>fz <Plug>(FooPluginDoZab)
> >> >>
> >> >> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write just
> >> >>
> >> >> mapdefineprefix FooPlugin <Leader>f
> >> >> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()<CR>
> >> >> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()<CR>
> >> >>
> >> >> and Vim will handle actually substituting values like this: each
> >> >> `<:prefix:mapname(default)>` expands into a concat of two strings:
> >> >>
> >> >> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to `prefix`.
> >> >> 2. The rhs of the first `:mapdefine` command or the `default` value if
> >> >> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
> >> >> issued. Inside `default` `<>` are good as long as they are balanced,
> >> >> various special characters like `)` may be entered via something like
> >> >> `<Char-41>`.
> >> >>
> >> >> In both cases using bang clears the prefix, so next non-banged command
> >> >> will define it (normally it is ignored).
> >> >>
> >> >> E.g. in this case if user wants mappings of foo plugin start with `,o`
> >> >> and not `<Leader>f` all he needs would be putting
> >> >>
> >> >> mapdefineprefix FooPlugin ,o
> >> >>
> >> >> into the vimrc (requirement: before sourcing actual plugin). If
> >> >> additionally he thinks that `DoZab` command is easier to run with
> >> >> `,oo` he would need
> >> >>
> >> >> mapdefine FooPlugin:DoZab o
> >> >>
> >> >> (requirement is the same).
> >> >>
> >> >> Currently plugins may do this on top of `:execute`, but nobody
> >> >> bothers. I normally want this functionality to e.g. make NERDCommenter
> >> >> mappings all start with `,c` (no, redefining `<Leader>` for all
> >> >> plugins does not sound like a good idea; `SourcePre` is useful, but
> >> >> still feels like a hack) or "undefine" (i.e. prefix with something you
> >> >> would never type, e.g. `<Plug>XXXIWouldNeverTypeThisXXX`) mappings for
> >> >> plugins I install for functionality other then mappings (not everybody
> >> >> is nice enough to have g:NERDCreateDefaultMappings setting).
> >> >>
> >> >> >
> >> >> > thanks again,
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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 vim_use+unsubscribe@googlegroups.com.
> >> >> > For more options, visit https://groups.google.com/d/optout.
> >> >
> >> > --
> >> > --
> >> > 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.
> >
> > --
> > --
> > 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.
--
--
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.
> 2018-02-23 18:21 GMT+03:00 Renato Fabbri:
> > Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX escreveu:
> >> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
> >> > Well, from your comments, i put a:
> >> >
> >> > let g:aall = mapleader
> >> > " let mapleader = '<Space>'
> >> > if exists("g:aa_leader")
> >> > let mapleader = g:aa_leader
> >> > el
> >> > let mapleader = 'anything'
> >> > en
> >> >
> >> >
> >> > before the mappings, and a:
> >> >
> >> > let mapleader = g:aall
> >> >
> >> > after them and it is all ok.
> >> > (only these mappings use the
> >> > temporarily defined leader key.)
> >> >
> >> > I did not understand how SourcePre
> >> > would be used.
> >> > Something like:
> >> > au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', mapleader]
> >> >
> >> > in combination with a somewhat SourcePost event to
> >> > set mapleader to fooleader?
> >>
> >> No, you set mapleader for *all* scripts, either to default or to
> >> something else. There is no SourcePost for some reason; an alternative
> >> is messing with SourceCmd, but this is harder to do right in general,
> >> but easier to use for specific use cases.
> >
> > hum... try this:
> > let mapleader = 'a'
> > nn <leader>j :ec 'a banana'<CR>
> > let mapleader = 'b'
> > nn <leader>j :ec 'an apple'<CR>
> > let mapleader = 'a'
> > nn <leader>k :ec 'an orange'<CR>
> >
> > which work 100% fine here.
>
> I do not understand what you are trying to say. I know that `<leader>`
> is expanded only once, but that is not helpful: SourcePre is run only
> before some script, so if your script is not the last one you have to
> create SourcePre command which will set mapleader to one value for
> your script and to another value for everything else.
so that I understand what you are saying
(I apologize if being slow),
does this sequence of commands
have the expected behavior in your Vim:
" {{{ should make aj ec banana, bj ec apple, ak ec orange, bk not mapped:
let mapleader = 'a'
nn <leader>j :ec 'a banana'<CR>
let mapleader = 'b'
nn <leader>j :ec 'an apple'<CR>
let mapleader = 'a'
nn <leader>k :ec 'an orange'<CR>
" }}}
>
> > ((
> > :version
> > VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan 6 2018 23:48:57)
> > Included patches: 1-1428
> > Compiled by renato@xps
> > Huge version without GUI.
> > )) + python 2-3 and termguicolors
> >
> >
> >>
> >> >
> >> > Anyway, I understood that it is not needed to define
> >> > extra <XXX> key names, but is it possible within Vim standard
> >> > capabilities?
> >>
> >> What is possible? All XXX in `<XXX>` are defined at compile time only,
> >> you can't evaluate expression inside XXX or something like this.
> >
> > Ok, so question closed here.
> > Notice that <XXX> is surely not completely
> > defined in compile time, for we use
> > g:mapleader to set <leader> at run time.
> >
> > Am I following things right?
>
> You cannot change semantics of `<Leader>` or e.g. evaluate `mapleader`
> as an expression, so this fact is not helpful. And you also can't add
> any new keys. So "not completely" is not very helpful.
exe g:mapleader
evaluates mapleader as an expression, but I don't see the case to do this.
let mapleader += 'banana'
should work to add new keys, but I again fail to see the point.
"not completely" there is in the sense of being dependent also on
the scripts/commands parsed at runtime, not at compile time.
Apologies for not being palpable.
>
> >
> >>
> >> >
> >> >
> >> > Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX escreveu:
> >> >> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
> >> >> > leader and localleader are the standard, so one might
> >> >> > have conflicts between scripts because
> >> >> > all of them use leader and localleader.
> >> >> >
> >> >> > how would you define, say
> >> >> > <coolleader>, which you set to the
> >> >> > leader by default,
> >> >> > but can be changed to any key
> >> >> > sequence (including c-v derived).
> >> >> >
> >> >> > ==
> >> >> > ideally, I would have a command mkKeyName with which to define
> >> >> > <coolleader> such as
> >> >> >
> >> >> > :mkKeyName -default=leader coolleader
> >> >> >
> >> >> > and might set it to anything such as
> >> >> > se mapcoolleader=^[
> >> >> > se mapcoolleader=
> >> >> > se mapcoolleader!
> >> >> > se mapcoolleader!=<Space>
> >> >> >
> >> >> > (this implies that one would also able to use
> >> >> > :setlocal mapcoolleader ??
> >> >> >
> >> >> > and use it in your mappings
> >> >> > as in
> >> >> > nnoremap <coolleader>B :call MyCoolFunction()<CR>
> >> >>
> >> >> This is not needed, there is `:execute` as something requiring changes
> >> >> to plugin code. E.g. my plugins (on my frawor framework) allow
> >> >> defining plugin-specific leader.
> >> >>
> >> >> To override `mapleader` for plugins which are not nice enough to allow
> >> >> defining plugin-specific leader there is SourcePre event.
> >> >>
> >> >> I personally find mapleader and maplocalleader as quite *incomplete*
> >> >> thing. For plugins much better idea would be key-value store: e.g. in
> >> >> place of
> >> >>
> >> >> nnoremap <Plug>(FooPluginDoBar) :call foo#bar()<CR>
> >> >> nnoremap <Plug>(FooPluginDoZab) :call foo#zab()<CR>
> >> >>
> >> >> nmap <Leader>fb <Plug>(FooPluginDoBar)
> >> >> nmap <Leader>fz <Plug>(FooPluginDoZab)
> >> >>
> >> >> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write just
> >> >>
> >> >> mapdefineprefix FooPlugin <Leader>f
> >> >> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()<CR>
> >> >> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()<CR>
> >> >>
> >> >> and Vim will handle actually substituting values like this: each
> >> >> `<:prefix:mapname(default)>` expands into a concat of two strings:
> >> >>
> >> >> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to `prefix`.
> >> >> 2. The rhs of the first `:mapdefine` command or the `default` value if
> >> >> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
> >> >> issued. Inside `default` `<>` are good as long as they are balanced,
> >> >> various special characters like `)` may be entered via something like
> >> >> `<Char-41>`.
> >> >>
> >> >> In both cases using bang clears the prefix, so next non-banged command
> >> >> will define it (normally it is ignored).
> >> >>
> >> >> E.g. in this case if user wants mappings of foo plugin start with `,o`
> >> >> and not `<Leader>f` all he needs would be putting
> >> >>
> >> >> mapdefineprefix FooPlugin ,o
> >> >>
> >> >> into the vimrc (requirement: before sourcing actual plugin). If
> >> >> additionally he thinks that `DoZab` command is easier to run with
> >> >> `,oo` he would need
> >> >>
> >> >> mapdefine FooPlugin:DoZab o
> >> >>
> >> >> (requirement is the same).
> >> >>
> >> >> Currently plugins may do this on top of `:execute`, but nobody
> >> >> bothers. I normally want this functionality to e.g. make NERDCommenter
> >> >> mappings all start with `,c` (no, redefining `<Leader>` for all
> >> >> plugins does not sound like a good idea; `SourcePre` is useful, but
> >> >> still feels like a hack) or "undefine" (i.e. prefix with something you
> >> >> would never type, e.g. `<Plug>XXXIWouldNeverTypeThisXXX`) mappings for
> >> >> plugins I install for functionality other then mappings (not everybody
> >> >> is nice enough to have g:NERDCreateDefaultMappings setting).
> >> >>
> >> >> >
> >> >> > thanks again,
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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 vim_use+unsubscribe@googlegroups.com.
> >> >> > For more options, visit https://groups.google.com/d/optout.
> >> >
> >> > --
> >> > --
> >> > 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.
> >
> > --
> > --
> > 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.
--
--
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.
bugs?
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)
--
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.
Subscribe to:
Posts (Atom)