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

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

[Drew Adams]

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)

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

[Juri Linkov]

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

bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'

[Drew Adams]

> > 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?)

bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'

[Juri Linkov]

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

bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'

[Drew Adams]

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

bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'

[Juri Linkov]

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

bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'

[Drew Adams]

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

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

[Lars Ingebrigtsen]

Juri Linkov <juri@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.