How to test whether any code runs after same command invocation?

How to test whether any code runs after same command invocation?

[Michael Heerdegen]

Hello,

This is a simple task I face quite often: Consider some piece of code
runs at different times, and you want to distinguish whether the last
time this code was run was before the current command invocation or not
(i.e., whether the code was run multiple times for the same command -
I mean the same command _call_).

Example: I use some code that propertizes any dired buffer in a way that
the mouse tooltip over any directory shows the directory contents.
Since that can take a long time for huge directory hierarchies, I want
to use a timeout.  But if you have marked files you operate on, the code
is run multiple times when refreshing the files' lines, so the timeout
must be relative to command invocation, it must not be reset to 0 when
the code is run anew.

I currently do this by (defvar counter 0) and adding a fun to
post-command-hook that increases the counter.  Is there a cleverer way?
Something of the form

(eq foo (setq foo (clever-expression)))

without the need to push to any hook?

Thanks!

Michael.

Re: How to test whether any code runs after same command invocation?

[Stefan Monnier]

> Example: I use some code that propertizes any dired buffer in a way that
> the mouse tooltip over any directory shows the directory contents.
> Since that can take a long time for huge directory hierarchies, I want
> to use a timeout.  But if you have marked files you operate on, the code
> is run multiple times when refreshing the files' lines, so the timeout

Not sure I understand.  Do you use after-change-functions, by any chance?
Could you use jit-lock instead?

> I currently do this by (defvar counter 0) and adding a fun to
> post-command-hook that increases the counter.

That sounds like the standard hack, yes.

> Is there a cleverer way?

In general, not that I know.
You can also use wall-time instead of a counter incremented in
post-command-hook.


        Stefan

Re: How to test whether any code runs after same command invocation?

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > Example: I use some code that propertizes any dired buffer in a way that
> > the mouse tooltip over any directory shows the directory contents.
> > Since that can take a long time for huge directory hierarchies, I want
> > to use a timeout.  But if you have marked files you operate on, the code
> > is run multiple times when refreshing the files' lines, so the timeout
>
> Not sure I understand.  Do you use after-change-functions, by any
> chance?

I after-advice dired-insert-set-properties.  

> Could you use jit-lock instead?

I didn't want to cope with that.  Also, this was just an example, I have
other, quite different use cases of the raised issue.

> > Is there a cleverer way?
>
> In general, not that I know.
> You can also use wall-time instead of a counter incremented in
> post-command-hook.

What's that?  Don't find it anywhere.  Is it a C variable?  In that case
I can't use it.


Thanks,

Michael.

Re: How to test whether any code runs after same command invocation?

[Stefan Monnier]

>> > Example: I use some code that propertizes any dired buffer in a way that
>> > the mouse tooltip over any directory shows the directory contents.
>> > Since that can take a long time for huge directory hierarchies, I want
>> > to use a timeout.  But if you have marked files you operate on, the code
>> > is run multiple times when refreshing the files' lines, so the timeout
>> Not sure I understand.  Do you use after-change-functions, by any
>> chance?
> I after-advice dired-insert-set-properties.

Then why is the code run multiple times?

> I didn't want to cope with that.  Also, this was just an example, I have
> other, quite different use cases of the raised issue.

The general idea might still apply: try and make it lazier.  E.g. change
your code so that rather than doing the job right away, it just writes
down somewhere what jobs needs to be done, and then later (e.g. in
post-command-hook, jit-lock, timer, you name it) look at what was
written down (if anything) and do it then, once.
Of course, it can't always be done.

> What's that?

"Wall clock" is this thing that you can get from your watch, your phone,
or the `current-time' function ;-)


        Stefan

Re: How to test whether any code runs after same command invocation?

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > I after-advice dired-insert-set-properties.
>
> Then why is the code run multiple times?

If you operate on several (marked) files, each file's line is refreshed
individually.  Then the code is called several times (contrary to
e.g. just hitting g) after one command invocation.

> > I didn't want to cope with that.  Also, this was just an example, I
> > have other, quite different use cases of the raised issue.
>
> The general idea might still apply: try and make it lazier.  E.g. change
> your code so that rather than doing the job right away, it just writes
> down somewhere what jobs needs to be done, and then later (e.g. in
> post-command-hook, jit-lock, timer, you name it) look at what was
> written down (if anything) and do it then, once.

Indeed, that would be a much better approach, although this requires
some more effort.

> "Wall clock" is this thing that you can get from your watch, your
> phone,

I'm not so accustomed to such physical things...

> or the `current-time' function ;-)

Oh, that's what you meant, ok, I understand.


Many thanks, Stefan!

Michael.

Re: How to test whether any code runs after same command invocation?

[Stefan Monnier]

>> > I after-advice dired-insert-set-properties.
>> Then why is the code run multiple times?
> If you operate on several (marked) files, each file's line is refreshed
> individually.  Then the code is called several times (contrary to
> e.g. just hitting g) after one command invocation.

But your code can limit itself to beg..end so while it will be called
several times, it will only be run once for any given part of the buffer.


        Stefan

Re: How to test whether any code runs after same command invocation?

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But your code can limit itself to beg..end so while it will be called
> several times, it will only be run once for any given part of the
> buffer.

Yes, that's why I advised (dired-insert-set-properties BEG END).  What I
have already is short and works quite effective.  The question was
really just about the abstract counter thing, and if it can be
substituted with something simple I wasn't aware of.

Many thanks,

Michael.

Re: How to test whether any code runs after same command invocation?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Fri, 14 Feb 2014 12:15:12 -0500

   The general idea might still apply: try and make it lazier.
   E.g. [create a future].

Another way to be lazy is to do nothing if there is pending input.
BTW, this should probably be on help-gnu-emacs.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: How to test whether any code runs after same command invocation?

[Michael Heerdegen]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> Another way to be lazy is to do nothing if there is pending input.

Yes, but that approach doesn't help in my case.

> BTW, this should probably be on help-gnu-emacs.

Thanks, I wasn't sure about that.  I thought questions about developing
Emacs addons fit here, but emacs-dev is only about developing vanilla
Emacs itself, right?  Sorry, then.

Michael.

Re: How to test whether any code runs after same command invocation?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

() Michael Heerdegen <michael_heerdegen@web.de>
() Sat, 15 Feb 2014 11:36:35 +0100

   > Another way to be lazy is to do nothing if there is pending input.

   Yes, but that approach doesn't help in my case.

Oops, sorry for the noise.

   > BTW, this should probably be on help-gnu-emacs.

   Thanks, I wasn't sure about that.  I thought questions about
   developing Emacs addons fit here, but emacs-dev is only about
   developing vanilla Emacs itself, right?  Sorry, then.

No worries.  In this case i suppose the issue pertains to both just
fine.  IMHO, it's nicer to see a solution using existing facilities on
help-, and one using new facilities (or conventions) on -devel, but if
in the end everyone who reads one reads the other, there is distinction
not in substance, only in style.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]