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.
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?
On Wednesday 10 October 2012 14:16:15 Ben Fritz wrote:
> 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?
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.
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.
Mohammed Chelouti wrote:
> 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.
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
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.
