From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Date: Fri, 17 May 2019 08:30:49 -0700 (PDT) Message-ID: References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="40292"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 17 17:34:12 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRes7-000ALC-EF for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 May 2019 17:34:11 +0200 Original-Received: from localhost ([127.0.0.1]:50214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRes5-0008KJ-TG for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 May 2019 11:34:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRerz-0008JC-Op for bug-gnu-emacs@gnu.org; Fri, 17 May 2019 11:34:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRery-0001tS-7K for bug-gnu-emacs@gnu.org; Fri, 17 May 2019 11:34:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45257) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hRery-0001tC-2M for bug-gnu-emacs@gnu.org; Fri, 17 May 2019 11:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hRerx-0001EL-Oq for bug-gnu-emacs@gnu.org; Fri, 17 May 2019 11:34: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: Fri, 17 May 2019 15:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35771 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.15581071824648 (code B ref 35771); Fri, 17 May 2019 15:34:01 +0000 Original-Received: (at 35771) by debbugs.gnu.org; 17 May 2019 15:33:02 +0000 Original-Received: from localhost ([127.0.0.1]:58800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hReqz-0001Cn-Mr for submit@debbugs.gnu.org; Fri, 17 May 2019 11:33:02 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:43156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hReqx-0001CY-Kw for 35771@debbugs.gnu.org; Fri, 17 May 2019 11:33:00 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4HFSTY2119011; Fri, 17 May 2019 15:32:53 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-2018-07-02; bh=/IksJGKtBHKjg8UfJ44Hoay3jgti98bBjdz3mSIhY30=; b=wlQ3ygNfhOWZjMoH/XIMGi3LB02SpqZROAtAAzwf/eQAf3h9vxRZfk1vG2OUM9N6Yp4J AtNZ6x5ADX1kkYLh0gyr24uV1P33DuDdkdCG3bK6M/K9Xrfly4f4r42P9/6quTYQiOpr gB0YYxlg3HaAukbTZ1qsG34b2tUbF8nWMhTaqytdfuQ7Is0apO3VYSfqolHfgpD68Jya 9Mh7Cyr13GGeNkSpLZI//tCa4k4g2/3Mb6YcR8Jte/IyC7MTkpGgCdjoEqtKDNlKl/9M koDjoZUk4sjaygyc7ySO7LPMlUPTeOVili/Nr0kajmEaK/xA06JdPGiz4YHJoz1vRDsQ uA== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2sdntuagc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 May 2019 15:32:53 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4HFTQmk097182; Fri, 17 May 2019 15:30:52 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2sggeuc0hr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 May 2019 15:30:52 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4HFUobi010214; Fri, 17 May 2019 15:30:50 GMT In-Reply-To: <87woipupuy.fsf@tcd.ie> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4849.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9260 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905170094 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9260 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905170094 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159456 Archived-At: > I don't know whether this has been discussed before, but it seems more > suited for emacs-devel or its own bug report, rather than the current > one. Well, it certainly also applies to this bug report, I think, which is purportedly about the "Customization _type_ of recentf-max-saved-items". > >> The customization type of recentf-max-saved-items is currently defined > >> as integer, which does not include nil in its domain. However, settin= g > >> this variable to nil is supported in the code and also documented. > >> > >> This patch changes the customization type to explicitly allow for the > >> variable to be set to nil through the Customization interface and > >> similar. (Please note that I copied the type from save-place-limit in > >> order to be consistent.) > > > > (I'm looking at Emacs 26.2, so apologies if the Emacs 27 > > code has already fixed this.) > > > > The code should also be changed to do one of the following: > > > > 1. Use `abs' when the variable value is used. >=20 > I disagree. It does not make sense for a size to be set to a negative > number without indication that this is a supported value; it is clearly > a user error to do so. Silently interpreting negative numbers as their > absolute value further restricts any future modifications to the > interpretation of this user option. The programmer should neither be > punished for such user errors, nor have to spoon-feed the user. >=20 > If there is ambiguity as to whether an integral user option can take a > negative value, the simplest and IMO best solution is to make the > documentation clearer, not to try to outsmart the user. I agree that #1 is not the best way to go (#2 is). But #1 is certainly better than allowing a negative value to=20 percolate through the code. (Not that a negative value would be disastrous in this case. For this particular bug it's not a big deal. But see, again, the Subject line - why not fix it right? > > 2. Use `restricted-sexp' in the defcustom :type, to require > > the value to be a non-negative (or possibly a positive?) > > integer (or nil). > > > > I'm guessing there are additional places in Emacs code > > where :type 'integer is used but a non-negative integer is > > really needed/appropriate. It would be good to improve > > those :type specs as well. > > > > (We might also want to consider adding `natnum' or > > `nonnegative-integer', `positive-integer' and > > `negative-integer' as possible :type values.) >=20 > I'd welcome a natnum type. >=20 > > But it is simple to use `restricted-sexp' to control such > > things. And not only would that improve the behavior for > > users; it would also, by way of model, encourage users to > > use `restricted-sexp' in their own code. >=20 > I don't see why restricted-sexp should be encouraged. It is far simpler > to use and harder to abuse combinations of predefined simple types. > Besides, not everyone uses the Customize interface. There is no alternative, when the type you want to express is not available as any "combination of predefined simple types". Use of `restricted-sexp' should be encouraged when it's _needed_, and that's when the type is not currently as restrictive as it should be AND there is no simpler way to define the more accurate type. That's the point. What we have today is not people avoiding/discouraging use of `restricted-sexp' in favor of just-as-useful, just-as-accurate, but simpler :type specs. We have people not using `restricted-sexp' out of ignorance of it, or perhaps out of laziness. (That's my guess, until convinced otherwise.) As for "not everyone uses Customize" - that's irrelevant here. This is about those who do use it, obviously. It's about the :type spec of a defcustom. More accurate defcustoms, using more appropriate :type specs, and sometimes using :set etc., is something we should encourage. Customize and defcustoms could use more love by Emacs developers, not less. > > Emacs-Lisp code delivered with Emacs is not a great model > > in this respect. It rarely uses `restricted-sexp' - at > > least it uses it much less than it could/should (IMHO). >=20 > IMO, that's one of the many things that makes Emacs a great and fun > model - the freedom from having to fight a (easily badly specified) type > system. Custom types should be as simple and declarative as possible. > Anything else should be reserved for exceptional cases. No idea what you're saying there. On the face of it it sounds like an argument for using only :type 'sexp, or perhaps an argument for not using defcustom at all. I think we probably disagree about 90% here (but I would glad to learn that I'm wrong about that guess). Using an accurate :type spec doesn't limit/hurt users. It helps them. Likewise, using a widget edit field that provides completion when appropriate etc. > > More generally, the distributed Emacs code is pretty > > "lazy" when it comes to providing defcustom definitions - > > few :tag descriptions, overly general :type specs, etc. > > > > E.g., > > > > (defcustom recentf-max-saved-items 20 > > "Maximum number of recently used file names to save. > > `nil' means save the whole list. > > See command `recentf-save-list'." > > :group 'recentf > > :type '(choice > > (restricted-sexp > > :tag "Save no more than this many file names" > > :match-alternatives > > ((lambda (x) (and (natnump x) (not (zerop x))))) > > :value ignore) > > (const :tag "Save all file names" nil))) >=20 > FWIW, my vote is against both trying to overspecify custom types, and > using restricted-sexp for such simple examples. If a particular type > such as natnum keeps cropping up, TRT is to add that type, not emulate > and duplicate it each time as a restricted-sexp. If you agree, and > there is no existing bug report for this, please submit one. "Overspecify"? "Trying to overspecify"? Please elaborate. The value should be a natural number (or perhaps a positive integer), no? How is specifying that exactly overspecifying? Specifying `integer' is underspecifying. You have that exactly backward. Why shouldn't users be helped to provide the most appropriate values? Why did you say you would welcome a :type of `natnum', if you argue for unrestricted typing? Why prefer using `natnum' to `integer' - or even to `sexp' - for such a value, in that case? I don't object to adding a `natnum' :type - I suggested it. But I also don't have a problem with expressing the same thing even if we don't have such a type. I think it's silly to _not_ specify such behavior, and to just use `integer' (or `sexp') simply because we don't have a `natnum'. That makes no sense to me. Do I think we should use `restricted-sexp' even when a simpler type spec is available to accomplish the same thing? Of course not.