all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
@ 2021-11-21 18:11 Drew Adams
  2021-11-21 19:19 ` Juri Linkov
  0 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2021-11-21 18:11 UTC (permalink / raw)
  To: 52023

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)






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
  2021-11-21 18:11 bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)' Drew Adams
@ 2021-11-21 19:19 ` Juri Linkov
  2021-11-21 21:36   ` bug#52023: [External] : " Drew Adams
  0 siblings, 1 reply; 8+ messages in thread
From: Juri Linkov @ 2021-11-21 19:19 UTC (permalink / raw)
  To: Drew Adams; +Cc: 52023

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
  2021-11-21 19:19 ` Juri Linkov
@ 2021-11-21 21:36   ` Drew Adams
  2021-11-22  8:06     ` Juri Linkov
  0 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2021-11-21 21:36 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 52023@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
  2021-11-21 21:36   ` bug#52023: [External] : " Drew Adams
@ 2021-11-22  8:06     ` Juri Linkov
  2021-11-22 15:17       ` Drew Adams
  0 siblings, 1 reply; 8+ messages in thread
From: Juri Linkov @ 2021-11-22  8:06 UTC (permalink / raw)
  To: Drew Adams; +Cc: 52023@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
  2021-11-22  8:06     ` Juri Linkov
@ 2021-11-22 15:17       ` Drew Adams
  2021-11-22 17:46         ` Juri Linkov
  0 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2021-11-22 15:17 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 52023@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
  2021-11-22 15:17       ` Drew Adams
@ 2021-11-22 17:46         ` Juri Linkov
  2021-11-22 20:00           ` Drew Adams
  2022-09-24 13:31           ` Lars Ingebrigtsen
  0 siblings, 2 replies; 8+ messages in thread
From: Juri Linkov @ 2021-11-22 17:46 UTC (permalink / raw)
  To: Drew Adams; +Cc: 52023@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#52023: [External] : Re: bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
  2021-11-22 17:46         ` Juri Linkov
@ 2021-11-22 20:00           ` Drew Adams
  2022-09-24 13:31           ` Lars Ingebrigtsen
  1 sibling, 0 replies; 8+ messages in thread
From: Drew Adams @ 2021-11-22 20:00 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 52023@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)'
  2021-11-22 17:46         ` Juri Linkov
  2021-11-22 20:00           ` Drew Adams
@ 2022-09-24 13:31           ` Lars Ingebrigtsen
  1 sibling, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-24 13:31 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 52023@debbugs.gnu.org, Drew Adams

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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-09-24 13:31 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-21 18:11 bug#52023: 27.2; Enhancement: `this-command-invocation-(buffer|window)' Drew Adams
2021-11-21 19:19 ` Juri Linkov
2021-11-21 21:36   ` bug#52023: [External] : " Drew Adams
2021-11-22  8:06     ` Juri Linkov
2021-11-22 15:17       ` Drew Adams
2021-11-22 17:46         ` Juri Linkov
2021-11-22 20:00           ` Drew Adams
2022-09-24 13:31           ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.