improvements to the "lossage buffer"

improvements to the "lossage buffer"

[Emanuel Berg]

`view-lossage' seems to have improved in
a recent Emacs version upgrade, since it now
displays a neat flow of information with one
key (or one key sequence) on each row with,
even more of an improvement, the name of the
command in square brackets following the
key. E.g.,

     k [next-line]
     i [previous-line]
     k [next-line]
     RET [buffer-menu-kill-and-open]
     C-j e . [anonymous-command]
     ESC o [other-window-or-split]
     ESC o [other-window-or-split]
     ESC o [other-window-or-split]
     ESC p [delete-other-windows]
     C-o k [end-of-buffer]
     C-h l [view-lossage]

This is much better than the old version which
looked like a jungle. Not speaking literally,
that is!

To make it even clearer, why don't you consider
putting the command name in a column of its
own? This would also make the brackets
redundant. Also, isn't, e.g. M-o more used than
"ESC o", both in speech/writing _and_ in code -
and isn't it more intuitive as well? I.e.,
wouldn't this be even better - and improvement
on the improvement, if you will?

     k         next-line
     i         previous-line
     k         next-line
     RET       buffer-menu-kill-and-open
     C-j e .   anonymous-command
     M-o       other-window-or-split
     M-o       other-window-or-split
     M-o       other-window-or-split
     M-p       delete-other-windows
     C-o k     end-of-buffer
     C-h l     view-lossage

I think so!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: improvements to the "lossage buffer"

[Stefan Monnier]

> To make it even clearer, why don't you consider
> putting the command name in a column of its
> own?

I'm sure the maintainers would be happy to get a patch for that ;-)

Note that occasionally there can be a very long sequence of events
leading to a command, so you'd want to make sure that such an occurrence
doesn't force the first column to be insanely wide.

> Also, isn't, e.g. M-o more used than
> "ESC o", both in speech/writing _and_ in code -

`M-o` and `ESC o` aren't the same events, although usually they lead to
the same behavior.  `view-lossage` is specifically useful in order to
see the "raw" events, for those cases where the difference between `ESC
o` and `M-o` might be important, so no I think that would be a bad idea.


        Stefan

Re: improvements to the "lossage buffer"

[Emanuel Berg]

Stefan Monnier wrote:

> `M-o` and `ESC o` aren't the same events,
> although usually they lead to the
> same behavior.

Wait, that means all these years, I've not been
hitting Meta, but Escape?

Must be some configuration years ago I've
forgotten about...

Maybe I don't even have a Meta key? Reading it
now on the physical keyboard, it _does_ say
"Alt" so that even makes sense!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: improvements to the "lossage buffer"

[Emanuel Berg]

BTW what does "lossage" mean?

It isn't in my dictionary, which is, ehem,
"dictd_www.dict.org_gcide"

    $ sdcv -l
    Dictionary's name   Word count
    dictd_www.dict.org_gcide    174222

and it isn't in Wiktionary either - or it
is [1] - only that seems to refer to something
else (?)


[1] https://en.wiktionary.org/wiki/lossage

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: improvements to the "lossage buffer"

[Marcin Borkowski]

On 2019-07-31, at 01:08, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> To make it even clearer, why don't you consider
>> putting the command name in a column of its
>> own?
>
> I'm sure the maintainers would be happy to get a patch for that ;-)

No need, I guess.  I'm on (relatively fresh) master and it's behaving
like this for some time already (I've just checked on emacs -Q).

While we're at that, sometimes I'd like to have also timestamps there.
But maybe that's too much.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: improvements to the "lossage buffer"

[Emanuel Berg]

Marcin Borkowski wrote:

> While we're at that, sometimes I'd like to
> have also timestamps there. But maybe that's
> too much.

In what format - Unix time? But what if you hit
more than one key in less than one second?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: improvements to the "lossage buffer"

[Marcin Borkowski]

On 2019-07-31, at 08:11, Emanuel Berg <moasenwood@zoho.eu> wrote:

> Marcin Borkowski wrote:
>
>> While we're at that, sometimes I'd like to
>> have also timestamps there. But maybe that's
>> too much.
>
> In what format - Unix time? But what if you hit
> more than one key in less than one second?

How about ISO 8601?  Also, why would the same timestamp for a few
entries be a problem?  The problem I'd like to solve is "I did something
strange 10 seconds ago, I want to know what I did, I'm not interested
in stuff that happened 4 or 40 seconds ago".

IOW, even better format could be
"2019-07-31T07:40:04+00:00 (18 seconds ago)"

Best,

--
Marcin Borkowski
http://mbork.pl

Re: improvements to the "lossage buffer"

[Emanuel Berg]

Marcin Borkowski wrote:

> How about ISO 8601?

Yep, one of my favorite ISOs OAT, also the one
and only one ISO mentioned in the date(1) man
page.

They also mention RFC 2822 and RFC 3339 tho,
and of them three, I think I'd vote for 3339:

    2006-08-14 02:34:56-06:00

> Also, why would the same timestamp for a few
> entries be a problem? The problem I'd like to
> solve is "I did something strange 10 seconds
> ago, I want to know what I did, I'm not
> interested in stuff that happened 4 or 40
> seconds ago".
>
> IOW, even better format could be
> "2019-07-31T07:40:04+00:00 (18 seconds ago)"

Hm, I wonder what the "T" is... time?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: improvements to the "lossage buffer"

[Stefan Monnier]

> No need, I guess.  I'm on (relatively fresh) master and it's behaving
> like this for some time already (I've just checked on emacs -Q).

Good point.

> While we're at that, sometimes I'd like to have also timestamps there.

Hmm... I can't remember ever feeling like timestamps would be helpful.
Do you have some scenario in mind?


        Stefan

Re: improvements to the "lossage buffer"

[Marcin Borkowski]

On 2019-07-31, at 14:18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> No need, I guess.  I'm on (relatively fresh) master and it's behaving
>> like this for some time already (I've just checked on emacs -Q).
>
> Good point.
>
>> While we're at that, sometimes I'd like to have also timestamps there.
>
> Hmm... I can't remember ever feeling like timestamps would be helpful.
> Do you have some scenario in mind?

I wrote about it another message, though I don't consider it essential
in any way - probably not worth the effort.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: improvements to the "lossage buffer"

[Marcin Borkowski]

On 2019-07-31, at 11:09, Emanuel Berg <moasenwood@zoho.eu> wrote:

> Marcin Borkowski wrote:
>
>> How about ISO 8601?
>
> Yep, one of my favorite ISOs OAT, also the one
> and only one ISO mentioned in the date(1) man
> page.
>
> They also mention RFC 2822 and RFC 3339 tho,
> and of them three, I think I'd vote for 3339:
>
>     2006-08-14 02:34:56-06:00

Thanks, I didn't know those!

>> Also, why would the same timestamp for a few
>> entries be a problem? The problem I'd like to
>> solve is "I did something strange 10 seconds
>> ago, I want to know what I did, I'm not
>> interested in stuff that happened 4 or 40
>> seconds ago".
>>
>> IOW, even better format could be
>> "2019-07-31T07:40:04+00:00 (18 seconds ago)"
>
> Hm, I wonder what the "T" is... time?

I guess so.  This is probably the dumbest part of ISO 8601.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: improvements to the "lossage buffer"

[Dan Sommers]

On 7/31/19 1:01 PM, Marcin Borkowski wrote:
> 
> On 2019-07-31, at 11:09, Emanuel Berg <moasenwood@zoho.eu> wrote:

>>> IOW, even better format could be
>>> "2019-07-31T07:40:04+00:00 (18 seconds ago)"
>>
>> Hm, I wonder what the "T" is... time?
> 
> I guess so.  This is probably the dumbest part of ISO 8601.

Dumbest is likely subjective (and off topic!), but that T
instead of a space makes the whole timestamp one whitespace
delimited token instead of two, which can make subsequent
operations on it easier in some tools.

Re: improvements to the "lossage buffer"

[Marcin Borkowski]

On 2019-07-31, at 19:14, Dan Sommers <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

> On 7/31/19 1:01 PM, Marcin Borkowski wrote:
>>
>> On 2019-07-31, at 11:09, Emanuel Berg <moasenwood@zoho.eu> wrote:
>
>>>> IOW, even better format could be
>>>> "2019-07-31T07:40:04+00:00 (18 seconds ago)"
>>>
>>> Hm, I wonder what the "T" is... time?
>>
>> I guess so.  This is probably the dumbest part of ISO 8601.
>
> Dumbest is likely subjective (and off topic!), but that T
> instead of a space makes the whole timestamp one whitespace
> delimited token instead of two, which can make subsequent
> operations on it easier in some tools.

Well, what would be the problem with dash or underscore?

But this is moot, since the norm is the norm anyway.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: improvements to the "lossage buffer"

[Yuri Khan]

On Thu, Aug 1, 2019 at 12:02 AM Marcin Borkowski <mbork@mbork.pl> wrote:

> >> How about ISO 8601?
> >
> > They also mention RFC 2822 and RFC 3339 tho,
> > and of them three, I think I'd vote for 3339:
> >
> >     2006-08-14 02:34:56-06:00
>
> Thanks, I didn't know those!

Be aware that proper RFC 3339 is a subset of ISO 8601; as such, it,
too, uses the T separator between date and time, not the space.

Re: improvements to the "lossage buffer"

[Emanuel Berg]

Yuri Khan wrote:

> Be aware that proper RFC 3339 is a subset of
> ISO 8601; as such, it, too, uses the
> T separator between date and time, not
> the space.

Only date(1) uses improper RFC 3339:

$ date --rfc-3339=date
2019-08-01

$ date --rfc-3339=seconds
2019-08-01 03:32:43+02:00

$ date --rfc-3339=ns
2019-08-01 03:32:45.480938921+02:00

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal