[PATCH] added TextDeleted and TextYanked events

[Philippe Vaucher]

Hello,

I added TextDelete and TextYank events.

This necessity appeared because of the small delete register getting
in our way in order to implement a proper killring. There exists a
plugin that tries to address it (YankRing.vim) but then other things
break down, like macros with counts, not to mention the plugin is
heavy.

This issue was raised on irc by the-isz and myself after we realised
we couldn't have a nice flow about editing some file like this:

delete a word (dw), remove some trailing spaces (xxx), go to end of
line ($), paste word (arg, dw didn't put word in registers 1-9, need
to undo, put word in explicit register, etc)

With this patch, we can now make a very simple "YankRing" plugin which
only stores Yanked/Deleted texts by listening on those events, without
interfering with all the vim commands like the original YankRing
plugin does.

You can test it with:

autocmd TextDeleted * echom 'Deleted: ' . @"
autocmd TextYanked * echom 'Yanked: ' . @"

Tell me what you think.

Philippe


From f82fa9037bf6bd2013742e9502ffcdea903e8401 Mon Sep 17 00:00:00 2001
From: Philippe Vaucher <philippe...@gmail.com>
Date: Mon, 23 May 2011 17:08:51 +0200
Subject: [PATCH] Added TextDeleted and TextYanked events

---
runtime/doc/autocmd.txt | 13 +++++++++++++
src/fileio.c | 2 ++
src/ops.c | 2 ++
src/vim.h | 2 ++
4 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/runtime/doc/autocmd.txt b/runtime/doc/autocmd.txt
index 145ecf6..057db21 100644
--- a/runtime/doc/autocmd.txt
+++ b/runtime/doc/autocmd.txt
@@ -302,6 +302,9 @@ Name triggered by ~
|InsertCharPre| when a character was typed in Insert mode, before
inserting it

+|TextDeleted| when some text is deleted (dw, dd, D)
+|TextYanked| when some text is yanked (yw, yd, Y)
+
|ColorScheme| after loading a color scheme

|RemoteReply| a reply from a server Vim was received
@@ -670,6 +673,16 @@ InsertCharPre When a character is typed in
Insert mode,
It is not allowed to change the text |textlock|.
The event is not triggered when 'paste' is
set.
+ *TextDeleted*
+TextDeleted Just after a delete (|d|) command is issued.
+ You can inspect the @" variable to
know
+ about the deleted text.
+
+ *TextYanked*
+TextYanked Just after a |yank| (|y|) command is issued.
+ You can inspect the @" variable to
know
+ about the deleted text.
+
*InsertEnter*
InsertEnter Just before starting Insert mode. Also for
Replace mode and Virtual Replace mode. The
diff --git a/src/fileio.c b/src/fileio.c
index 6355c79..81b09e2 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -7688,6 +7688,8 @@ static struct event_name
{"WinEnter", EVENT_WINENTER},
{"WinLeave", EVENT_WINLEAVE},
{"VimResized", EVENT_VIMRESIZED},
+ {"TextDeleted", EVENT_TEXTDELETED},
+ {"TextYanked", EVENT_TEXTYANKED},
{NULL, (event_T)0}
};

diff --git a/src/ops.c b/src/ops.c
index c41f844..375e629 100644
--- a/src/ops.c
+++ b/src/ops.c
@@ -3160,6 +3160,8 @@ op_yank(oap, deleting, mess)
# endif
#endif

+ apply_autocmds(deleting ? EVENT_TEXTDELETED : EVENT_TEXTYANKED,
NULL, NULL, FALSE, curbuf);
+
return OK;

fail: /* free the allocated lines */
diff --git a/src/vim.h b/src/vim.h
index 1f4f17b..5473a21 100644
--- a/src/vim.h
+++ b/src/vim.h
@@ -1290,6 +1290,8 @@ enum auto_event
EVENT_TABENTER, /* after entering a tab page */
EVENT_SHELLCMDPOST, /* after ":!cmd" */
EVENT_SHELLFILTERPOST, /* after ":1,2!cmd", ":w !cmd", ":r !cmd".
*/
+ EVENT_TEXTDELETED, /* after a delete command was done (dd, dw,
D) */
+ EVENT_TEXTYANKED, /* after a yank command was done (yy, yw, Y)
*/
NUM_EVENTS /* MUST be the last one */
};

