Re: triggering macro on navigation to new line

Gary,

Yes I was thinking of that - a special check - but any perceptible
delay on the part of vim for what is such a common operation
(basically any operation) really goes against what I'm trying to get
at here usability wise. I really want this to be as close to a zero
cost operation as possible.

Plus there is always the cost of eval. I'm not sure if vim saves
internal vimscript compiles of a given macro for future evals of the
same macro. How much of a startup time would those checks impose? And
my ultimate language of choice would either be perl or python so
people could configure it without knowing vim regular expressions, and
i'm not sure if vim stores perl/python as bytecode either, or
(shudder) actually executes a subprocess.

In any case I'll play around with it and thanks for all the info.

On Mon, May 13, 2019 at 12:52 PM Gary Johnson <garyjohn@spocom.com> wrote:
>
> On 2019-05-13, Ed Peschko wrote:
> > Gary,
> >
> > thanks for this tip, yes it looks like I could use it to do what I
> > want but my concern is speed. I don't want to trigger a potentially
> > expensive macro each time the cursor moves anytime, just when the line
> > number changes.
> >
> > So perhaps there is a need for CursorLineMoved? I see in vim where I
> > might be added, but I haven't contributed patches to vim before, so
> > i'm not sure on how to go about it.
>
> I don't think we need Yet Another Event for this special case. The
> usual approach to this sort of problem is to make an inexpensive
> test early in the process so that you don't spend time considering
> cases you don't care about. In this case, you could cache the last
> cursor line location and test against that early in the
> autocommand command, perhaps something like this:
>
> :let g:prev_line = 0
> :au CursorMoved if line('.') != g:prev_line
> \ | let g:prev_line = line('.')
> \ | " other stuff
> \ | endif
>
> Note that you could have just jumped to the same line number in
> a different buffer, so you should test the buffer number, too,
> perhaps with getcurpos() instead of line() to get both the buffer
> number and the line number.
>
> Regards,
> Gary
>
> --
> --
> You received this message from the "vim_use" 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
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190513195231.GC12153%40phoenix.
> For more options, visit https://groups.google.com/d/optout.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CACQ%2BYcvxn-dGgRG%3DUQJp_W92hs4peWBzujp0fb3GHXMKFbCvPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.