bug#61440: 27.2; Be able to have `view-lossage' report only on the current buffer

bug#61440: 27.2; Be able to have `view-lossage' report only on the current buffer

[Drew Adams]

Enhancement request.

Be able (e.g. with a prefix arg) to have `C-h l' show only the recent
commands used in the current buffer.  The max number should be the same
as if listing the commands used in all buffers.  IOW, it shouldn't just be a
filtering of what `C-h l' without a prefix arg would give you (i.e., limited
to the max number).

It would be good to also extend `recent-keys' to accept an additional
optional arg, to have it return only events in the current buffer.

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.19044
System Description: Microsoft Windows 10 Pro (v10.0.2009.19044.2486)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Type C-x 1 to delete the help window.

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

bug#61440: 27.2; Be able to have `view-lossage' report only on the current buffer

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sat, 11 Feb 2023 21:59:09 +0000
> 
> Be able (e.g. with a prefix arg) to have `C-h l' show only the recent
> commands used in the current buffer.  The max number should be the same
> as if listing the commands used in all buffers.  IOW, it shouldn't just be a
> filtering of what `C-h l' without a prefix arg would give you (i.e., limited
> to the max number).
> 
> It would be good to also extend `recent-keys' to accept an additional
> optional arg, to have it return only events in the current buffer.

How do you define "commands used in the current buffer"?

  . are commands in the minibuffer when Emacs prompts considered to be
    "used in the current buffer"?
  . are commands invoked from the minibuffer via M-x considered to be
    "used in the current buffer"?
  . what about commands that switch to temporary buffers and enter
    recursive edit there?
  . what about commands that switch to another buffer in the middle of
    typing a key sequence?
  . etc. etc.

IOW, I don't understand how this hypothetical feature could work in
practice, let alone how to document what exactly it produces.  Emacs
commands are by their very nature "global", unrelated to a buffer.

bug#61440: 27.2; Be able to have `view-lossage' report only on the current buffer

[Drew Adams]

> How do you define "commands used in the current buffer"?

Good question!  Clearly I didn't think enough about this
before posting.

>   . are commands in the minibuffer when Emacs prompts considered to be
>     "used in the current buffer"?
>   . are commands invoked from the minibuffer via M-x considered to be
>     "used in the current buffer"?
>   . what about commands that switch to temporary buffers and enter
>     recursive edit there?
>   . what about commands that switch to another buffer in the middle of
>     typing a key sequence?
>   . etc. etc.
> 
> IOW, I don't understand how this hypothetical feature could work in
> practice, let alone how to document what exactly it produces.  Emacs
> commands are by their very nature "global", unrelated to a buffer.

All true.  Thanks for thinking this through more than I did.

Commands and keys (except keys on text/overlay properties)
are unrelated to any particular buffer.  But some buffer is
current when a command/key is invoked.

How about making the criterion be the commands/keys invoked
when buffer X is current?  (More generally, events occurring
when X is current.)

Only one buffer is current at any time.  The time a command
is called could be used to decide which buffer considers it
a command to be listed for that buffer.

This doesn't imply that the buffer that's current when a
command is invoked remains current throughout the command
execution, or that the effects of the command will even be
in that "invocation" buffer - of course.

But it gives us a way to split up the stream of input events
a bit, in a way that can sometimes be useful.  Commands that
move point within a buffer, for example would be listed for
that buffer.

And of course the usual behavior would be there and be the
default: show all commands/keys, regardless of the buffer
that was current when called.

I'm pretty sure I'd find it useful.  I can imagine checking
one or more such buffer listings, as well as the global one,
when I'm looking for some event or want to know better what
I did.

As for the minibuffer: I think the choices are either (1)
count the minibuffer itself as the current buffer when, uh,
it's current, or (2) consider the buffer that was current
just before the minibuffer (i.e., that particular depth)
was entered as the "current buffer" for purposes of this
feature.

Each of those, #1 and #2 could actually be useful.

Except that, as I worded the request, the proposed
behavior would only give you the lossage for the current
buffer, not for any buffer you request.  And minibuffers
are ephemeral, especially recursive ones, so "getting
into" such a minibuffer again, to be able to request the
lossage help would be problematic.

A version of `view-lossage' (I mean another, new command)
that asks which buffer to show the lossage for would
likely take of that problem.

But #2 (use the buffer current before the minibuffer)
would be fine.  (Dunno whether Emacs has a way to give
you the buffer current before the minibuffer was entered.
I have that for Icicles, but that didn't exist when I
added that.  Maybe it's available in Emacs now?)

Dunno whether this answers both of your questions: what
for? and which buffer?