--
1.7.4.msysgit.0

[Bram Moolenaar]

Philippe Vaucher wrote:

> I added TextDelete and TextYank events.
>
> This necessity appeared because of the small delete register getting
> in our way in order to implement a proper killring. There exists a
> plugin that tries to address it (YankRing.vim) but then other things
> break down, like macros with counts, not to mention the plugin is
> heavy.
>
> This issue was raised on irc by the-isz and myself after we realised
> we couldn't have a nice flow about editing some file like this:
>
> delete a word (dw), remove some trailing spaces (xxx), go to end of
> line ($), paste word (arg, dw didn't put word in registers 1-9, need
> to undo, put word in explicit register, etc)
>
> With this patch, we can now make a very simple "YankRing" plugin which
> only stores Yanked/Deleted texts by listening on those events, without
> interfering with all the vim commands like the original YankRing
> plugin does.
>
> You can test it with:
>
> autocmd TextDeleted * echom 'Deleted: ' . @"
> autocmd TextYanked * echom 'Yanked: ' . @"
>
> Tell me what you think.

I think they should be called TextDeletePost and TextYankPost to be
consistent.

Try doing something weird in the autocommand, such as "help" and then
deleting something.

You probably need to disallow lots of things to avoid breaking stuff
(and perhaps even crashing Vim).

Don't you need to let the commands know what register text was yanked
into?

--
hundred-and-one symptoms of being an internet addict:
99. The hum of a cooling fan and the click of keys is comforting to you.

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

[Philippe Vaucher]

> I think they should be called TextDeletePost and TextYankPost to be
> consistent.

Ok, I can do that.

> Try doing something weird in the autocommand, such as "help" and then
> deleting something.
> You probably need to disallow lots of things to avoid breaking stuff
> (and perhaps even crashing Vim).

I'm not sure I want to support the crazy guys, there's probably lots
of ways to create problems with other events too if that's your goal.
Anyway, what do you have in mind? The current patch is very simple and
I kinda like it to be that way, but if there are obvious stuffs I can
disable/disallow I'll do it.

> Don't you need to let the commands know what register text was yanked
> into?

No because every delete/yank use the " register even if a register was
explicitely specified. As a matter of completeness maybe it'd be nice
to know which register was intended yes but it's the first time I
fiddle with vim's source (with some pain) so I'm not too sure how much
work is involved in creating one of those v:somevar.

Philippe

[ZyX]

Reply to message «Re: added TextDeleted and TextYanked events»,
sent 01:00:50 24 May 2011, Tuesday
by Philippe Vaucher:

> No because every delete/yank use the " register even if a register was
> explicitely specified. As a matter of completeness maybe it'd be nice
> to know which register was intended yes but it's the first time I
> fiddle with vim's source (with some pain) so I'm not too sure how much
> work is involved in creating one of those v:somevar.

No, you forgot about deleting to black hole register.

Original message:

[Philippe Vaucher]

> > No because every delete/yank use the " register even if a register was
> > explicitely specified. As a matter of completeness maybe it'd be nice
> > to know which register was intended yes but it's the first time I
> > fiddle with vim's source (with some pain) so I'm not too sure how much
> > work is involved in creating one of those v:somevar.
>
> No, you forgot about deleting to black hole register.

Well this was kinda by design, tho it's a marginal decision. I
originally thought "well if someone really don't want it to go in a
register (black hole) why should TextDeleted/TextYanked fire for it?".

Philippe

[Bram Moolenaar]

Philippe Vaucher wrote:

That should be in the documentation then.

--
hundred-and-one symptoms of being an internet addict:

100. The most exciting sporting events you noticed during summer 1996
was Netscape vs. Microsoft.

