GNU bug report logs - #52023
27.2; Enhancement: `this-command-invocation-(buffer|window)'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52023 in the body.
You can then email your comments to 52023 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
Date: Sun, 21 Nov 2021 18:11:51 +0000

Enhancement request: please consider adding functions
`this-command-invocation-buffer' and `this-command-invocation-window'.
(Other names OK.)

They would return, respectively, the buffer that was current, and the
window that was selected, when the command that's the value of
`this-command' was invoked.

Currently, to get this information a workaround would be to use a
`pre-command-hook' function that sets variables, and then to test those
variables.

In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.1288)

Message #8 received at 52023 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 52023 <at> debbugs.gnu.org
Subject: Re: bug#52023: 27.2; Enhancement:
 `this-command-invocation-(buffer|window)'
Date: Sun, 21 Nov 2021 21:19:04 +0200

> Enhancement request: please consider adding functions
> `this-command-invocation-buffer' and `this-command-invocation-window'.
> (Other names OK.)
>
> They would return, respectively, the buffer that was current, and the
> window that was selected, when the command that's the value of
> `this-command' was invoked.
>
> Currently, to get this information a workaround would be to use a
> `pre-command-hook' function that sets variables, and then to test those
> variables.

Maybe these functions give what you need?

  (old-selected-window)
  (window-buffer (old-selected-window))

Message #11 received at 52023 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: "52023 <at> debbugs.gnu.org" <52023 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#52023: 27.2; Enhancement:
 `this-command-invocation-(buffer|window)'
Date: Sun, 21 Nov 2021 21:36:49 +0000

> > Enhancement request: please consider adding functions
> > `this-command-invocation-buffer' and `this-command-invocation-window'.
> > (Other names OK.)
> >
> > They would return, respectively, the buffer that was current, and the
> > window that was selected, when the command that's the value of
> > `this-command' was invoked.
> >
> > Currently, to get this information a workaround would be to use a
> > `pre-command-hook' function that sets variables, and then to test those
> > variables.
> 
> Maybe these functions give what you need?
> 
>   (old-selected-window)
>   (window-buffer (old-selected-window))

Thanks for looking into this.  I wasn't
aware of that function.

But I don't see how it provides either of
the requested functions.

As for the second sexp you show: the buffer
that's current when a command is invoked
need not be displayed in any window.

As for the first (function `old-*'), the
doc says ~ it's the window selected at the
time of (before? after?) the last window
change.

It's not clear to me whether that's the
`selected-window' when this-command was
invoked.  Is it? always?

(The doc string for that `old-*' function
seems unclear to me.  What's the spec for
the "window selected the last time window
change functions were run"?  Is that the
`selected-window' just before those
functions were run?  Is it a window that
gets selected by running those functions?)

Message #14 received at 52023 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "52023 <at> debbugs.gnu.org" <52023 <at> debbugs.gnu.org>
Subject: Re: [External] : Re: bug#52023: 27.2; Enhancement:
 `this-command-invocation-(buffer|window)'
Date: Mon, 22 Nov 2021 10:06:10 +0200

>> Maybe these functions give what you need?
>>
>>   (old-selected-window)
>>   (window-buffer (old-selected-window))
>...
> As for the second sexp you show: the buffer
> that's current when a command is invoked
> need not be displayed in any window.

It seems there is no such thing as `old-current-buffer'
like there is `current-minibuffer-command'.

> As for the first (function `old-*'), the
> doc says ~ it's the window selected at the
> time of (before? after?) the last window
> change.
>
> It's not clear to me whether that's the
> `selected-window' when this-command was
> invoked.  Is it? always?

I don't know what `old-selected-window' returns when
more window changes were performed by the same command.
But in any case you can use `pre-command-hook' to store
the original buffer and window.

Message #19 received at 52023 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: "52023 <at> debbugs.gnu.org" <52023 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#52023: 27.2; Enhancement:
 `this-command-invocation-(buffer|window)'
Date: Mon, 22 Nov 2021 15:17:54 +0000

> But in any case you can use `pre-command-hook' to store
> the original buffer and window.

Please the bug report.  It includes this:

  Currently, to get this information a workaround
  would be to use a `pre-command-hook' function
  that sets variables, and then to test those variables.

Message #22 received at 52023 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "52023 <at> debbugs.gnu.org" <52023 <at> debbugs.gnu.org>
Subject: Re: [External] : Re: bug#52023: 27.2; Enhancement:
 `this-command-invocation-(buffer|window)'
Date: Mon, 22 Nov 2021 19:46:37 +0200

>> But in any case you can use `pre-command-hook' to store
>> the original buffer and window.
>
> Please the bug report.  It includes this:

A verb is missing.  I assume you meant: "Please close the bug report"?

>   Currently, to get this information a workaround
>   would be to use a `pre-command-hook' function
>   that sets variables, and then to test those variables.

Indeed, `pre-command-hook' could be used to set these variables,
and other possible variables.  There are much worse problems
while using window-configuration-change-hook.  When this hook is fired,
it doesn't provide the previous window-configuration as its argument,
thus requiring remembering the old window-configuration in `pre-command-hook'.
So every `pre-command-hook' calls `current-window-configuration'
that is huge performance overhead.  This is worse than remembering
a variable in `pre-command-hook', and still no one complains about this.

Message #25 received at 52023 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: "52023 <at> debbugs.gnu.org" <52023 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#52023: 27.2; Enhancement:
 `this-command-invocation-(buffer|window)'
Date: Mon, 22 Nov 2021 20:00:23 +0000

> >> But in any case you can use `pre-command-hook' to store
> >> the original buffer and window.
> >
> > Please the bug report.  It includes this:
> 
> A verb is missing.  I assume you meant: "Please close the bug report"?

It should have said "please read".  No, the report
should not be closed.

> >   Currently, to get this information a workaround
> >   would be to use a `pre-command-hook' function
> >   that sets variables, and then to test those variables.
> 
> Indeed, `pre-command-hook' could be used to set these variables,
> and other possible variables.  There are much worse problems
> while using window-configuration-change-hook.  When this hook is fired,
> it doesn't provide the previous window-configuration as its argument,
> thus requiring remembering the old window-configuration in `pre-command-
> hook'.
>
> So every `pre-command-hook' calls `current-window-configuration'
> that is huge performance overhead.  This is worse than remembering
> a variable in `pre-command-hook', and still no one complains about this.

Please consider filing a bug / enhancement request
for that (other) problem.

`pre-command-hook' (and `post-') are overused.
One reason, I think, is that sometimes there's no
other way to do something easily.  They can be kind
of a mess, and yes, they can affect performance and
other behavior.

I'd like to see this particular enhancement added,
as I think such functions would be useful generally.
I'd like to avoid yet another use of the `pre-' and
`post-' hooks just to obtain some simple state info.

There are lots of things that no one complains about
but that it would be good to fix.

Message #28 received at 52023 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: "52023 <at> debbugs.gnu.org" <52023 <at> debbugs.gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#52023: 27.2; Enhancement:
 `this-command-invocation-(buffer|window)'
Date: Sat, 24 Sep 2022 15:31:13 +0200

Juri Linkov <juri <at> linkov.net> writes:

> So every `pre-command-hook' calls `current-window-configuration'
> that is huge performance overhead.  This is worse than remembering
> a variable in `pre-command-hook', and still no one complains about this.

So I think the conclusion here is that we don't want to add these
suggested variables, and I'm closing this bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.