Re: InsertEnter cursor position related

49 views
Skip to first unread message

Bram Moolenaar

unread,
May 18, 2013, 7:21:15 AM5/18/13
to troydm, vim...@googlegroups.com

Troydm (?) wrote:

> v7-3-768 commit introduced following check for InsertEnter autocommand
> event execution e.g. calling check_cursor_col()
>
> http://pastebin.com/tShmNDDz
>
> However after this commit some of my plugins that heavily rely on InsertEnter
> stopped working namely because some of those plugins change cursor
> position on autocommand event thus making those changes obsolete and
> cursor position not changing
>
> As i see this is a bug however i'm not sure if it's a bug or expected
> behavior
>
> The way to fix this is to save cursor position only after autocommand
> event is executed e.g. moving following line
>
> pos_T save_cursor = curwin->w_cursor;
>
> after this call
>
> apply_autocmds(EVENT_INSERTENTER, NULL, NULL, FALSE, curbuf);
>
> So is this a bug or not?

The documentation says that the InsertEnter autocommand must not move
the cursor:

InsertEnter Just before starting Insert mode. Also for
Replace mode and Virtual Replace mode. The
|v:insertmode| variable indicates the mode.
Be careful not to move the cursor or do
anything else that the user does not expect.

Why do you want to move the cursor, what is it for?

--
User: I'm having problems with my text editor.
Help desk: Which editor are you using?
User: I don't know, but it's version VI (pronounced: 6).
Help desk: Oh, then you should upgrade to version VIM (pronounced: 994).

/// 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 ///

troydm

unread,
May 18, 2013, 4:09:55 PM5/18/13
to vim...@googlegroups.com, troydm

Well for example one of my plugins includes bash shell emulation inside a vim buffer, it's called shellasync.vim and it's source code is at https://github.com/troydm/shellasync.vim, it uses InsertEnter to check if user went into insert mode while his cursor was on prefix of shell e.g. '$' symbol and if it does it just automaticly moves cursor on 3rd col instead. For a user of my plugin (atleast for me) this is an expected behaviour

troydm

unread,
May 18, 2013, 4:18:37 PM5/18/13
to vim...@googlegroups.com
Also as it is now i can move a cursor from InsertEnter as long as it's moved on a different line (not the same line)

for example open some multi line file

do

:au InsertEnter <buffer> normal! 3jl

try entering insert mode on the first line (it works)

now reopen some other multiline file and do

:au InsertEnter <buffer> normal! 3l

And it doesn't works

Bram Moolenaar

unread,
May 18, 2013, 5:23:24 PM5/18/13
to troydm, vim...@googlegroups.com

Troydm (?) wrote:

> Well for example one of my plugins includes bash shell emulation
> inside a vim buffer, it's called shellasync.vim and it's source code
> is at https://github.com/troydm/shellasync.vim, it uses InsertEnter to
> check if user went into insert mode while his cursor was on prefix of
> shell e.g. '$' symbol and if it does it just automaticly moves cursor
> on 3rd col instead. For a user of my plugin (atleast for me) this is
> an expected behaviour

You can use the CursorMovedI event instead. If it's slow you can set a
flag in InsertEnter and only do something in CursorMovedI when it' set.
Hmm, I suppose it doesn't work for the "i" command, the cursor doesn't
move then. You would have to map it.

--
ARTHUR: No, hang on! Just answer the five questions ...
GALAHAD: Three questions ...
ARTHUR: Three questions ... And we shall watch ... and pray.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

Bram Moolenaar

unread,
May 18, 2013, 5:23:23 PM5/18/13
to troydm, vim...@googlegroups.com
That's a bug. The check for the line is to avoid going outside of the
available lines when the text has changed.

--
Permission is granted to read this message out aloud on Kings Cross Road,
London, under the condition that the orator is properly dressed.

troydm

unread,
May 18, 2013, 5:53:16 PM5/18/13
to vim...@googlegroups.com, troydm
On Sunday, May 19, 2013 1:23:23 AM UTC+4, Bram Moolenaar wrote:
>
>
> That's a bug. The check for the line is to avoid going outside of the
>
> available lines when the text has changed.
>

You mean check_cursor_col() call is to check for the line to avoid going outside of the available lines when text has changed i presume?
So what is the proposed fix?

commenting/removing this line?
curwin->w_cursor = save_cursor;

troydm

unread,
May 18, 2013, 5:57:20 PM5/18/13
to vim...@googlegroups.com, troydm

Wait, isn't check_cursor_col() called only when line number hasn't changed, and that is when cursor's position is resetted to value before event call

Bram Moolenaar

unread,
May 19, 2013, 3:04:12 PM5/19/13
to troydm, vim...@googlegroups.com
Well, if text got deleted the saved cursor position may no longer be
valid.

Hmm, that would be a problem though. If the autocommand removed text
and positioned the cursor where it should be it will be restored in the
wrong position.

Most InsertEnter autocommands will not change text, restoring the cursor
is useful then. But we need some way to avoid restoring the cursor.
We could use the v:char variable perhaps.

--
There is no right or wrong, there is only your personal opinion.
(Bram Moolenaar)

troydm

unread,
May 19, 2013, 3:46:10 PM5/19/13
to vim...@googlegroups.com, troydm

Thanks, works perfectly

Reply all
Reply to author
Forward
0 new messages