CursorLineMoved

[Edward Peschko]

All,

I'd like to be able to write a macro that could be triggered each time the line changed - so that I could write an autocmd to say automatically split a logfile in vim that has stack traces to show the corresponding code for each line in that stack trace.

However, the closest thing that was brought to my attention was CursorMoved, which IMO is way too broad. After all I don't want a potentially expensive macro to be done *every* single time the cursor is moved, just when it moves lines.

So I was thinking CursorLineMoved. Is there such a thing? If not, it looks fairly easy to add, but i'm not all that keen on supporting my own vim, so would a patch like this be welcomed?

Thanks much and feedback welcome..

Ed

[Ingo Karkat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13-May-2019 21:20 +0200, Edward Peschko wrote:

> All,
>
> I'd like to be able to write a macro that could be triggered each time
> the line changed - so that I could write an autocmd to say
> automatically split a logfile in vim that has stack traces to show the
> corresponding code for each line in that stack trace.
>
> However, the closest thing that was brought to my attention was
> CursorMoved, which IMO is way too broad. After all I don't want a
> potentially expensive macro to be done *every* single time the cursor
> is moved, just when it moves lines.

I've encountered the same use case (also around logfile processing - the
conditional is here [1]); if you do a quick comparison with the stored
last line number at the beginning of the :autocmd and return early if
the line hasn't changed, the performance seems to be okay (for me, so
far).

> So I was thinking CursorLineMoved. Is there such a thing? If not, it
> looks fairly easy to add, but i'm not all that keen on supporting my
> own vim, so would a patch like this be welcomed?

This doesn't exist yet. To consider such an addition:
- - Is there a need? Now, we've already got at least two use cases (from
you and me).
- - Is it easy to implement with few changes? You say it is.
- - Does it help improving performance? If the core C code essentially
does the same as a Vimscript would do, all we'd save is a little
interpretation overhead. But if there's a better place (e.g. the
'cursorline' drawing code also has to consider the current line
number), it could be more efficient.
- - Does it improve the Vimscript API? A dedicated CursorLineMoved event
type provides precise semantics, and would avoid boilerplate code (if
just a single conditional here).
- - Is this easy to emulate? Only future Vim versions will have the new
event. Plugin writers still have to provide a fallback implementation
for older versions. Here, I think this is not a problem, as this is
just about efficiency gains.

- -- regards, ingo

[1] https://github.com/inkarkat/vim-LogViewer/blob/eb5f2601d3521b001612002d609386713d2ad707/autoload/LogViewer.vim#L200-L203
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJc3S1pAAoJEA7ziXlAzQ/vwXEH/1DJ5Gs/wv3/gSpnimVEa9SX
lEAtcaGgD3ko7J88rla1l4HoyQddOwRiLoqvKrlobC7QbizLHJsCXEHa1LL0/6Q0
ImduN5PQxUIml5J5EbH2pBvfLvSqjOWKLrIiLbnjuMLBMJXr3Ia4XbVyEPCgHMdu
cG0X0pqtlJw2+pozYxWUj5bYETmd4OgWqOajPRXZZzGUG37O7dJvlvIuDVctlZtF
OWRcaS2BGMy5yX0ZRTnmbXlv7wpEs3KhMo5G7GcXiid2o4yIZwRLgAXReiRT3lbH
gr1jKgxMFObUVTBnbYy+OHxOtIyfGS+aHyb9SazJxmpE0is7Wpy0zZ2tFvEyf/I=
=SLMR
-----END PGP SIGNATURE-----

[Paul Jolly]

> This doesn't exist yet. To consider such an addition:
> - - Is there a need? Now, we've already got at least two use cases (from
> you and me).
> - - Is it easy to implement with few changes? You say it is.
> - - Does it help improving performance? If the core C code essentially
> does the same as a Vimscript would do, all we'd save is a little
> interpretation overhead. But if there's a better place (e.g. the
> 'cursorline' drawing code also has to consider the current line
> number), it could be more efficient.
> - - Does it improve the Vimscript API? A dedicated CursorLineMoved event
> type provides precise semantics, and would avoid boilerplate code (if
> just a single conditional here).
> - - Is this easy to emulate? Only future Vim versions will have the new
> event. Plugin writers still have to provide a fallback implementation
> for older versions. Here, I think this is not a problem, as this is
> just about efficiency gains.

The only thing I would suggest we consider at the same time is an
event that is triggered pre/post viewport changes. And by viewport, I
mean the information returned by getwininfo() (minus the variable
key), along with the current window number. Current line number
could/should be part of this.

My proposed use case here is an AST-based syntax highlighting.

I will note however that this would likely require some changes to
matchaddpos/deletematch to make them more batch friendly.

In https://github.com/myitcv/govim/pull/24 I have simulated such a
viewport changed event using timers (ideally I would have the new
highlights be added in response to the pre viewport changed event).
But the lag because of the multiple calls required to
matchaddpos/deletepos over a channel start to become apparent.

Thanks

[Christian Brabandt]

On Do, 16 Mai 2019, Paul Jolly wrote:

> > This doesn't exist yet. To consider such an addition:
> > - - Is there a need? Now, we've already got at least two use cases (from
> > you and me).
> > - - Is it easy to implement with few changes? You say it is.
> > - - Does it help improving performance? If the core C code essentially
> > does the same as a Vimscript would do, all we'd save is a little
> > interpretation overhead. But if there's a better place (e.g. the
> > 'cursorline' drawing code also has to consider the current line
> > number), it could be more efficient.
> > - - Does it improve the Vimscript API? A dedicated CursorLineMoved event
> > type provides precise semantics, and would avoid boilerplate code (if
> > just a single conditional here).
> > - - Is this easy to emulate? Only future Vim versions will have the new
> > event. Plugin writers still have to provide a fallback implementation
> > for older versions. Here, I think this is not a problem, as this is
> > just about efficiency gains.

I am against it as long as current vimscript solutions are being able to
handle this case (which seems to be the case).

>
> The only thing I would suggest we consider at the same time is an
> event that is triggered pre/post viewport changes. And by viewport, I
> mean the information returned by getwininfo() (minus the variable
> key), along with the current window number. Current line number
> could/should be part of this.
>
> My proposed use case here is an AST-based syntax highlighting.
>
> I will note however that this would likely require some changes to
> matchaddpos/deletematch to make them more batch friendly.
>
> In https://github.com/myitcv/govim/pull/24 I have simulated such a
> viewport changed event using timers (ideally I would have the new
> highlights be added in response to the pre viewport changed event).
> But the lag because of the multiple calls required to
> matchaddpos/deletepos over a channel start to become apparent.

See https://github.com/vim/vim/issues/3127 for that I think.

Best,
Christian
--
Das ist die wahre Symbolik, wo das Besondere das Allgemeinere
repräsentiert, nicht als Traum und Schatten, sondern als lebendig
augenblickliche Offenbarung des Unerforschlichen.
-- Goethe, Maximen und Reflektionen, Nr. 451

[Paul Jolly]

> See https://github.com/vim/vim/issues/3127 for that I think.

Indeed, just so long as this is triggered for all visible windows when
their viewport changes (e.g. window resize)

[Paul Jolly]

> > See https://github.com/vim/vim/issues/3127 for that I think.
>
> Indeed, just so long as this is triggered for all visible windows when
> their viewport changes (e.g. window resize)

Sorry, that sent too quickly. I meant to finish by saying thank you
for linking to that issue; I've now added a comment there and linked
back to this discussion.

Best,


Paul