From: Eli Zaretskii <eliz@gnu.org>
To: Tino Calancha <tino.calancha@gmail.com>
Cc: monnier@iro.umontreal.ca, 38796@debbugs.gnu.org, uyennhi.qm@gmail.com
Subject: bug#38796: 26.3; `view-lossage': Use a variable for the lossage limit
Date: Sat, 27 Jun 2020 11:32:57 +0300 [thread overview]
Message-ID: <83v9jc3o3q.fsf@gnu.org> (raw)
In-Reply-To: <87zh8pij6e.fsf@calancha-pc.dy.bbexcite.jp> (message from Tino Calancha on Fri, 26 Jun 2020 23:58:01 +0200)
> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 38796@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, Stefan Monnier
> <monnier@iro.umontreal.ca>,uyennhi.qm@gmail.com, tino.calancha@gmail.com
> Date: Fri, 26 Jun 2020 23:58:01 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Drew Adams <drew.adams@oracle.com>
> >> This report is a follow-up to this emacs-devel thread:
> >> https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00678.html
> >> and to the older thread that it references:
> >> https://lists.gnu.org/archive/html/emacs-devel/2006-03/msg01012.html
> >> Please use a variable for the limit of how many characters to use for
> >> recording lossage.
>
> > it isn't enough to expose the value to Lisp; one must
> > also write code that reallocates the vector when the value changes,
> > and copies the keystrokes from the old to the new vector in the
> > correct order.
> >
> > Patches are welcome.
>
> I have uploaded the branch feature/bug#38796-lossage-limit
> [I've been using it during last 10 days with no issues]
>
> Initially I decided to hardcode a sensible minimum of 100 (keeping
> the current default of 300). That is the first commit.
> Actually, the code works for N > 0, but as Drew suggested, a value < 100
> (which gives only ~ 50 lines of past inputs) is too small to be useful
> for the use case of checking typing mistakes.
>
> After some time I thought that, for some people (anyone in this thread),
> a very small value in fact can be seen as a security feature;
> see for instance the docstrings of `term-read-noecho' and
> `comint-send-invisible'. That motivates the second commit.
Thanks. Some initial comments below:
. The original request was for allowing to keep _more_ than just 300
keystrokes, there was no request for recording less than that
number. I'm not sure we should allow reducing the number; if
someone thinks it could be a security issue, then we should have a
separate feature that disabled recording the keys, not as a side
effect of reducing the vector size.
. The size of the vector shouldn't be exposed to Lisp, there's no
reason for doing that. You say in the doc string of the variable
not to set nor bind it, but documenting the restriction is not
enough, as someone, perhaps even some malicious code, could just do
what you ask not to. Instead, there should be a function to get
the value and a function to set the value (which should also resize
the vector as a side effect).
. Using 1 as the value that disables recording is unnatural; it might
be convenient from the implementation POV, but this implementation
convenience cannot justify asking the users to remember such a
strange convention. The usual way of disabling a feature is either
by setting the value to zero or using a suitable symbol, like nil.
(But I'm not sure we should provide this feature as part of this
changeset, see below.)
. Last, but not least: if we are going to allow to disable recording
of keys, we should carefully audit all the places that call
recent-keys, and make sure they will not break due to such a
radical change.
My personal view is that we should allow only growing the size and
resetting it to the original size of 300. Disabling the key record
should be a separate feature, most probably implemented by means other
than shrinking the recent_keys vector.
Thanks.
next prev parent reply other threads:[~2020-06-27 8:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-29 17:04 bug#38796: 26.3; `view-lossage': Use a variable for the lossage limit Drew Adams
2019-12-29 17:30 ` Eli Zaretskii
2019-12-29 17:34 ` Drew Adams
2020-06-26 21:58 ` Tino Calancha
2020-06-27 8:32 ` Eli Zaretskii [this message]
2020-06-28 16:55 ` Tino Calancha
2020-06-28 18:00 ` Stefan Monnier
2020-06-28 20:01 ` Drew Adams
2020-06-28 21:52 ` Tino Calancha
2020-06-29 0:05 ` Drew Adams
2020-08-22 21:24 ` Lars Ingebrigtsen
2020-08-22 22:54 ` Drew Adams
2020-08-27 21:28 ` Tino Calancha
2020-08-28 6:04 ` Eli Zaretskii
2020-09-04 9:31 ` Tino Calancha
2020-09-04 12:07 ` Eli Zaretskii
2020-09-12 12:29 ` Tino Calancha
2020-09-17 14:35 ` Tino Calancha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83v9jc3o3q.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=38796@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=tino.calancha@gmail.com \
--cc=uyennhi.qm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).