[Bram Moolenaar]

Philippe Vaucher wrote:

> > I think they should be called TextDeletePost and TextYankPost to be
> > consistent.
>
> Ok, I can do that.
>
> > Try doing something weird in the autocommand, such as "help" and then
> > deleting something.
> > You probably need to disallow lots of things to avoid breaking stuff
> > (and perhaps even crashing Vim).
>
> I'm not sure I want to support the crazy guys, there's probably lots
> of ways to create problems with other events too if that's your goal.
> Anyway, what do you have in mind? The current patch is very simple and
> I kinda like it to be that way, but if there are obvious stuffs I can
> disable/disallow I'll do it.

Using textlock probably works.

The problem is that there will always be people that install an
autocommand (or use a plugin that has this autocommand without them
knowning) and then run into trouble because of unexpected things.
It's better to protect the user from destroying his text.
Crashing Vim is obviously worse.

> > Don't you need to let the commands know what register text was yanked
> > into?
>
> No because every delete/yank use the " register even if a register was
> explicitely specified. As a matter of completeness maybe it'd be nice
> to know which register was intended yes but it's the first time I
> fiddle with vim's source (with some pain) so I'm not too sure how much
> work is involved in creating one of those v:somevar.

OK, we can add it later when really needed.

--
hundred-and-one symptoms of being an internet addict:

101. U can read htis w/o ny porblm and cant figur eout Y its evn listd.

[Ben Fritz]

On May 24, 6:14 am, Bram Moolenaar <B...@Moolenaar.net> wrote:

> Philippe Vaucher wrote:
> > > Don't you need to let the commands know what register text was yanked
> > > into?
>
> > No because every delete/yank use the " register even if a register was
> > explicitely specified. As a matter of completeness maybe it'd be nice
> > to know which register was intended yes but it's the first time I
> > fiddle with vim's source (with some pain) so I'm not too sure how much
> > work is involved in creating one of those v:somevar.
>
> OK, we can add it later when really needed.
>

Do we get it for free? :help v:register says it contains "the name of
the register in effect for the current normal mode command". It
certainly seems like it *could* contain the register used, though I'm
not sure whether the contents are lost before the autocmd fires.

[Philippe Vaucher]

> > > No because every delete/yank use the " register even if a register was
> > > explicitely specified. As a matter of completeness maybe it'd be nice
> > > to know which register was intended yes but it's the first time I
> > > fiddle with vim's source (with some pain) so I'm not too sure how much
> > > work is involved in creating one of those v:somevar.
>
> > OK, we can add it later when really needed.
>
> Do we get it for free? :help v:register says it contains "the name of
> the register in effect for the current normal mode command". It
> certainly seems like it *could* contain the register used, though I'm
> not sure whether the contents are lost before the autocmd fires.

Actually we do! Didn't know v:register existed, thanks!

Here's what I test it with:

autocmd! TextDeletePost * echom 'DeletePost: Register(' . v:register .
') Value(' . eval('@' . v:register) . ')'
autocmd! TextYankPost * echom 'YankPost: Register(' . v:register .
') Value(' . eval('@' . v:register) . ')'

Here's the (hopefully final) patch:

From 15a2f33bd2dd3d10d0f167e249546fcff8f7e9a0 Mon Sep 17 00:00:00 2001
From: Philippe Vaucher <philippe...@gmail.com>
Date: Tue, 24 May 2011 20:32:48 +0200
Subject: [PATCH] Add TextDeletePost and TextYankPost events

---
runtime/doc/autocmd.txt | 21 +++++++++++++++++++++
src/fileio.c | 2 ++
src/ops.c | 4 ++++
src/vim.h | 2 ++
4 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/runtime/doc/autocmd.txt b/runtime/doc/autocmd.txt
index 145ecf6..93fdefc 100644

--- a/runtime/doc/autocmd.txt
+++ b/runtime/doc/autocmd.txt
@@ -302,6 +302,9 @@ Name triggered by ~
|InsertCharPre| when a character was typed in Insert mode, before
inserting it

+|TextDeletePost| when some text is deleted (dw, dd, D)
+|TextYankPost| when some text is yanked (yw, yd, Y)

+
|ColorScheme| after loading a color scheme

|RemoteReply| a reply from a server Vim was received

@@ -670,6 +673,24 @@ InsertCharPre When a character is typed in

Insert mode,
It is not allowed to change the text |textlock|.
The event is not triggered when 'paste' is
set.

+ *TextDeletePost*
+TextDeletePost Just after a delete (|d|) command is issued.
+ Not issued if the black hole register
+ (|quote_|) is used. The affected text
can be
+ accessed by several ways, through @"
+ (|quotequote| or |v:register|: >
+ :echo @"
+ :echo eval('@' . v:register)
+<
+ *TextYankPost*
+TextYankPost Just after a |yank| (|y|) command is issued.
+ Not issued if the black hole register
+ (|quote_|) is used. The affected text
can be
+ accessed by several ways, through @"
+ (|quotequote| or |v:register|: >
+ :echo @"
+ :echo eval('@' . v:register)

+<
*InsertEnter*
InsertEnter Just before starting Insert mode. Also for
Replace mode and Virtual Replace mode. The
diff --git a/src/fileio.c b/src/fileio.c

index 6355c79..a794a04 100644

--- a/src/fileio.c
+++ b/src/fileio.c
@@ -7688,6 +7688,8 @@ static struct event_name
{"WinEnter", EVENT_WINENTER},
{"WinLeave", EVENT_WINLEAVE},
{"VimResized", EVENT_VIMRESIZED},

+ {"TextDeletePost", EVENT_TEXTDELETEPOST},
+ {"TextYankPost", EVENT_TEXTYANKPOST},

{NULL, (event_T)0}
};

diff --git a/src/ops.c b/src/ops.c

index c41f844..f5897b7 100644
--- a/src/ops.c
+++ b/src/ops.c
@@ -3160,6 +3160,10 @@ op_yank(oap, deleting, mess)
# endif
#endif

+ ++textlock;
+ apply_autocmds(deleting ? EVENT_TEXTDELETEPOST :
EVENT_TEXTYANKPOST, NULL, NULL, FALSE, curbuf);
+ --textlock;

+
return OK;

fail: /* free the allocated lines */
diff --git a/src/vim.h b/src/vim.h

index 1f4f17b..dc147cf 100644

--- a/src/vim.h
+++ b/src/vim.h
@@ -1290,6 +1290,8 @@ enum auto_event
EVENT_TABENTER, /* after entering a tab page */
EVENT_SHELLCMDPOST, /* after ":!cmd" */
EVENT_SHELLFILTERPOST, /* after ":1,2!cmd", ":w !cmd", ":r !cmd".
*/

+ EVENT_TEXTDELETEPOST, /* after a delete command was done (dd, dw,
D) */
+ EVENT_TEXTYANKPOST, /* after a yank command was done (yy, yw, Y)

*/
NUM_EVENTS /* MUST be the last one */
};

--

1.7.1

[Philippe Vaucher]

Ah, the_isz found the first bug already :)

When yanking/deleting with a visual range, the autocmd is triggered
twice.

I'll fix it and report.

[Philippe Vaucher]

Ok we did some tests and now everything works as it should.

For a better view of the patch, see
https://github.com/Silex/vim/commit/de0dd46e90fd7c6587492d3d7f8878d9f57f42f2

We tested with `vim -u NONE -U NONE --noplugin test.vim`, followed
by :so % and
test.vim being:

let s:count = 0

function! s:del_or_yank_event(desc)
echom s:count . ' ' . a:desc . ': Register(' . v:register . ')

Value(' . eval('@' . v:register) . ')'

let s:count += 1
endfunction

autocmd! TextDeletePost * call
<SID>del_or_yank_event('TextDeletePost')
autocmd! TextYankPost * call
<SID>del_or_yank_event('TextYankPost')

Tell me if there's an issue I forgot to address.

