From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#38796: 26.3; `view-lossage': Use a variable for the lossage limit Date: Sun, 28 Jun 2020 20:01:07 +0000 (UTC) Message-ID: References: <43aac56d-ecf1-44ed-9be1-ffb8e5f8a7ce@default> <83zhfbm448.fsf@gnu.org> <87zh8pij6e.fsf@calancha-pc.dy.bbexcite.jp> <83v9jc3o3q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="2122"; mail-complaints-to="usenet@ciao.gmane.io" Cc: uyennhi.qm@gmail.com, 38796@debbugs.gnu.org To: Stefan Monnier , Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 28 22:02:13 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpdVE-0000Qh-ML for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Jun 2020 22:02:12 +0200 Original-Received: from localhost ([::1]:48134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpdVD-0007JS-LJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Jun 2020 16:02:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpdV3-0007J5-Vy for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2020 16:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jpdV3-0001j8-Lv for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2020 16:02:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jpdV3-0004ch-Jd for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2020 16:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Jun 2020 20:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38796 X-GNU-PR-Package: emacs Original-Received: via spool by 38796-submit@debbugs.gnu.org id=B38796.159337448017705 (code B ref 38796); Sun, 28 Jun 2020 20:02:01 +0000 Original-Received: (at 38796) by debbugs.gnu.org; 28 Jun 2020 20:01:20 +0000 Original-Received: from localhost ([127.0.0.1]:46987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpdUO-0004bU-4F for submit@debbugs.gnu.org; Sun, 28 Jun 2020 16:01:20 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:40596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpdUK-0004b7-Qs for 38796@debbugs.gnu.org; Sun, 28 Jun 2020 16:01:18 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05SJx8oa067086; Sun, 28 Jun 2020 20:01:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=mMMXh2QxPIRWX07KtQ/Oqje31WenqGHQkq8pQtMVdc4=; b=MFV3yMa9zLSm/K24poR00mBupI93Nt2zPa28cCAtpaQGvpkFCVwdHow7F9CqIYC2XJrl 6AD08yWDix+J3nLXB9z/XUYPiPwF9o6w7SvmQ0YjTSpWZvPps3K2L6GwslT/iQjnRkDA O9VlZ3HTu/b9rLi/uvdFn6sCX5TykhyfDwZdZpEdE44y7kKvuIfYOgF+zgSLQBwusyWd WXYtaS7FSkkg+Iqafzs4xEuRbF3hlMjBkvmldR1MSr6GPRnQkLCfS2O5b8yx4gaRSr2Z a9YfmUAKww4lxVdXm4hdcl2QaIy4TlGiqo23HjCEwsmb69iZBRKjqrM3GD3QVN5hyZ4x sw== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 31wxrmue38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Jun 2020 20:01:11 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05SJwKA3026756; Sun, 28 Jun 2020 20:01:10 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 31xfpjx9jd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Jun 2020 20:01:10 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05SK18ih015906; Sun, 28 Jun 2020 20:01:08 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5017.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9666 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 suspectscore=0 mlxscore=0 phishscore=0 bulkscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006280149 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9666 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 clxscore=1011 malwarescore=0 phishscore=0 adultscore=0 cotscore=-2147483648 lowpriorityscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006280149 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182485 Archived-At: > I agree that disabling should not necessarily be implemented by > "abusing" the max-lossage setting. >=20 > 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 . 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.