bug#38796: 26.3; `view-lossage': Use a variable for the lossage limit

[Drew Adams <drew.adams@oracle.com>]

> I agree that disabling should not necessarily be implemented by
> "abusing" the max-lossage setting.
> 
> But I don't see any reason to impose a 300 minimum either.  I think it's
> fine to impose a minimum, but it should be dictated by the limits of the
> code.  I'm not saying we should work to push this lower limit down, but
> just that it should reflect what the code can do safely rather than
> being an arbitrary number like 300 (I'm pretty sure 100 would be safe as
> well, since that's what we've used for many years).

OP here.

 ++++
 +** The new option 'lossage-limit' controls the
 +maximum number of keystrokes and commands recorded.

I don't feel strongly about what's done wrt low values
or turning such logging off.  As Eli said, the point
of the enhancement request is to let users control the
max, in particular to be able to make it _larger_ than
the default (300).

I think I understand why some have argued for a second
option for turning logging off.  But I don't think
it's a great argument (IIUC).

I agree with Stefan that disabling should not
_necessarily_ be carried out by setting the max limit
(e.g. to 0).

Not _necessary_, but isn't that logical, from a user
point of view?  I wouldn't call that "abusing" the
max-limit option.

1. In general in Emacs, setting a maximum of zero does
   (and should) do just what it says: not allow ANY
   <whatevers>.

2. Having 2 options here goes against Occam, and is
   likely to lead to some confusion (perhaps even some
   mistakes, in terms of security?).

   It'll require the doc of each option to mention the
   other, in hopes that users will consult both.  Iffy
   if really you see a security problem here.

   It'll mean that the defcustom for the max one needs
   to prevent a value as low as zero, in order to avoid
   misunderstanding.  E.g., what would it even mean for
   a history of length zero that does not, in effect,
   disable logging?

Is the real reason for not letting zero turn off
logging a C-implementation reason?  What's really
wrong, from a user point of view, with doing that?

Again, this isn't super important.  The request
was for users to be able to customize the length,
in particular to be able to _increase_ it.

But if we allow such length customization, why
complicate things by adding another option for
getting the natural effect of length zero, i.e.,
turning logging off?

I'm more often in the position of arguing for
more, not fewer, options, even when they combine
to control something.  But this time (until I
understand better perhaps), that's not the case.
___

Another possibility is to have, for the same
option, a specific value other than zero, to
indicate disabling.  E.g. `disable' or some other
non-number value.  But then you have the same
confusion, if the numeric value can itself be 0.
___

Although it's not part of this enhancement request,
as was mentioned from the outset the main problem
with `view-lossage' output (of any length) is the
low signal-to-noise ratio.  It would really be good
to be able to (on the fly) filter out certain kinds
of input, in particular kinds of non-keyboard input.

Besides on-the-fly filtering, it might be good to
have a user variable, to define a preference for
(default) filtering.

Another nice-to-have would be a way (e.g. filter)
to not show the commands long with their keys.
For someone who knows the commands associated with
keys, they are pretty much noise.  And we could
perhaps put links on the keys to their commands in
the current keymap context.

Increasing the logging length is only one possible
improvement.  In general, we should be looking for
ways to help users see what they think is important
in a log - ways to show/hide different things.