Here's the patch:

From de0dd46e90fd7c6587492d3d7f8878d9f57f42f2 Mon Sep 17 00:00:00 2001
From: Philippe Vaucher <philippe...@gmail.com>
Date: Wed, 25 May 2011 13:02:28 +0200

Subject: [PATCH] Add TextDeletePost and TextYankPost events

---
runtime/doc/autocmd.txt | 21 +++++++++++++++++++++
src/fileio.c | 2 ++

src/ops.c | 11 +++++++++++
src/vim.h | 2 ++
4 files changed, 36 insertions(+), 0 deletions(-)

index c41f844..5709aa5 100644
--- a/src/ops.c
+++ b/src/ops.c
@@ -1957,6 +1957,10 @@ op_delete(oap)

msgmore(curbuf->b_ml.ml_line_count - old_lcount);

+ ++textlock;
+ apply_autocmds(EVENT_TEXTDELETEPOST, NULL, NULL, FALSE, curbuf);
+ --textlock;
+
#ifdef FEAT_VIRTUALEDIT
setmarks:
#endif
@@ -3160,6 +3164,13 @@ op_yank(oap, deleting, mess)
# endif
#endif

+ if(mess && !deleting)
+ {
+ ++textlock;
+ apply_autocmds(EVENT_TEXTYANKPOST, NULL, NULL, FALSE,

curbuf);
+ --textlock;
+ }
+
return OK;

fail: /* free the allocated lines */
diff --git a/src/vim.h b/src/vim.h
index 1f4f17b..dc147cf 100644
--- a/src/vim.h
+++ b/src/vim.h
@@ -1290,6 +1290,8 @@ enum auto_event
EVENT_TABENTER, /* after entering a tab page */
EVENT_SHELLCMDPOST, /* after ":!cmd" */
EVENT_SHELLFILTERPOST, /* after ":1,2!cmd", ":w !cmd", ":r !cmd".
*/
+ EVENT_TEXTDELETEPOST, /* after a delete command was done (dd, dw,
D) */
+ EVENT_TEXTYANKPOST, /* after a yank command was done (yy, yw, Y)
*/
NUM_EVENTS /* MUST be the last one */
};

--

1.7.4.msysgit.0

[Philippe Vaucher]

So, Bram is that ok? Do you want the patch on another medium? Are
there issues I didn't address?

Thanks,
Philippe

[Bram Moolenaar]

Philippe Vaucher wrote:

> So, Bram is that ok? Do you want the patch on another medium? Are
> there issues I didn't address?

I need to have a closer look. Bugs usually have a higher priority than
new features.

--
hundred-and-one symptoms of being an internet addict:

131. You challenge authority and society by portnuking people

[Philippe Vaucher]

> I need to have a closer look.  Bugs usually have a higher priority than
> new features.

Hum, it's been a while now... should I create a ticket on
http://code.google.com/p/vim/issues/list so it's not forgotten?

In the meantime, we did some tests about potential problems with this
new feature:

test: autocmd! TextDeletePost * help :write
result:
Error detected while processing TextDeletePost Auto commands for
"*":
E523: Not allowed here: help :write

test: autocmd! TextDeletePost * bd
result:
Error detected while processing TextDeletePost Auto commands for
"*":
E523: Not allowed here: bd

test: autocmd! TextDeletePost * normal isometext
result: No error, but nothing inserted either

test: autocmd! TextDeletePost * normal dw
result: No error, but nothing deleted either


This looks fairly ok to me.
Philippe

[Philippe Vaucher]

Bram: this is just a message to bump this issue, to avoid that you
forget about it.

Thanks,
Philippe

[Bram Moolenaar]

Philippe Vaucher wrote:

> Bram: this is just a message to bump this issue, to avoid that you
> forget about it.

It's in the todo list. That list is very long, and bug fixes have
priority. Might take a while.

--
hundred-and-one symptoms of being an internet addict:

271. You collect hilarious signatures from all 250 mailing lists you
are subscribed to.

[Philippe Vaucher]

