* bug#42916: 26.3; `view-lossage': include timestamp
@ 2020-08-18 17:12 Drew Adams
2020-08-19 9:49 ` Lars Ingebrigtsen
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2020-08-18 17:12 UTC (permalink / raw)
To: 42916
Possible enhancement:
If bug #38796 gets taken care of then users could have very long
`view-lossage' logs (if they choose).
Especially in such a context, it could be useful to provide a timestamp
with each event. This could be via a `help-echo' property, for example.
Or it could be made available as a separate column, or in some other
way.
I know it doesn't make a lot of sense with the current state of the
output, but with much longer logs it could be helpful.
A `help-echo' property provides a tooltip, but it won't help with
searching. A UI that lets you search, or filter (e.g. `occur') on not
only the event/key/command name but also the time/date, could be useful.
Just a thought. `view-lossage' is essentially a log. It could be made
more useful than it is now, I expect.
In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.18362
Configured using:
`configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#42916: 26.3; `view-lossage': include timestamp
2020-08-18 17:12 bug#42916: 26.3; `view-lossage': include timestamp Drew Adams
@ 2020-08-19 9:49 ` Lars Ingebrigtsen
2020-08-19 12:59 ` Drew Adams
2020-08-19 13:09 ` Peder O. Klingenberg
0 siblings, 2 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-19 9:49 UTC (permalink / raw)
To: Drew Adams; +Cc: 42916
Drew Adams <drew.adams@oracle.com> writes:
> Especially in such a context, it could be useful to provide a timestamp
> with each event. This could be via a `help-echo' property, for example.
> Or it could be made available as a separate column, or in some other
> way.
This would mean querying (and storing) the time stamp of all keystrokes,
which seems excessive for such a marginal feature.
Anybody got an opinion here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#42916: 26.3; `view-lossage': include timestamp
2020-08-19 9:49 ` Lars Ingebrigtsen
@ 2020-08-19 12:59 ` Drew Adams
2020-08-19 13:09 ` Peder O. Klingenberg
1 sibling, 0 replies; 5+ messages in thread
From: Drew Adams @ 2020-08-19 12:59 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 42916
> > Especially in such a context, it could be useful to provide a timestamp
> > with each event. This could be via a `help-echo' property, for example.
> > Or it could be made available as a separate column, or in some other
> > way.
>
> This would mean querying (and storing) the time stamp of all keystrokes,
> which seems excessive for such a marginal feature.
Yes. It was just a thought.
Perhaps an optional behavior (via mode or otherwise)
would be in order - something you could turn on when
interested in more complete logging. That could help
with some kinds of debugging or learning, for instance.
Certainly, if this were a performance drag it shouldn't
be the default behavior.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#42916: 26.3; `view-lossage': include timestamp
2020-08-19 9:49 ` Lars Ingebrigtsen
2020-08-19 12:59 ` Drew Adams
@ 2020-08-19 13:09 ` Peder O. Klingenberg
2020-08-22 21:26 ` Lars Ingebrigtsen
1 sibling, 1 reply; 5+ messages in thread
From: Peder O. Klingenberg @ 2020-08-19 13:09 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 42916
On on., 2020-08-19 kl. 11.49 +0200 +0200, Lars Ingebrigtsen wrote:
> This would mean querying (and storing) the time stamp of all keystrokes,
> which seems excessive for such a marginal feature.
An alternative could be to dump a dedicated timestamp event into the log
every <mumble> minutes or so. It wouldn't give you exact timings, but
could tell you whether you're looking at something you typed last month
or five minuts ago, and wouldn't require more work on every keystroke.
...Peder...
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#42916: 26.3; `view-lossage': include timestamp
2020-08-19 13:09 ` Peder O. Klingenberg
@ 2020-08-22 21:26 ` Lars Ingebrigtsen
0 siblings, 0 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-22 21:26 UTC (permalink / raw)
To: Peder O. Klingenberg; +Cc: 42916
"Peder O. Klingenberg" <peder@klingenberg.no> writes:
> On on., 2020-08-19 kl. 11.49 +0200 +0200, Lars Ingebrigtsen wrote:
>
>> This would mean querying (and storing) the time stamp of all keystrokes,
>> which seems excessive for such a marginal feature.
>
> An alternative could be to dump a dedicated timestamp event into the log
> every <mumble> minutes or so. It wouldn't give you exact timings, but
> could tell you whether you're looking at something you typed last month
> or five minuts ago, and wouldn't require more work on every keystroke.
Hm, yes, that might be a good idea...
On the other hand, the last time I poked at the lossage data, it wasn't
a lot of fun: It's used by normal typing as well as the keyboard macro
binding stuff, so it's a bit of a prickly data structure. If I remember
correctly; it's been at least a couple of years since I poked at it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-08-22 21:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-18 17:12 bug#42916: 26.3; `view-lossage': include timestamp Drew Adams
2020-08-19 9:49 ` Lars Ingebrigtsen
2020-08-19 12:59 ` Drew Adams
2020-08-19 13:09 ` Peder O. Klingenberg
2020-08-22 21:26 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).