[PATCH] New autocmds: OperationPending, OperationExecuted, OperationCleared

64 views
Skip to first unread message

Mohammed Chelouti

unread,
Oct 10, 2012, 4:30:13 PM10/10/12
to vim...@vim.org

Hello

 

I have written a plugin[1] for Vim that enables relative line numbers for pending operations. Unfortunately it's kinda messy to get to 'know' when an operation is pending and when it is executed. You have to remap every operator-command to call your specific plugin function (something like: nnoremap d :call MyFunc()<CR>d). Of course this leads to the problem that you cannot use more than one plugin that needs to know when you are in operation-pending mode. Additionally you somehow need to remap operations that come from other plugins.

 

A much more elegant solution would be to have an event to be called when an operation is pending. I've looked at the Vim code and added the following three autocommands:

- OperationPending: is executed when an operation is called which needs a motion.

- OperationExecuted: is executed after the pending operation was executed (i.e. a motion or a second keystroke like yy, dd etc. is passed).

- OperationCleared: is executed after every command that doesn't enter operation-pending-mode. (executed after OperationExecuted)

 

I hope you see the reasoning behind my request and add my patch to Vim.

 

I haven't found any hint about your preferred patch format, so I just attached the 'hg diff' output.

 

Best regards,

Mohammed

 

[1] http://www.vim.org/scripts/script.php?script_id=4212

operation_autocmds.patch

Ben Fritz

unread,
Oct 10, 2012, 5:16:15 PM10/10/12
to vim...@googlegroups.com, vim...@vim.org, mh...@web.de
On Wednesday, October 10, 2012 3:30:13 PM UTC-5, Mohammed Chelouti wrote:
>
> I've looked at the Vim code and added the following three autocommands:
>
> - OperationPending: is executed when an operation is called which needs a motion.
> - OperationExecuted: is executed after the pending operation was executed (i.e. a motion or a second keystroke like yy, dd etc. is passed).
> - OperationCleared: is executed after every command that doesn't enter operation-pending-mode. (executed after OperationExecuted)
>

I can see why the first two are needed for taking actions in operator pending mode. But why is the third needed?

Mohammed Chelouti

unread,
Oct 10, 2012, 6:01:37 PM10/10/12
to vim...@googlegroups.com

Because a pending operation triggers OperationExecuted only when the operation is really executed.

E.g. place your cursor on the first line and hit dk. This will leave operation pending mode but won't execute the operation. Additionally actions like hitting <Esc> or <C-c> or just leaving the buffer won't execute the operation, either.

David Fishburn

unread,
Oct 11, 2012, 8:47:49 AM10/11/12
to vim...@googlegroups.com
On Wed, Oct 10, 2012 at 4:30 PM, Mohammed Chelouti <mh...@web.de> wrote:
...
> A much more elegant solution would be to have an event to be called when an
> operation is pending. I've looked at the Vim code and added the following
> three autocommands:
>
> - OperationPending: is executed when an operation is called which needs a
> motion.
>
> - OperationExecuted: is executed after the pending operation was executed
> (i.e. a motion or a second keystroke like yy, dd etc. is passed).
>
> - OperationCleared: is executed after every command that doesn't enter
> operation-pending-mode. (executed after OperationExecuted)

Mohammed,

What information is available within these events?
Usually this is through some v: scoped variable or something like
<a:file> and so on.

I would expect the usual stuff like:

v:register - Register currently being operated on
v:operator - Current operator (i.e. "f" for cf)
v:count - Count given for the command

Right now, the YankRing plugin had to create expression maps for these
and prompt the user for the remaining part of the command. It sounds
like I could use this feature instead of some of those maps, if the
required information is available.

Thanks,
Dave

Mohammed Chelouti

unread,
Oct 11, 2012, 9:36:48 AM10/11/12
to vim...@googlegroups.com
On Thursday 11 October 2012 08:47:49 David Fishburn wrote:
> What information is available within these events?
> Usually this is through some v: scoped variable or something like
> <a:file> and so on.
>
> I would expect the usual stuff like:
>
> v:register - Register currently being operated on
> v:operator - Current operator (i.e. "f" for cf)
> v:count - Count given for the command
>
> Thanks,
> Dave

Hello Dave

The v:variables you mentioned work as expected.
So the command 4"adk would give

v:count = 4
v:register = a
v:operator = d

Best,
Mohammed

Bram Moolenaar

unread,
Oct 11, 2012, 10:03:29 PM10/11/12
to Mohammed Chelouti, vim...@vim.org
The problem with autocommands is that they can do lots of things that
the code where they are triggered from does not expect. It's not
unusual for Vim to crash. Try changing to another buffer, moving the
cursor, closing the window, renaming the buffer, etc. It is very
difficult to handle every single one of these. We still find problems
with existing autocommands.

Perhaps there is another way to do what you want?

--
The Characters and incidents portrayed and the names used are fictitious and
any similarity to the names, characters, or history of any person is entirely
accidental and unintentional.
Signed RICHARD M. NIXON
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

Mohammed Chelouti

unread,
Oct 15, 2012, 6:26:18 PM10/15/12
to vim...@googlegroups.com
On Friday 12 October 2012 04:03:29 Bram Moolenaar wrote:
> The problem with autocommands is that they can do lots of things that
> the code where they are triggered from does not expect. It's not
> unusual for Vim to crash. Try changing to another buffer, moving the
> cursor, closing the window, renaming the buffer, etc. It is very
> difficult to handle every single one of these. We still find problems
> with existing autocommands.
>
> Perhaps there is another way to do what you want?

My plugin unfortunately breaks default Vim functionality (<count>{dd,yy,cc
etc}) and as mentioned in my first mail, other plugins using the default Vim
operations may not work with mine (or vice versa).
I tried to fix that with VimL but without success. This patch was my last
resort to fix my problems rather than to add a nice to have feature. But I
fully understand your concerns.

Thank you anyways.

Best,
Mohammed

Reply all
Reply to author
Forward
0 new messages