> It's in the todo list. That list is very long, and bug fixes have
> priority. Might take a while.

How long is that list? It's been more than 6 months now :/

Philippe

[Jürgen Krämer]

Hi,

:help todo

Regards,
J�rgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

[Thilo Six]

Hello

Excerpt from J�rgen Kr�mer:

-- <snip> --

>>> It's in the todo list. That list is very long, and bug fixes have
>>> priority. Might take a while.
>>
>> How long is that list? It's been more than 6 months now :/
>
> :help todo

Which might be out of date. The latest version is always available at:
https://vim.googlecode.com/hg/runtime/doc/todo.txt

> Regards,
> J�rgen
>

--
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F

[Philippe Vaucher]

> Which might be out of date. The latest version is always available at:
> https://vim.googlecode.com/hg/runtime/doc/todo.txt

Thanks.
Philippe

[Jan Larres]

Hi,

Do you maybe have a yankring-like plugin that makes use of the feature?
That could help people try it out in real-world scenarios.

Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
Technological progress has merely provided us with more efficient means for
going backwards.
-- Aldous Huxley

[Philippe Vaucher]

> Do you maybe have a yankring-like plugin that makes use of the feature?
> That could help people try it out in real-world scenarios.

Yes there is, see https://github.com/the-isz/MinYankRing.vim/tree/events

Philippe

[David Fishburn]

I will also add this to the YankRing plugin (script #1234).

I don't se the patch # to put a conditional check in for it.

Could someone let me know.

Thanks.

--
David Fishburn

> --
> You received this message from the "vim_dev" 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

[Benjamin R. Haskell]

On Sun, 18 Mar 2012, David Fishburn wrote:

> I will also add this to the YankRing plugin (script #1234).
>
> I don't se the patch # to put a conditional check in for it.

It hasn't been applied yet, but you shouldn't check by patch # anyway.
exists() can detect whether an autocommand for a particular event is
supported. Use:

exists('##TextDeleted')

and

exists('##TextYanked')

--
Best,
Ben

[David Fishburn]

Perfect thanks Ben.

--
David Fishburn

[Philippe Vaucher]

> It's in the todo list. That list is very long, and bug fixes have
> priority. Might take a while.

Bump :)

Philippe

[Philippe Vaucher]

Yawn... More than 2 years for a trivial patch like this.

https://github.com/Silex/vim/commit/de53ab72c89affa8ba77536ed8920751c037d127

Honestly, I'm disapointed. It's been a while I don't use vim anymore but I think vim deserves a more reactive development model than the current one.

Bram: I think you clearly need to nominate additional people to apply patches.

[Björn Linse]

For the record, a version of this was merged into neovim:
https://github.com/neovim/neovim/pull/4304

[Philippe Vaucher]

On Monday, February 29, 2016 at 4:13:31 PM UTC+1, Björn Linse wrote:
> For the record, a version of this was merged into neovim:
> https://github.com/neovim/neovim/pull/4304

Hehe, I just noticed that!

Thanks :-)

Sooooo reguarding vim, 6 years ago this was put in the TODO in the "As soon as possible" section. Today this patch still sits there... maybe... just maybe... is there some kind of problems with the patch submission process? *wink wink*

[Christian Brabandt]

Hi Philippe!

On Fr, 03 Mär 2017, Philippe Vaucher wrote:

> Sooooo reguarding vim, 6 years ago this was put in the TODO in the "As
> soon as possible" section. Today this patch still sits there...
> maybe... just maybe... is there some kind of problems with the patch
> submission process? *wink wink*

patch submission works fine. The problem is rather having those patches
applied. I am still waiting for getting the vartabs feature included,
which was initially posted 10 years ago.


Best,
Christian
--
Demokratie ist nichts anderes, als das Niederknüppeln des Volkes durch
das Volk für das Volk.
-- Oscar Wilde

[Bram Moolenaar]

I don't recall anyone asking for this feature in the past six years.
If there was a discussion about how this is useful for more than one
user, it would have been moved up in the todo list.

Including just every patch available leads to a mess. Also,
autocommands are a clumsy mechanism, thus I hesitate to add more of it.

I had a brief look at the comments, and it appears the functionality
would be better done with some kind of callback.

--
Never overestimate a man's ability to underestimate a woman.

[Ben Fritz]

On Saturday, March 4, 2017 at 6:47:33 AM UTC-6, Bram Moolenaar wrote:
> Philippe Vaucher wrote:
>
> > On Monday, February 29, 2016 at 4:13:31 PM UTC+1, Björn Linse wrote:
> > > For the record, a version of this was merged into neovim:
> > > https://github.com/neovim/neovim/pull/4304
> >
> > Hehe, I just noticed that!
> >
> > Thanks :-)
> >
> > Sooooo reguarding vim, 6 years ago this was put in the TODO in the "As
> > soon as possible" section. Today this patch still sits there...
> > maybe... just maybe... is there some kind of problems with the patch
> > submission process? *wink wink*
>
> I don't recall anyone asking for this feature in the past six years.
> If there was a discussion about how this is useful for more than one
> user, it would have been moved up in the todo list.
>
> Including just every patch available leads to a mess. Also,
> autocommands are a clumsy mechanism, thus I hesitate to add more of it.
>
> I had a brief look at the comments, and it appears the functionality
> would be better done with some kind of callback.
>

Aren't autocmds basically Vim's way of doing callbacks?

I don't personally feel the need for one, but I know many people would like a "yank ring" style of plugin or other sort of clipboard management which this patch would enable.

[David Fishburn]

...

 

I don't personally feel the need for one, but I know many people would like a "yank ring" style of plugin or other sort of clipboard management which this patch would enable.

FYI:

YankRing.vim : Maintains a history of previous yanks, changes and deletes

http://www.vim.org/scripts/script.php?script_id=1234 

David

[Bram Moolenaar]

Ben Fritz wrote:

> On Saturday, March 4, 2017 at 6:47:33 AM UTC-6, Bram Moolenaar wrote:
> > Philippe Vaucher wrote:
> >
> > > On Monday, February 29, 2016 at 4:13:31 PM UTC+1, Björn Linse wrote:
> > > > For the record, a version of this was merged into neovim:
> > > > https://github.com/neovim/neovim/pull/4304
> > >
> > > Hehe, I just noticed that!
> > >
> > > Thanks :-)
> > >
> > > Sooooo reguarding vim, 6 years ago this was put in the TODO in the "As
> > > soon as possible" section. Today this patch still sits there...
> > > maybe... just maybe... is there some kind of problems with the patch
> > > submission process? *wink wink*
> >
> > I don't recall anyone asking for this feature in the past six years.
> > If there was a discussion about how this is useful for more than one
> > user, it would have been moved up in the todo list.
> >
> > Including just every patch available leads to a mess. Also,
> > autocommands are a clumsy mechanism, thus I hesitate to add more of it.
> >
> > I had a brief look at the comments, and it appears the functionality
> > would be better done with some kind of callback.
> >
>
> Aren't autocmds basically Vim's way of doing callbacks?

Yes, in a quite clumsy way. Especially the way arguments are passed to
the commands being executed. And how state needs to be saved and
restored. I have often wondered what would be a proper solution, but I
don't have a concrete proposal.

Another problem with autocommands is that the caller can do anything.
Such as a BufReadPre could open a new window. Thus the Vim code
triggering the autocommand has to be extremely careful about assuming
the current state. And need to abort the command sometimes. Anyway,
using a callback mechanism probably won't solve that. But the point
where it is called could help.

> I don't personally feel the need for one, but I know many people would
> like a "yank ring" style of plugin or other sort of clipboard
> management which this patch would enable.

Each problem usually has several ways of dealing with it. Just taking
the first solution that comes to mind is often wrong, it may lead to the
need for another solution later, when it turns out that the first
solution doesn't cover all use cases.

--
hundred-and-one symptoms of being an internet addict:

71. You wonder how people walk