From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: Dario Gjorgjevski Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2019 12:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 35771 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 35771@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.15580964183280 (code B ref -1); Fri, 17 May 2019 12:34:01 +0000 Received: (at submit) by debbugs.gnu.org; 17 May 2019 12:33:38 +0000 Received: from localhost ([127.0.0.1]:57708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRc3N-0000qq-VS for submit@debbugs.gnu.org; Fri, 17 May 2019 08:33:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRc3M-0000qe-Uq for submit@debbugs.gnu.org; Fri, 17 May 2019 08:33:37 -0400 Received: from lists.gnu.org ([209.51.188.17]:53227) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hRc3H-0006yJ-M5 for submit@debbugs.gnu.org; Fri, 17 May 2019 08:33:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRc3G-0007Uq-Ll for bug-gnu-emacs@gnu.org; Fri, 17 May 2019 08:33:31 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRbsF-0000qd-JH for bug-gnu-emacs@gnu.org; Fri, 17 May 2019 08:22:08 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:44074) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hRbsF-0000om-BH for bug-gnu-emacs@gnu.org; Fri, 17 May 2019 08:22:07 -0400 Received: by mail-wr1-x431.google.com with SMTP id c5so6876088wrs.11 for ; Fri, 17 May 2019 05:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=N3UOPi5LmkbW5Kr81cZCF3jZhZA6oGq8fvAfTc8+/x8=; b=Cp7LLmDBL8IvUFdMt6GrOSyjFEVbAqq97fLdm4serTjslz9q6bDArMlzfY0dRm2su7 ZVgP0ouvq1Y4z5ZyjrVPI/r8KAEw1GTx+pC6qXkSmkVIbcZKdVKU1p9q87XPYv2SyP7r HlrrveuReaKZWtbP20zEB8916xwI3o6NOTAgwkoMr9ahP++CuzNecGU9eYnUC0+uvkX8 JXWAFjLFy4jI47bbXu4SWL/fPtyrzqegkBmxXTYh9IdTDEtouh5aJegnS3dbg4Mh2UCH 8MVK2hesfki/fYgoyDM1eaAT5cw68i+V1bJIhBkEtKBFSw4W5P/1QY4atmXrXt8jwsQR OQIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=N3UOPi5LmkbW5Kr81cZCF3jZhZA6oGq8fvAfTc8+/x8=; b=bD+yZmfXUNYMWhgBqV189f3u/ytjomYOjYr7xWFZB1CrDKGwUOaMYxNGy4zzpN8BL8 Hdr099dWxa/kC2V6SOGU/nMJvklZcIsoyI3REZcVbgkNYmQEtdTa7QeVabZhIO+NVa/9 YNS8ee3U65FGNoVByy+8zstoXwnNJOYg4K/vuTTy16vadveNNZHEIfdJp8Wr5AW+S/Lf f97mY7ysxed5VNMDSFy8SftOsdWux6B3D2vjXs4JYDekZ6ROIUg7ybkZqLCO73rNJwo+ 2nHANAjpPQ9T8p5bhB9uk5sOaTVBggohhUFa+kZVjihmK8H9vrZmcXFq3sTI7+VTzOH2 eptQ== X-Gm-Message-State: APjAAAVG3cAYInZHs//WLgHipQn/n0flGZlvkKe8pMW8uRHq+fGN2F2s 6OyZrCJqyzF9g8XtPIG3PS4intP6pDk= X-Google-Smtp-Source: APXvYqw8NrVesjZi4Oz+8dkTh8j1LTxCYb3uIdeO467vQwmngJlNBhYPo/K0eQ90M7/FWC5T55+BxA== X-Received: by 2002:a5d:4d46:: with SMTP id a6mr36396029wru.142.1558095725080; Fri, 17 May 2019 05:22:05 -0700 (PDT) Received: from dario-XPS-13-9370.gmail.com (p4FE1B137.dip0.t-ipconnect.de. [79.225.177.55]) by smtp.gmail.com with ESMTPSA id 19sm6997730wmk.3.2019.05.17.05.22.03 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 May 2019 05:22:04 -0700 (PDT) From: Dario Gjorgjevski Date: Fri, 17 May 2019 14:22:02 +0200 Message-ID: <87pnohb79x.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::431 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain The customization type of recentf-max-saved-items is currently defined as integer, which does not include nil in its domain. However, setting 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.) --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Customization-type-of-recentf-max-saved-items.patch Content-Description: Change customization type of recentf-max-saved-items to allow for nil >From a62b4c6208f9d64bc49499855e65ae9b9a55b01e Mon Sep 17 00:00:00 2001 From: Dario Gjorgjevski Date: Fri, 17 May 2019 11:46:54 +0200 Subject: [PATCH] Customization type of recentf-max-saved-items --- lisp/recentf.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/recentf.el b/lisp/recentf.el index 9b70017a38..4112b44e48 100644 --- a/lisp/recentf.el +++ b/lisp/recentf.el @@ -67,7 +67,8 @@ You should define the options of your own filters in this group." A nil value means to save the whole list. See the command `recentf-save-list'." :group 'recentf - :type 'integer) + :type '(choice (integer :tag "Entries" :value 1) + (const :tag "No Limit" nil))) (defcustom recentf-save-file (locate-user-emacs-file "recentf" ".recentf") "File to save the recent list into." -- 2.20.1 --=-=-= Content-Type: text/plain -- Dario Gjorgjevski :: dario.gjorgjevski@gmail.com :: +389 (0)70 784 142 --=-=-=-- From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2019 13:14: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 To: Dario Gjorgjevski Cc: 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.15580988017083 (code B ref 35771); Fri, 17 May 2019 13:14:01 +0000 Received: (at 35771) by debbugs.gnu.org; 17 May 2019 13:13:21 +0000 Received: from localhost ([127.0.0.1]:57763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRcfn-0001q8-Bh for submit@debbugs.gnu.org; Fri, 17 May 2019 09:13:21 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:36841) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRcfl-0001po-C9 for 35771@debbugs.gnu.org; Fri, 17 May 2019 09:13:18 -0400 Received: by mail-ed1-f68.google.com with SMTP id a8so10544104edx.3 for <35771@debbugs.gnu.org>; Fri, 17 May 2019 06:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=QvewQA2C1v4QYdELtj6KMgpcUY8xdLzRjYT/yLh8kU4=; b=xyKz56rotEMa+BVWwdXu0vhbw6VMPydgMYPTe2hZEmjKVfxoTjBE64p/IRXEboG7Op esuCulmEvuIetV8y3Sx4UKwATQogfAV3bfpRQcmy/v9sMJYR2QuZeuCcL4Sdncq3mJmU GiBZtyEwAcr6i7YM2AjwUiZBlYW/rMMHEtogsG3qq4lAsgBzdYNPT/GnPzxZhDt0M7rg 4U/eKwE3BDCeG/Jhue80nUCppWm+6wJsc6a6v7boqOIPBU52stBTr+IHIQgiyq+suGR0 KF9cQnrK+aVPNVO+WkXO1ldcQY4UWQ4ffQbzLnfHDTLaU7YfZIgBjU/ZHZ51SeNgzMGt DwuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=QvewQA2C1v4QYdELtj6KMgpcUY8xdLzRjYT/yLh8kU4=; b=pXCza54fc4dOv2loWD1j6UeQuMuRCd8QmN2gqykgSDFv6H6cWk6uSLf8GjBjQP3vDU f9DohD2ETeSeLS9zX+03xOUsBMQj5aBwXhjnCrNV+bA4J5Oi5u1qh+lOa8DdXz7Nl9Gf fQ+cANkUchK+KcBnBH+UUkyZt7+n6yvsc9Dqg2G6Fzg33hvHcAM5b2FwZhRpE5jvlD9e HwVNgFXPtZ82QWYdC/Gt4rlQrBe7W4kFnxDlZH45rdIhkyT6Ve4g+MFZGJ62u5NQ4neJ WUGei1SZecsDE1yqKHTmpqZnzkmnuFW0txuFKpylIkcQwu7ySHqzYtVFrvGyqLu3KqSv ATnQ== X-Gm-Message-State: APjAAAWCGE/qylxEY3kvCWgKSSHJqUXW4d38QP08T2OBg1bTYwVnLzr+ 3lEZAoiPxNSQdxuHp0hlFRU2Kg== X-Google-Smtp-Source: APXvYqzkENzBaJEInsCuMzbRYS/w0jizOuR/pTjYq8jFcjznPs9RtJg7/61H7Iw+oxyyqdcjV9+Cmw== X-Received: by 2002:a17:906:2785:: with SMTP id j5mr44018355ejc.94.1558098791345; Fri, 17 May 2019 06:13:11 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:6fa:38d6:1fce:ddb3]) by smtp.gmail.com with ESMTPSA id r14sm503846edd.0.2019.05.17.06.13.10 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 17 May 2019 06:13:10 -0700 (PDT) From: "Basil L. Contovounesios" References: <87pnohb79x.fsf@gmail.com> Date: Fri, 17 May 2019 14:13:09 +0100 In-Reply-To: <87pnohb79x.fsf@gmail.com> (Dario Gjorgjevski's message of "Fri, 17 May 2019 14:22:02 +0200") Message-ID: <87r28xxlzu.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 35771 minor quit Dario Gjorgjevski writes: > The customization type of recentf-max-saved-items is currently defined > as integer, which does not include nil in its domain. However, setting > this variable to nil is supported in the code and also documented. Indeed. > This patch changes the customization type to explicitly allow for the > variable to be set to nil through the Customization interface and > similar. The change LGTM, thanks. > (Please note that I copied the type from save-place-limit in order to > be consistent.) (I'm curious as to why :value is set to 1 rather than the default values 20 and 400 of the user options recentf-max-saved-items and save-place-limit, respectively. Not an important issue, though.) > From a62b4c6208f9d64bc49499855e65ae9b9a55b01e Mon Sep 17 00:00:00 2001 > From: Dario Gjorgjevski > Date: Fri, 17 May 2019 11:46:54 +0200 > Subject: [PATCH] Customization type of recentf-max-saved-items See the outlines "Commit messages" and "Generating ChangeLog entries" in the file CONTRIBUTE for the preferred commit message format. In particular, it should mention the names of the file and variable changed, as well as the bug#number. The change is small enough to be exempt from copyright paperwork, but if you are interested in contributing more in the future, I recommend starting the assignment process early; see (info "(emacs) Copyright Assignment"). Thanks, -- Basil From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2019 13:35:02 +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 To: "Basil L. Contovounesios" Cc: dario.gjorgjevski@gmail.com, 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155810004417188 (code B ref 35771); Fri, 17 May 2019 13:35:02 +0000 Received: (at 35771) by debbugs.gnu.org; 17 May 2019 13:34:04 +0000 Received: from localhost ([127.0.0.1]:57784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRczr-0004TA-V5 for submit@debbugs.gnu.org; Fri, 17 May 2019 09:34:04 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRczp-0004Sg-Uf for 35771@debbugs.gnu.org; Fri, 17 May 2019 09:34:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRczk-0002nR-N6; Fri, 17 May 2019 09:33:56 -0400 Received: from [176.228.60.248] (port=3512 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hRczc-0000jK-26; Fri, 17 May 2019 09:33:53 -0400 Date: Fri, 17 May 2019 16:33:29 +0300 Message-Id: <831s0xb3yu.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87r28xxlzu.fsf@tcd.ie> (contovob@tcd.ie) References: <87pnohb79x.fsf@gmail.com> <87r28xxlzu.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "Basil L. Contovounesios" > Date: Fri, 17 May 2019 14:13:09 +0100 > Cc: 35771@debbugs.gnu.org > > The change is small enough to be exempt from copyright paperwork, > but if you are interested in contributing more in the future, > I recommend starting the assignment process early; > see (info "(emacs) Copyright Assignment"). Dario has an assignment on file, so we are good. From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2019 13:37: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 To: Dario Gjorgjevski , 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155810020017416 (code B ref 35771); Fri, 17 May 2019 13:37:01 +0000 Received: (at 35771) by debbugs.gnu.org; 17 May 2019 13:36:40 +0000 Received: from localhost ([127.0.0.1]:57789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRd2O-0004Wq-EV for submit@debbugs.gnu.org; Fri, 17 May 2019 09:36:40 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:45364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRd2M-0004Wd-7V for 35771@debbugs.gnu.org; Fri, 17 May 2019 09:36:39 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4HDXv0B030637; Fri, 17 May 2019 13:36:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=r7NK3wqrKQ5/sGbvK5EFBMhLoMp/h5hzHd9QDpD+h1c=; b=gQr9y+b2bspgk2kNVFlxDirNtQexkHIggbGycWKH23QCNe7tML9P75BrFJscNTYn7vVz hsA542x4R9yL+nTyZLs1qF0ZCk534YtUP0oGdK88Ju6KujVcWNAsja6JhTFr8G7L2djb Scj4Uziq7WhJuI6GA6bSwtR4t/ieRR3LSZnNfad/ynSNjkijRoTYlxD9VReRIHeg71KG vjFvotca5qonveTk75VXiyCtr5VO6ft8rj0W+1XB5p6ggA9xtkIVAVcH6F2vx8t+iKHa J9wr7Y+6qAFya9mmcacxqKvstnlJekaNy38A9Do/x4ZUyQFcFgTu1f2pOCsg2gy7+iyi GA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2sdq1r1mgg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 May 2019 13:36:32 +0000 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 x4HDZQui179684; Fri, 17 May 2019 13:36:31 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2sggeua07c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 May 2019 13:36:31 +0000 Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x4HDaUPU029717; Fri, 17 May 2019 13:36:30 GMT MIME-Version: 1.0 Message-ID: <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> Date: Fri, 17 May 2019 06:36:30 -0700 (PDT) From: Drew Adams References: <87pnohb79x.fsf@gmail.com> In-Reply-To: <87pnohb79x.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4849.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9259 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-1905170087 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9259 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=1011 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-1905170087 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > The customization type of recentf-max-saved-items is currently defined > as integer, which does not include nil in its domain. However, setting > this variable to nil is supported in the code and also documented. >=20 > 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. 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.) 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. 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). 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=20 (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))) From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2019 14:16:02 +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 To: Eli Zaretskii Cc: dario.gjorgjevski@gmail.com, 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155810250721778 (code B ref 35771); Fri, 17 May 2019 14:16:02 +0000 Received: (at 35771) by debbugs.gnu.org; 17 May 2019 14:15:07 +0000 Received: from localhost ([127.0.0.1]:58713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRddb-0005fB-1h for submit@debbugs.gnu.org; Fri, 17 May 2019 10:15:07 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:36949) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRddY-0005eL-AF for 35771@debbugs.gnu.org; Fri, 17 May 2019 10:15:05 -0400 Received: by mail-ed1-f66.google.com with SMTP id w37so10823766edw.4 for <35771@debbugs.gnu.org>; Fri, 17 May 2019 07:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=ZCu324p6PVu+0VSyfmmVy9q5/dkoM/u0lPg0HtpIqbM=; b=PBLxicrOvHOweCtU/ppoxqgOkSQzXem60vO8hFmkrhtrHANBf1j3pTEGFDIPN8cL8R VDcuG1y/oqBvaSYhVsApdAR+6Ft13Dx2hUy1DUdJEwDJMc6oi7C4ICfg8YnM8T+eypIL 4nMxTmkqHmnfbdHxDAl7uoUrc+lsfqZXufhU70HDZZLPa+U3JT9xNSWWjP+wlAmS5qV4 9XrS0aMPLnkl9mdzfdoakhv72l5nl4IqO7pnrzfMdapvyD2nzbUjaxH6gu4hf9RVaIOj ZmUu5bLt1lg0r5Gj+9Ail+wRWaR5VArTTi8OnT1WKJ1+Vbpo+o8+azpz3ocyz8/qosPY wsKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=ZCu324p6PVu+0VSyfmmVy9q5/dkoM/u0lPg0HtpIqbM=; b=kllJ8fenBQuq48E2yRppmmwpRAh9S7ZJoMnT4XDUg5EiHX3QnpFzG0a8ZQje+5F6Zh ohpL74eHIUJOXou+4g5KuHasWrRIRvogVfZdOY/ljRyUqnrBhZJTXA3+IevF2i2Dxb2V Owb6V5hsL5J1FIIqYViR42eOImptrzDhc0k6k1zIc/KJn1q0QZ3/kuusdfZzxAqwaUx9 ETtixZhojvQtsaPQMyBTCBX6AH1HX8FgmnN88oAkTYIwzEt+C9/NGjYDtmIqYfLiwBoP EIjc7hkDI8BTqQ225WJTNezBzqGSqmqr7lKFo/r/uMCcVRFM1KnOaRPsyTyo64Q9L5iA Mr3A== X-Gm-Message-State: APjAAAX/mjXoHDz35ihcs4xwDiN069wijvHC8Ux3v7Vnjm8JLYKopfOh hDVLCz1wwdqxvxVCT82JCoaohg== X-Google-Smtp-Source: APXvYqwsP285iOx4QgZ7tWx+jRJoK4foJn9gHoXlZg5XwFw5PG2++b2aHp1woJhUYDq8i76qL/9zuQ== X-Received: by 2002:a50:91d0:: with SMTP id h16mr57788977eda.265.1558102498563; Fri, 17 May 2019 07:14:58 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:6fa:38d6:1fce:ddb3]) by smtp.gmail.com with ESMTPSA id h20sm1581242eja.37.2019.05.17.07.14.57 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 17 May 2019 07:14:57 -0700 (PDT) From: "Basil L. Contovounesios" References: <87pnohb79x.fsf@gmail.com> <87r28xxlzu.fsf@tcd.ie> <831s0xb3yu.fsf@gnu.org> Date: Fri, 17 May 2019 15:14:56 +0100 In-Reply-To: <831s0xb3yu.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 17 May 2019 16:33:29 +0300") Message-ID: <875zq9w4kf.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Date: Fri, 17 May 2019 14:13:09 +0100 >> Cc: 35771@debbugs.gnu.org >> >> The change is small enough to be exempt from copyright paperwork, >> but if you are interested in contributing more in the future, >> I recommend starting the assignment process early; >> see (info "(emacs) Copyright Assignment"). > > Dario has an assignment on file, so we are good. Great, sorry for not asking first. Once Dario submits a log message, will this change be suitable for emacs-26? Thanks, -- Basil From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2019 14:19: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 To: Drew Adams Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155810268722072 (code B ref 35771); Fri, 17 May 2019 14:19:01 +0000 Received: (at 35771) by debbugs.gnu.org; 17 May 2019 14:18:07 +0000 Received: from localhost ([127.0.0.1]:58719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRdgU-0005jw-IW for submit@debbugs.gnu.org; Fri, 17 May 2019 10:18:06 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:33052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRdgS-0005jT-I1 for 35771@debbugs.gnu.org; Fri, 17 May 2019 10:18:04 -0400 Received: by mail-ed1-f65.google.com with SMTP id n17so10896451edb.0 for <35771@debbugs.gnu.org>; Fri, 17 May 2019 07:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=iC1vEFJcZRt17kwaF1FkM/hmBtyCsOGb2RpDSEmbIUw=; b=NDTEZ6oWSa7sG6zA+4O4go1bcHJnr1Td2kUm5z6nVTpXvywxkjiDO7PaD8VYRV0YSI grqxJKzNw06OzPNeO6HzGZ67HsEdsbE81sdnvFyMXMSfy+l0LEVMTSVuZ+zbh5x7l8T6 rhS2Msk8iBUYDheuCk8j/yqa1rPnu/V4q6RpNQjbvQ19cAb4O1dokaeQ4BAnM/HUggSA Q6GcNXifCWumUA48Y8tIM2jriq1ucUHCrUWKb0jL/xFcypuM/dgHZfuqckz6ZZ+hwXiI mUoqSESK5VyEkJqEEnPdhjNg+P6uILadIhtBVpuZQCZ160LZ3PiPD0X5xjeH+Tmz/JeO cEQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=iC1vEFJcZRt17kwaF1FkM/hmBtyCsOGb2RpDSEmbIUw=; b=bjuIVEjxpBYcf3iy0ykgH9WKVmcvIkBkdpYQkHtnj27fhZB8LOLUQqG4ap9/bYut/h wqDNp5DvKGmcmIKrsRl2pfRAX84SZnWtQurUJSUhDcPw3YZlAgnKKyYHbnlRcfaSCA66 eMZjEWIFY/CAZJm1aUPoI20YjqpaHQwULPyydG50sUoa91rBb6dfgtfdmyEnMlYFJAOx 4F6/Ps0IAg3tMrYYDFORt2HhsoQBShKGhVLXRP3uRwg4Km3TpZPk7S4b3pOyYEK6KeV1 qv2EsJod8D5me1DG8WnGRckZU097Y6NAvjAJnIOpmSQYsVemPJD1QGFgPqZSVHM90oEt r4Qg== X-Gm-Message-State: APjAAAUdGGengdkcWojdFw+FtLoWy3tyZ/uwGACCTZmQZZEQB7VNeX1L EhINbuFv/yF28Lw//jDWINY5jw== X-Google-Smtp-Source: APXvYqyKFNafmgU7ILvSzoKr2TbupNqMiIhzEyFIY59UI6qaiWMtAdE1zKg2p4Wi3S0CQHEBjd2DDw== X-Received: by 2002:a50:ad77:: with SMTP id z52mr58028813edc.174.1558102678936; Fri, 17 May 2019 07:17:58 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:6fa:38d6:1fce:ddb3]) by smtp.gmail.com with ESMTPSA id o3sm1541418ejb.71.2019.05.17.07.17.58 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 17 May 2019 07:17:58 -0700 (PDT) From: "Basil L. Contovounesios" References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> Date: Fri, 17 May 2019 15:17:57 +0100 In-Reply-To: <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> (Drew Adams's message of "Fri, 17 May 2019 06:36:30 -0700 (PDT)") Message-ID: <87woipupuy.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. Drew Adams writes: >> The customization type of recentf-max-saved-items is currently defined >> as integer, which does not include nil in its domain. However, setting >> 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. 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. 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. > 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.) I'd welcome a natnum type. > 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. 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. > 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). 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. > 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))) 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. Thanks, -- Basil From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2019 14:41:02 +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 To: "Basil L. Contovounesios" Cc: dario.gjorgjevski@gmail.com, 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155810400732158 (code B ref 35771); Fri, 17 May 2019 14:41:02 +0000 Received: (at 35771) by debbugs.gnu.org; 17 May 2019 14:40:07 +0000 Received: from localhost ([127.0.0.1]:58739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRe1m-0008Mb-QT for submit@debbugs.gnu.org; Fri, 17 May 2019 10:40:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRe1l-0008M2-4N for 35771@debbugs.gnu.org; Fri, 17 May 2019 10:40:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRe1f-00078f-Qi; Fri, 17 May 2019 10:39:59 -0400 Received: from [176.228.60.248] (port=3872 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hRe1d-0004zV-2z; Fri, 17 May 2019 10:39:59 -0400 Date: Fri, 17 May 2019 17:39:37 +0300 Message-Id: <83v9y99mc6.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <875zq9w4kf.fsf@tcd.ie> (contovob@tcd.ie) References: <87pnohb79x.fsf@gmail.com> <87r28xxlzu.fsf@tcd.ie> <831s0xb3yu.fsf@gnu.org> <875zq9w4kf.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "Basil L. Contovounesios" > Cc: , <35771@debbugs.gnu.org> > Date: Fri, 17 May 2019 15:14:56 +0100 > > Once Dario submits a log message, will this change be suitable for > emacs-26? Assuming the patch won't become significantly more complex, yes. From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items 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 To: "Basil L. Contovounesios" Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.15581071824648 (code B ref 35771); Fri, 17 May 2019 15:34:01 +0000 Received: (at 35771) by debbugs.gnu.org; 17 May 2019 15:33:02 +0000 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 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 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== 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 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 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 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 MIME-Version: 1.0 Message-ID: Date: Fri, 17 May 2019 08:30:49 -0700 (PDT) From: Drew Adams References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 May 2019 16:59: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 To: Drew Adams Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155819871227645 (code B ref 35771); Sat, 18 May 2019 16:59:01 +0000 Received: (at 35771) by debbugs.gnu.org; 18 May 2019 16:58:32 +0000 Received: from localhost ([127.0.0.1]:32883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hS2fH-0007Bo-LO for submit@debbugs.gnu.org; Sat, 18 May 2019 12:58:32 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:44616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hS2fD-0007BV-ID for 35771@debbugs.gnu.org; Sat, 18 May 2019 12:58:29 -0400 Received: by mail-wr1-f44.google.com with SMTP id c5so10117015wrs.11 for <35771@debbugs.gnu.org>; Sat, 18 May 2019 09:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=wcLuMpS9ndLdgdFQE8POChTvJ4JmazKk0MzAEJ2VjwM=; b=JiQVhQqYcsGTtXNhv4ZZRQsdL9iGjvkX8NgpB9vUyIJ4E53rQmXNKDR0PG7o+zANoL GPdVmO80FMZZlyow4M1J0wpE+8rcNf7pD5918ummwlDE0srTm7hhpm/1aEnGeU4KqWmy ReAP754n6kI0pPziS39Je8VwOuZYXKDXqJSjlqqztWxWpcVgnQ/M3wHXBDHaWaXkLxeo 59q7VjEzZIzZCZbIo/q83JuMSCIO+zgA8mNu1gI4hQ5rAfOmtznQosrA23yB9eFc/+f2 mIjV9RQhkKn1LU5z8UFyVvtYXp9VHor1hwauYMYZjjt+79S5dqGBB3JaH3oyARFJfqzC eP3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=wcLuMpS9ndLdgdFQE8POChTvJ4JmazKk0MzAEJ2VjwM=; b=s8MOYYYQQhXwWNcePfc3MpHeI/0pLKlXS4wYm4LoC3yWppLlveRZrkVXkQ8Mm7imsk 3vJIaaRRvnYaMfPV4MgbK5NRxYn9jUW6gYdazU1zCtYHUdIsA7tvnxgD1wgrsHxpoSJN Mnzl0dKzpLe5fOUDK6rf46S4IvGZBUJnGeYG1ZbfM4PV/jrQON1J07pTu+PPiVSKlwgr ytnP85CQC/jamu+Q4OqZijx6yWHq2Qrkc748aH/CHIPcydZ4tyLLC1OBtAS/oV5ctXKe G2+dCnvuviaUNI21ZWtxY3TzxESBo7JcKKQRz+kwVjab42ZWcFF+6GGe6AJOWxpJwOrN 262Q== X-Gm-Message-State: APjAAAXQxtlxlMOD6Aoy8OESZiAKeRMCt3BidrahNi2vRaX6M270NexR ez3JVWNBFE93zqFriZ2euZd6aQ== X-Google-Smtp-Source: APXvYqwiBCOy8ywB2AlK6su/6jTg8IgpJ5OlWPuJNeIc0hLiPo8rX+eR5yylMq+5ydC6zvJ+SoR2ug== X-Received: by 2002:adf:ec0b:: with SMTP id x11mr2777674wrn.88.1558198701577; Sat, 18 May 2019 09:58:21 -0700 (PDT) Received: from localhost ([163.172.211.46]) by smtp.gmail.com with ESMTPSA id e8sm27154872wrc.34.2019.05.18.09.58.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 18 May 2019 09:58:20 -0700 (PDT) From: "Basil L. Contovounesios" References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> Date: Sat, 18 May 2019 17:58:15 +0100 In-Reply-To: (Drew Adams's message of "Fri, 17 May 2019 08:30:49 -0700 (PDT)") Message-ID: <87r28vwvh4.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Drew Adams writes: >> 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". Sure, but it applies also to all other user options of a similar nature, and concerns a potential change in general Elisp conventions, so I would rather it were discussed on its own and with other people included, and any conclusions reported as wishlists and/or documented. >> >> The customization type of recentf-max-saved-items is currently defined >> >> as integer, which does not include nil in its domain. However, setting >> >> 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. >> >> 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. >> >> 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 > percolate through the code. No-one is letting a negative value 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? This bug report is about fixing the custom :type to include nil as an accepted value, which the submitted patch fixes in a way suitable for inclusion in emacs-26. I would rather we dealt with one issue at a time. >> > 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.) >> >> I'd welcome a natnum type. >> >> > 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. >> >> 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". Hence my welcoming of a new simple type natnum. But in this case there is nothing wrong with using the integer type. > 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.) FWIW, I am neither ignorant of it, nor too lazy to use it; rather, in my limited experience, I have yet to author or review a case where it is truly "needed", this report included. Existing precedent says the integer type is fine even when dealing with nonnegative sizes. If you prefer to use a more accurate natnum type in these cases, which I sympathise with, then please submit a feature request for this, if one does not already exist. I think it is wrong to start using restricted-sexp to emulate a natnum type in an ad hoc way. > 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. It is not irrelevant. First, authors cannot rely on the custom :type alone to tell users what qualifies as an expected value; the docstring must also contain this information. This encourages writing better docstrings and is how users may know not to set recentf-max-saved-items to a negative number, regardless of whether its custom :type is integer or natnum. Emacs customisations have worked fine like this until now. Second, application code must work correctly regardless of the custom :type. Since Elisp is not a strongly typed language, the programmer can only assume that the user has understood the docstring and hasn't set the user option to a silly value. > 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. As long as "more love" means smarter, not more, use, then I agree. >> > 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). >> >> 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). I meant neither of those things. What I meant is KISS: a good-enough but simple custom :type is far better than a more accurate but more complicated one, especially in the context of something as trivial as a natnum. There is no need to encourage complicated (and very easily buggy) logic in defcustoms when a simpler solution will do. > 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. Agreed. >> > 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))) >> >> 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. No, I'm voting against the general notion of trying to specify more than is necessary, just because we can. > 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 welcome a natnum type because it is simple, informative, and declarative and can be used universally. Elisp already has unrestricted typing, so I don't pretend otherwise. > 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. Then please submit a report for that, if one does not already exist. > Do I think we should use `restricted-sexp' even when a > simpler type spec is available to accomplish the same > thing? Of course not. Agreed. Just one opinion, -- Basil From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 May 2019 23:12:02 +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 To: "Basil L. Contovounesios" Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155822106914988 (code B ref 35771); Sat, 18 May 2019 23:12:02 +0000 Received: (at 35771) by debbugs.gnu.org; 18 May 2019 23:11:09 +0000 Received: from localhost ([127.0.0.1]:33209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hS8Tt-0003tf-6a for submit@debbugs.gnu.org; Sat, 18 May 2019 19:11:09 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:41246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hS8Tp-0003t6-SY for 35771@debbugs.gnu.org; Sat, 18 May 2019 19:11:08 -0400 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 x4IN9Cem148440; Sat, 18 May 2019 23:10:57 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; s=corp-2018-07-02; bh=zV3Q/lznqkxQQ9iX3q5hvdNk/XUlfFffpawkT8idWAE=; b=tWYeK0No7KwBKO6bTCgLiSWIJXQQlqGYDKer3axqiVvcBG0yLUhj4gHaB63xaHL7K+d/ bdPhyrlnp0YsFdbMWLmtSZZFMNhTqb64TJ3Vp0E/zubOH5uc0nAPW8hlP2PUvM5Ju2w2 3KkjikekgW82JaDusgojsoWcjJ8l6iVlkZCgszy9tNcPFKTBhVvPLy6bAv8ZYMPYwAUQ R1SyblgQRvQJLgjgy+vyuFOXKaHt0Fnm8Na7mF9UiH5ChpitBwG/TxGZ2glP2uEWLbwu JJCNHITlK69fhT5OyFkAuM3yK30dc1jQXMkcrQWJDXjGjz/2U1w3Gt8NejXTV4jhsUAi KA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2sj9ft1uyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 May 2019 23:10:57 +0000 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 x4IN9XYl182854; Sat, 18 May 2019 23:10:56 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2sj839ypx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 May 2019 23:10:56 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x4INAmYZ023381; Sat, 18 May 2019 23:10:50 GMT MIME-Version: 1.0 Message-ID: <11926b48-89a8-47f9-bce9-f71ad6aa2a57@default> Date: Sat, 18 May 2019 16:10:46 -0700 (PDT) From: Drew Adams References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> <87r28vwvh4.fsf@tcd.ie> In-Reply-To: <87r28vwvh4.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)] Content-Type: multipart/mixed; boundary="__1558221048002289683abhmp0017.oracle.com" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9261 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-1905180167 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9261 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-1905180167 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --__1558221048002289683abhmp0017.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > >> 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". >=20 > Sure, but it applies also to all other user options of a similar nature, Irrelevant here. This is no different from suggesting clearer or more correct doc-string wording or fixing an off-by-one error. It pertains to _this_ bug. Whether there might be other, similar bugs is irrelevant to whether it should be taken into account for fixing this one. > and concerns a potential change in general Elisp conventions, What potential change would that be? Is there some existing Elisp convention that says :type should be mistyped or should be the loosest possible type in preference to the most accurate type? Does some convention recommend omitting :type altogether, to keep things simple? > so I would rather it were discussed on its own > and with other people included, and any conclusions > reported as wishlists and/or documented. Don't know what you're aiming for. There's no reason not to fix this bugged occurrence just because you also see the possibility that similar problems can exist elsewhere. I already provided simple code to fix this one. What's the problem? Why not help users now by letting Customize properly support the allowable/ expected set of values for this option? > > see, again, the Subject line - why not fix it right? >=20 > This bug report is about fixing the custom :type to include nil as an > accepted value, which the submitted patch fixes in a way suitable for > inclusion in emacs-26. I would rather we dealt with one issue at a > time. Then please fix it properly in a second step, if you prefer. There's no need for you (or me) to file another report to get the customization type fixed as it should be for this option. > in this case there is nothing wrong with using the integer type. Nothing wrong with using `number' either, in that case. Nothing wrong with using `sexp' either, in that case. If you don't want to specify the type then don't specify the type - anything at all will do: nothing wrong, as you say. To me that flies in the face of why we even have :type. But hey - we _don't_ have :type! It's optional. Who needs pesky old :type? Do as you like, including doing nothing. > > 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.) >=20 > FWIW, I am neither ignorant of it, nor too lazy to use it; rather, in my > limited experience, I have yet to author or review a case where it is > truly "needed", this report included. Tautology, if you define "truly needed" by never needed at all, which seems to be your point of view. But if that's not really your view, what would you say is "needed" in the attached cases (from my code)? `sexp'? Something more than `sexp', but avoiding `restricted-sexp' (what)? Would you submit a bug report for each case, to add new simple types to avoid use of `restricted-sexp'? When do you think `restricted-sexp' should be used? It sounds like the answer is "never". Since Lisp does not have typed variables (it does have typed values, of course), I suppose you'd just rely on the doc string as sole help for users trying to customize the value. Is that it? > Existing precedent says the integer type is fine even when dealing with > nonnegative sizes. If you prefer to use a more accurate natnum type in > these cases, which I sympathise with, then please submit a feature > request for this, if one does not already exist. I think it is wrong to > start using restricted-sexp to emulate a natnum type in an ad hoc way. With that point of view the `sexp' type is fine when dealing with _any_ defcustom. It will surely help avoid the danger of "overspecifying". Go for it. IMO "existing precedent" when it comes to defcustom is sometimes not so great. Just like some developers don't spend enough attention on doc strings, so some don't spend enough attention on defcustom types. (This bug report is a case in point, no?) That's one reason users give up on using Customize: it's too often not so helpful (no completion when completion could help, for example). We've fixed some such oversights in the past, but there are likely more. Emacs developers themselves have been clear now and then that they mostly don't use Customize, and that shows in the lack of love and attention they give defcustoms sometimes. Emacs can help users more. > > 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. >=20 > It is not irrelevant. First, authors cannot rely on the custom :type > alone to tell users what qualifies as an expected value;=20 That has nothing to do with "not everyone uses Customize". Even if everyone did use Customize you would not be able to rely on :type alone to tell users what values are acceptable. And no one has said that one can, or should be able to, rely on :type alone. Totally a red herring. You may not see it as irrelevant, but I do. > the docstring must also contain this information. You make it sound like having to describe the type of the option is an unfortunate _extra_ thing that authors have to do. It's not. A doc string is a normal part of defun, defvar, defconst, defmacro, etc. (Just because `interactive' might control input values, that doesn't mean that we don't need to also document them in the doc string. Code controlling things properly doesn't obviate the need for user help. Nothing replaces doc strings.) Having to describe the accepted value types in the doc string is a red herring - unrelated to the separate need to specify a proper :type. In one case you're talking directly to the user. In the other case you're communicating to Customize (which in turn talks to the user in its own way). > This encourages writing better docstrings=20 What? What encourages writing better doc strings? Not having good :type values? By that logic `sexp' will be ideal as :type, _really_ encouraging good doc strings. Just don't use :type at all - get great doc. > and is how users may know not to set recentf-max-saved-items > to a negative number, regardless of whether its custom :type is integer > or natnum. Emacs customisations have worked fine like this until now. Again, if your argument is that doc strings alone suffice and are the best way or the only good way to specify the type, then :type 'sexp is called for in all cases (or just don't use :type ever, which amounts to the same thing). > Second, application code must work correctly regardless of the custom > :type. Again, irrelevant. Of course it must work correctly. Doc strings are needed anyway. And code must work correctly anyway. So what? How does either of those requirements suggest that we don't need to tell Customize what the :type is? > Since Elisp is not a strongly typed language, the programmer can > only assume that the user has understood the docstring and hasn't set > the user option to a silly value. Why do you think defcustom has a :type at all? Was adding that just misguided "overspecifying" by some overeager implementor? > > 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. >=20 > As long as "more love" means smarter, not more, use, then I agree. It means using :type to specify the relevant/good values; :set to specify any special behavior needed each time it is set; :init to specify any special behavior needed when it's initialized; correct and complete doc strings to help users understand what the option is for - what the option does/means; and so on. That you _can_ get away with specifying a minimal :type is not a reason to do so. That Lisp variables are untyped is not a reason not to specify and document the expected/allowed values. > > 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. >=20 > Agreed. A good start. > >> FWIW, my vote is against both trying to overspecify custom types, and > >> using restricted-sexp for such simple examples. > > > > "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. >=20 > No, I'm voting against the general notion of trying to specify more than > is necessary, just because we can. Define "necessary". Lisp variables being untyped, and especially given a doc string that specifies the type (expected/allowed values), wanting to be strictly and minimally "necessary", which I guess is what you espouse, calls for :type 'sexp in all cases (i.e., never use :type at all). No danger, if you do that, of accidentally writing the wrong expression for :type and introducing a bug. No need for anything more complex, no "overspecifying", since the doc string does all that's needed. Go for it. Oh, and since not everyone uses Customize, no real need to use defcustom at all - just use defvar in all cases. No danger of a miscoded :set, no confusing users with the Customize UI - LOTS of nasty problems evacuated. Go for it. > > 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. >=20 > Then please submit a report for that, if one does not already exist. Just use :type 'sexp (or just omit :type). Easier for everyone. KISS, as you say. --__1558221048002289683abhmp0017.oracle.com Content-Type: application/octet-stream; name="foo.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="foo.el" KGRlZmN1c3RvbSBiYXIgKCkKICAiTGlzdCBvZiBjdXN0b20gdGhlbWVzIGZvci4uLiIKICA6dHlw ZSAnKHJlcGVhdCAocmVzdHJpY3RlZC1zZXhwCiAgICAgICAgICAgICAgICAgIDptYXRjaC1hbHRl cm5hdGl2ZXMKICAgICAgICAgICAgICAgICAgKChsYW1iZGEgKHN5bWIpIChtZW1xIHN5bWIgKGN1 c3RvbS1hdmFpbGFibGUtdGhlbWVzKSkpKSkpCiAgOmdyb3VwICdmb29iYXIpCgooZGVmY3VzdG9t IGZvbyAoKQogICIuLi4KVGhlIG9wdGlvbiB2YWx1ZSBpcyBhIGxpc3QuICBFYWNoIGVsZW1lbnQg ZGVmaW5lcyBhIHN1Ym1lbnUgb3IgYSBtZW51Cml0ZW0uICBBIG51bGwgZWxlbWVudCAoYG5pbCcp IGlzIGlnbm9yZWQuCgpTZXZlcmFsIGFsdGVybmF0aXZlIGVudHJ5IGZvcm1hdHMgYXJlIGF2YWls YWJsZS4gIFdoZW4gY3VzdG9taXppbmcsCmNob29zZSBhbiBhbHRlcm5hdGl2ZSBpbiB0aGUgQ3Vz dG9taXplIGBWYWx1ZSBNZW51Jy4KCkluIHRoaXMgZGVzY3JpcHRpb246CiBTWU1CT0wgICAgICBp cyBhIHN5bWJvbCBpZGVudGlmeWluZyB0aGUgbWVudSBlbnRyeS4KIGBtZW51LWl0ZW0nIGlzIGp1 c3QgdGhhdCB0ZXh0LCBsaXRlcmFsbHkuCiBOQU1FICAgICAgICBpcyBhIHN0cmluZyBuYW1pbmcg dGhlIG1lbnUgaXRlbSBvciBzdWJtZW51LgogQ09NTUFORCAgICAgaXMgdGhlIGNvbW1hbmQgdG8g YmUgaW52b2tlZCBieSBhbiBpdGVtLgogTUVOVS1LRVlNQVAgaXMgYSBtZW51IGtleW1hcCBvciBh IHZhciB3aG9zZSB2YWx1ZSBpcyBhIG1lbnUga2V5bWFwLgogS0VZV09SRFMgICAgaXMgYSBwcm9w ZXJ0eSBsaXN0IG9mIG1lbnUga2V5d29yZHMgKGA6ZW5hYmxlJywKICAgICAgICAgICAgIGA6dmlz aWJsZScsIGA6ZmlsdGVyJywgYDprZXlzJywgZXRjLikuCgoxLiBTaW5nbGUgbWVudSBpdGVtLiAg Rm9yIGEgc2VsZWN0YWJsZSBpdGVtLCB1c2UKICAgKFNZTUJPTCBtZW51LWl0ZW0gTkFNRSBDT01N QU5EIC4gS0VZV09SRFMpLiAgRm9yIGEgbm9uLXNlbGVjdGFibGUKICAgaXRlbSBzdWNoIGFzIGEg c2VwYXJhdG9yLCB1c2UgKFNZTUJPTCBOQU1FKSBvcgogICAoU1lNQk9MIG1lbnUtaXRlbSBOQU1F IG5pbCAuIEtFWVdPUkRTKS4KCjIuIEl0ZW1zIHRha2VuIGZyb20gYSBtZW51LWtleW1hcCB2YXJp YWJsZSwgc3VjaCBhcwogICBgbWVudS1iYXItZWRpdC1tZW51Jy4gIEp1c3QgdXNlIHRoZSBuYW1l IG9mIHRoZSB2YXJpYWJsZSAoYQogICBzeW1ib2wpLiAgVGhlIGl0ZW1zIGFwcGVhciBhdCB0aGUg dG9wIGxldmVsIG9mIHRoZSBwb3B1cCBtZW51LCBub3QKICAgaW4gYSBzdWJtZW51LgoKMy4gU3Vi bWVudS4gIFVzZSAoU1lNQk9MIG1lbnUtaXRlbSBOQU1FIE1FTlUtS0VZTUFQIC4gS0VZV09SRFMp IG9yCiAgIChTWU1CT0wgTkFNRSAuIE1FTlUtS0VZTUFQKS4gIFJlbWVtYmVyIHRoYXQgTUVOVS1L RVlNQVAgY2FuIGFsc28gYmUKICAgYSB2YXJpYWJsZSAoc3ltYm9sKSB3aG9zZSB2YWx1ZSBpcyBh IG1lbnUga2V5bWFwLgoKQWxsIG9mIHRoZXNlIGFyZSBzdGFuZGFyZCBtZW51IGVsZW1lbnRzLCB3 aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlIHVzZQpvZiBhIGtleW1hcCB2YXJpYWJsZSB0byByZXBy ZXNlbnQgaXRzIHZhbHVlLgoKU2VlIGFsc286CiAqIChlbGlzcCkgRm9ybWF0IG9mIEtleW1hcHMK ICogKGVsaXNwKSBDbGFzc2lmeWluZyBFdmVudHMKICogKGVsaXNwKSBFeHRlbmRlZCBNZW51IEl0 ZW1zCgpFeGFtcGxlIHN1Ym1lbnUgZWxlbWVudDoKICh0b3RvIG1lbnUtaXRlbSBcIlRvdG9cIiBt ZW51LWJhci10b3RvLW1lbnUpCgpFeGFtcGxlIHNlbGVjdGFibGUgbWVudS1pdGVtIGVsZW1lbnQ6 CiAoZm9vIG1lbnUtaXRlbSBcIkZvb1wiICAgZm9vLWNvbW1hbmQKICAgICAgIDp2aXNpYmxlIChu b3QgYnVmZmVyLXJlYWQtb25seSkpIgogIDp0eXBlICAnKHJlcGVhdAogICAgICAgICAgIChjaG9p Y2UKICAgICAgICAgICAgOzsgVGhlc2UgY291bGQgYmUgY29tYmluZWQsIGJ1dCBpdCdzIGJldHRl ciBmb3IgdXNlcnMgdG8gc2VlIHNlcGFyYXRlIGNob2ljZXMuCiAgICAgICAgICAgIChyZXN0cmlj dGVkLXNleHAKICAgICAgICAgICAgIDp0YWcgIlN1Ym1lbnUgKFNZTUJPTCBtZW51LWl0ZW0gTkFN RSBNRU5VLUtFWU1BUCAuIEtFWVdPUkRTKSBvciAoU1lNQk9MIE5BTUUgLiBNRU5VLUtFWU1BUCki CiAgICAgICAgICAgICA6bWF0Y2gtYWx0ZXJuYXRpdmVzCiAgICAgICAgICAgICAoKGxhbWJkYSAo eCkKICAgICAgICAgICAgICAgIChhbmQgKGNvbnNwIHgpIChzeW1ib2xwIChjYXIgeCkpCiAgICAg ICAgICAgICAgICAgICAgIChvciAoYW5kIChzdHJpbmdwIChjYWRyIHgpKSAoY2RkciB4KSkgOyAo U1lNQk9MIE5BTUUgLiBNRU5VLUtFWU1BUCkKICAgICAgICAgICAgICAgICAgICAgICAgIDs7IChT WU1CT0wgbWVudS1pdGVtIE5BTUUgTUVOVS1LRVlNQVAgLiBLRVlXT1JEUykKICAgICAgICAgICAg ICAgICAgICAgICAgIChhbmQgKGVxICdtZW51LWl0ZW0gKGNhZHIgeCkpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChzdHJpbmdwIChjYXIgKGNkZHIgeCkpKQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAob3IgKGtleW1hcHAgKGNhciAoY2RyIChjZGRyIHgpKSkpIDsgQ2FuIGJl IGEga2V5bWFwIHZhci4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChhbmQgKHN5 bWJvbHAgKGNhciAoY2RyIChjZGRyIHgpKSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChib3VuZHAgKGNhciAoY2RyIChjZGRyIHgpKSkpCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChrZXltYXBwIChzeW1ib2wtdmFsdWUgKGNhciAoY2RyIChj ZGRyIHgpKSkpKSkpKSkpKQogICAgICAgICAgICAgICduaWwpKQogICAgICAgICAgICAocmVzdHJp Y3RlZC1zZXhwCiAgICAgICAgICAgICA6dGFnICJJdGVtcyBmcm9tIGEga2V5bWFwIHZhcmlhYmxl J3MgdmFsdWUuIgogICAgICAgICAgICAgOm1hdGNoLWFsdGVybmF0aXZlcyAoKGxhbWJkYSAoeCkg KGFuZCAoc3ltYm9scCB4KSAgKGtleW1hcHAgKHN5bWJvbC12YWx1ZSB4KSkpKQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJ25pbCkpCiAgICAgICAgICAgIChyZXN0cmljdGVkLXNl eHAKICAgICAgICAgICAgIDp0YWcgIlNlbGVjdGFibGUgaXRlbSAoU1lNQk9MIG1lbnUtaXRlbSBO QU1FIENPTU1BTkQgLiBLRVlXT1JEUykiCiAgICAgICAgICAgICA6bWF0Y2gtYWx0ZXJuYXRpdmVz ICgobGFtYmRhICh4KSAoYW5kIChjb25zcCB4KSAgKHN5bWJvbHAgKGNhciB4KSkKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcSAnbWVudS1pdGVtIChjYWRy IHgpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0cmlu Z3AgKGNhciAoY2RkciB4KSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoY29tbWFuZHAgKGNhciAoY2RyIChjZGRyIHgpKSkpKSkKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICduaWwpKQogICAgICAgICAgICAocmVzdHJpY3RlZC1zZXhwCiAg ICAgICAgICAgICA6dGFnICJOb24tc2VsZWN0YWJsZSBpdGVtIChTWU1CT0wgTkFNRSkgb3IgKFNZ TUJPTCBtZW51LWl0ZW0gTkFNRSBuaWwgLiBLRVlXT1JEUykiCiAgICAgICAgICAgICA6bWF0Y2gt YWx0ZXJuYXRpdmVzICgobGFtYmRhICh4KSAoYW5kIChjb25zcCB4KSAgKHN5bWJvbHAgKGNhciB4 KSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChvciAoYW5k IChzdHJpbmdwIChjYWRyIHgpKSAgKG51bGwgKGNhZGRyIHgpKSkKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoYW5kIChlcSAnbWVudS1pdGVtIChjYWRy IHgpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKHN0cmluZ3AgKGNhciAoY2RkciB4KSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAobnVsbCAoY2FyIChjZHIgKGNkZHIgeCkpKSkpKSkp CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnbmlsKSkpKQogIDpncm91cCAnZm9v YmFyKQo= --__1558221048002289683abhmp0017.oracle.com-- From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 May 2019 02:53: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 To: Drew Adams Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.15582343502557 (code B ref 35771); Sun, 19 May 2019 02:53:01 +0000 Received: (at 35771) by debbugs.gnu.org; 19 May 2019 02:52:30 +0000 Received: from localhost ([127.0.0.1]:33546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSBw5-0000fA-Sp for submit@debbugs.gnu.org; Sat, 18 May 2019 22:52:30 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:45860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSBw3-0000ev-LJ for 35771@debbugs.gnu.org; Sat, 18 May 2019 22:52:29 -0400 Received: by mail-ed1-f68.google.com with SMTP id g57so17477017edc.12 for <35771@debbugs.gnu.org>; Sat, 18 May 2019 19:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=xx0ECln9lFS8MfAE5cysCP51vIxaT6IbPudNm15CAGE=; b=kjN0svIN3TVij3eEoKOxgjkGl7ACZGr5htRU00DNIErSXrgJ8Ghjk5bSai81TMndAg R8okDypLibGTzF8jLLeSQ+mrQEdUL/CoT1dqvp0MTFbANLobNYYK+0+VAksJ9FKQ7ZdD HRM0DVDNt3BHX+JN50XF4OEev2gI8QEXCF+IOSLt4/LD+0Eueob2iOWqrLfAmVPgU/JJ teEEmBlnEeXBKKDJupo6MpX661OInCU+oKM2VXV13epvLhUQXULLlzzSkWKbIbyiPtUt iyWcEVmyk6lSj++7k/Imn13E1S8v67N2u68G4LuRMI3og5wMcrwucElJNCT/B3Khfvm1 G8gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=xx0ECln9lFS8MfAE5cysCP51vIxaT6IbPudNm15CAGE=; b=i9T5cMsHcmzCPI48xIAwvdFdWNk3y54f1isE0OT5e8qHobaqbE9HUId38ILuv6IVIQ rGocojC67M6HSfi6FXp4cs2tq02S7c751okulV6U8J2vM/I1vPnDwPyHnDQsL5U2CdyE +bv9GsELkc0A99A/HzjwmkKywlDhewwirSmLDHEUFJ+bUn1yO3hfiSctV8bCbw462tZQ 4xb+oqB6/PwcY58dw+XuKtow+UW47GTPi7OAk4ivPr09QpCxOceYGeBdGbKbJOWixm+S TYkt6dABcbKe5Y1CnK5TTRX7ADsNGZteUwZYe2x0GKv0+1ROXlMSQekx3B+v6+lxtlIG ug+A== X-Gm-Message-State: APjAAAWd9GcfhhIdFRkAfDCUbekFx4VuHvRy1BSYDs5dD1Vw3Ax1Wch3 IkmuWS+AOx7l65acZLuklF0u0A== X-Google-Smtp-Source: APXvYqx5j4x84jYLAmAxDyCebYL0gOeh/52jYBlgHSYp0dNBcfv97eikF3jRk6OXfWCgQXrAEqQQEg== X-Received: by 2002:a17:906:7388:: with SMTP id f8mr17790481ejl.231.1558234341480; Sat, 18 May 2019 19:52:21 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:8cad:ae29:555d:852d]) by smtp.gmail.com with ESMTPSA id i33sm4458348ede.47.2019.05.18.19.52.20 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 18 May 2019 19:52:20 -0700 (PDT) From: "Basil L. Contovounesios" References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> <87r28vwvh4.fsf@tcd.ie> <11926b48-89a8-47f9-bce9-f71ad6aa2a57@default> Date: Sun, 19 May 2019 03:52:13 +0100 In-Reply-To: <11926b48-89a8-47f9-bce9-f71ad6aa2a57@default> (Drew Adams's message of "Sat, 18 May 2019 16:10:46 -0700 (PDT)") Message-ID: <87r28vp34y.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Drew Adams writes: >> >> 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". >> >> Sure, but it applies also to all other user options of a similar nature, > > Irrelevant here. This is no different from > suggesting clearer or more correct doc-string > wording or fixing an off-by-one error. > > It pertains to _this_ bug. Whether there might > be other, similar bugs is irrelevant to whether > it should be taken into account for fixing this one. This bug report is about an incorrect custom :type. You're arguing about restricting the custom :type. Having a looser type (integer) than desirable (natnum) is a separate issue, one which I would rather be discussed elsewhere. >> and concerns a potential change in general Elisp conventions, > > What potential change would that be? Either adding and using a new custom :type, or encouraging usage of restricted-sexp instead of integer for nonnegative values. > Is there some existing Elisp convention that says :type should be > mistyped or should be the loosest possible type in preference to the > most accurate type? Does some convention recommend omitting :type > altogether, to keep things simple? Straw man. The de facto convention is indeed that using the integer type is fine even for nonnegative values. >> so I would rather it were discussed on its own >> and with other people included, and any conclusions >> reported as wishlists and/or documented. > > Don't know what you're aiming for. A more democratic discussion in a more appropriate and less opportunistic place. > There's no reason not to fix this bugged occurrence just because you > also see the possibility that similar problems can exist elsewhere. I don't consider this a bug/problem. I consider the addition of a natnum type a nice-to-have, and the use of restricted-sexp here a nonsolution. > I already provided simple code to fix this one. > What's the problem? Why not help users now by > letting Customize properly support the allowable/ > expected set of values for this option? Dario's patch already lets "Customize properly support the allowable expected set of values for this option." >> > see, again, the Subject line - why not fix it right? >> >> This bug report is about fixing the custom :type to include nil as an >> accepted value, which the submitted patch fixes in a way suitable for >> inclusion in emacs-26. I would rather we dealt with one issue at a >> time. > > Then please fix it properly in a second step, if you > prefer. There's no need for you (or me) to file > another report to get the customization type fixed > as it should be for this option. As far as I'm concerned, Dario's patch is the proper fix for this bug, and the second step would be to add a natnum widget, but I can't promise to work on that any time soon, sorry. >> in this case there is nothing wrong with using the integer type. > > Nothing wrong with using `number' either, in that case. > Nothing wrong with using `sexp' either, in that case. > If you don't want to specify the type then don't specify > the type - anything at all will do: nothing wrong, as > you say. > > To me that flies in the face of why we even have :type. > > But hey - we _don't_ have :type! It's optional. Who > needs pesky old :type? Do as you like, including doing > nothing. I didn't say there's nothing wrong with using sexp where integer will do, no need to exaggerate. >> > 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.) >> >> FWIW, I am neither ignorant of it, nor too lazy to use it; rather, in my >> limited experience, I have yet to author or review a case where it is >> truly "needed", this report included. > > Tautology, if you define "truly needed" by never needed > at all, which seems to be your point of view. It's not. > But if that's not really your view, what would you say > is "needed" in the attached cases (from my code)? `sexp'? > Something more than `sexp', but avoiding `restricted-sexp' > (what)? Would you submit a bug report for each case, to > add new simple types to avoid use of `restricted-sexp'? > > When do you think `restricted-sexp' should be used? > It sounds like the answer is "never". It's not. It has its uses, but trying to emulate natnum in an ad hoc way is not one of them. > Since Lisp does not have typed variables (it does have > typed values, of course), I suppose you'd just rely on > the doc string as sole help for users trying to customize > the value. Is that it? No, but docstrings are indispensable regardless. >> Existing precedent says the integer type is fine even when dealing with >> nonnegative sizes. If you prefer to use a more accurate natnum type in >> these cases, which I sympathise with, then please submit a feature >> request for this, if one does not already exist. I think it is wrong to >> start using restricted-sexp to emulate a natnum type in an ad hoc way. > > With that point of view the `sexp' type is fine when > dealing with _any_ defcustom. It will surely help > avoid the danger of "overspecifying". Go for it. You're misconstruing my point. > IMO "existing precedent" when it comes to defcustom > is sometimes not so great. Just like some developers > don't spend enough attention on doc strings, so some > don't spend enough attention on defcustom types. > (This bug report is a case in point, no?) No, this bug report is likely a result of an oversight. > That's one reason users give up on using Customize: > it's too often not so helpful (no completion when > completion could help, for example). We've fixed > some such oversights in the past, but there are > likely more. > > Emacs developers themselves have been clear now and > then that they mostly don't use Customize, and that > shows in the lack of love and attention they give > defcustoms sometimes. Emacs can help users more. Sure, which is why I think discussing this on emacs-devel or in a separate report would be more appropriate and productive. >> > 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. >> >> It is not irrelevant. First, authors cannot rely on the custom :type >> alone to tell users what qualifies as an expected value; > > That has nothing to do with "not everyone uses > Customize". Even if everyone did use Customize you > would not be able to rely on :type alone to tell > users what values are acceptable. > > And no one has said that one can, or should be able > to, rely on :type alone. Totally a red herring. > You may not see it as irrelevant, but I do. > >> the docstring must also contain this information. > > You make it sound like having to describe the type > of the option is an unfortunate _extra_ thing that > authors have to do. That's not what I intended to convey. > It's not. A doc string is a > normal part of defun, defvar, defconst, defmacro, > etc. > > (Just because `interactive' might control input > values, that doesn't mean that we don't need to > also document them in the doc string. Code > controlling things properly doesn't obviate the > need for user help. Nothing replaces doc strings.) > > Having to describe the accepted value types in > the doc string is a red herring - unrelated to > the separate need to specify a proper :type. In > one case you're talking directly to the user. In > the other case you're communicating to Customize > (which in turn talks to the user in its own way). I agree; you seem to have misconstrued my aside. >> This encourages writing better docstrings > > What? What encourages writing better doc strings? > Not having good :type values? By that logic `sexp' > will be ideal as :type, _really_ encouraging good > doc strings. Just don't use :type at all - get > great doc. You seem to have misunderstood me. What I meant is that the docstring anyway has to include the same information that Customize can display, and more. >> and is how users may know not to set recentf-max-saved-items >> to a negative number, regardless of whether its custom :type is integer >> or natnum. Emacs customisations have worked fine like this until now. > > Again, if your argument is that doc strings alone > suffice and are the best way or the only good way > to specify the type, then :type 'sexp is called for > in all cases (or just don't use :type ever, which > amounts to the same thing). That is not my argument. >> Second, application code must work correctly regardless of the custom >> :type. > > Again, irrelevant. Of course it must work correctly. > Doc strings are needed anyway. And code must work > correctly anyway. So what? How does either of those > requirements suggest that we don't need to tell > Customize what the :type is? Neither of those was meant to suggest that, I'm not sure how you reached that conclusion. >> Since Elisp is not a strongly typed language, the programmer can >> only assume that the user has understood the docstring and hasn't set >> the user option to a silly value. > > Why do you think defcustom has a :type at all? Was > adding that just misguided "overspecifying" by some > overeager implementor? No. >> > 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. >> >> As long as "more love" means smarter, not more, use, then I agree. > > It means using :type to specify the relevant/good > values; :set to specify any special behavior needed > each time it is set; :init to specify any special > behavior needed when it's initialized; correct and > complete doc strings to help users understand what > the option is for - what the option does/means; and > so on. > > That you _can_ get away with specifying a minimal > :type is not a reason to do so. That Lisp variables > are untyped is not a reason not to specify and > document the expected/allowed values. Agreed. >> > 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. >> >> Agreed. > > A good start. > >> >> FWIW, my vote is against both trying to overspecify custom types, and >> >> using restricted-sexp for such simple examples. >> > >> > "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. >> >> No, I'm voting against the general notion of trying to specify more than >> is necessary, just because we can. > > Define "necessary". In the case of recentf-max-saved-items, it's Dario's patch. > Lisp variables being untyped, > and especially given a doc string that specifies > the type (expected/allowed values), wanting to be > strictly and minimally "necessary", which I guess > is what you espouse, calls for :type 'sexp in all > cases (i.e., never use :type at all). I disagree. > No danger, if you do that, of accidentally writing > the wrong expression for :type and introducing a > bug. No need for anything more complex, no > "overspecifying", since the doc string does all > that's needed. Go for it. > > Oh, and since not everyone uses Customize, no real > need to use defcustom at all - just use defvar in > all cases. No danger of a miscoded :set, no > confusing users with the Customize UI - LOTS of > nasty problems evacuated. Go for it. No thanks. >> > 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. >> >> Then please submit a report for that, if one does not already exist. > > Just use :type 'sexp (or just omit :type). > Easier for everyone. KISS, as you say. I disagree. I have already presented my arguments and recommended discussing this elsewhere, so I will now remain quiet to give others a chance to chime in. Thanks, -- Basil From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: Dario Gjorgjevski Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 May 2019 09:16: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 To: "Basil L. Contovounesios" Cc: 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.15582573357046 (code B ref 35771); Sun, 19 May 2019 09:16:01 +0000 Received: (at 35771) by debbugs.gnu.org; 19 May 2019 09:15:35 +0000 Received: from localhost ([127.0.0.1]:33772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSHup-0001pZ-Dr for submit@debbugs.gnu.org; Sun, 19 May 2019 05:15:35 -0400 Received: from mail-ed1-f49.google.com ([209.85.208.49]:45984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSHum-0001pI-SO for 35771@debbugs.gnu.org; Sun, 19 May 2019 05:15:33 -0400 Received: by mail-ed1-f49.google.com with SMTP id g57so18437490edc.12 for <35771@debbugs.gnu.org>; Sun, 19 May 2019 02:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=RqiSVaRTsk6zO+DgezCCjY409gxPWHCy9GGApCuLjx4=; b=vKOG15Kb79pH1hAigOJ53RSiPvtCSKR4K0CZbq6PUtzA1jkfKmn7ethpjyHTsOBFqt odeUHOX/SZtsC3qeg9R+ATBavIx1BkYkXVBJlxjXElLUrLlhLAGVu1krw9SjBnvUTUxb homJoaCCH8M+WmtjwkxxQc0wU3KX2lR1QxOUtJaNNMndv1G591A2D3oBZO+5Y7zj5V6f NtMhXeOoEmuut1CU8zRwcfeoy8DpAOwu/w6KqlaxhDtl4iE0jP3YGkFrf1b/cUYW362x YrVuEozymPDa/PN3M/pFn1N8dOjMBYuBLWbajeyJMbuWQRgOpqbzasMhL5vNpszVs3at cu9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=RqiSVaRTsk6zO+DgezCCjY409gxPWHCy9GGApCuLjx4=; b=nn152GeQMxMfcXZQqD7kZvfS8JDYdbAmTcvYIKRFtbOPzFVqDu7ZcmLkeMInLsCyOH LP7nUcs26Zo5DSdnP736TRRPsq8O0nfMZ+J6RTYBCr1sykp2DOgW3/j2APRkA9JPcwwA dCSIDujpng6eayuCZs+bRe/V7oY+usMzkisijvwuH/tmCuMbhfDdT9QTXvV04qSKfFAs NxP2KhQjgxNsiCqiCbHnRCXFwlctrCgc5r9n473WPm7EB/5C1MMcE1XxcuvxoHqojG19 c54nwucjhmbFrvrFFaZwVH2v7q3L/QpEck5WN23n8vSO3ni7vnLrVQcRKPqfOmKUXr5Y /GmA== X-Gm-Message-State: APjAAAVJ8ba3DJVeZKyniyPuOznJF9X0ThNd9ZCSxwNB/qMiVW9XtQK5 HNDf/PQWmKlMonRIAmAoWI/1eV1Q5nM= X-Google-Smtp-Source: APXvYqy2cSHZFBC/HVztVFt2hCQSVlefCUtYV8tEjDQmXF0jWpX6/BCOqe7RlaP+tVj+nA+icta5Eg== X-Received: by 2002:a50:94ed:: with SMTP id t42mr69360723eda.288.1558257326760; Sun, 19 May 2019 02:15:26 -0700 (PDT) Received: from dario-XPS-13-9370.gmail.com (cable-158-181-75-102.cust.telecolumbus.net. [158.181.75.102]) by smtp.gmail.com with ESMTPSA id b53sm3903954edd.89.2019.05.19.02.15.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 19 May 2019 02:15:25 -0700 (PDT) From: Dario Gjorgjevski References: <87pnohb79x.fsf@gmail.com> <87r28xxlzu.fsf@tcd.ie> Date: Sun, 19 May 2019 11:15:24 +0200 In-Reply-To: <87r28xxlzu.fsf@tcd.ie> (Basil L. Contovounesios's message of "Fri, 17 May 2019 14:13:09 +0100") Message-ID: <87pnoe4xg3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain "Basil L. Contovounesios" writes: > (I'm curious as to why :value is set to 1 rather than the default values > 20 and 400 of the user options recentf-max-saved-items and > save-place-limit, respectively. Not an important issue, though.) I was also wondering the same thing. > See the outlines "Commit messages" and "Generating ChangeLog entries" > in the file CONTRIBUTE for the preferred commit message format. > In particular, it should mention the names of the file and variable > changed, as well as the bug#number. Thanks. I am attaching a patch file with a properly formatted commit message. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Customization-type-of-recentf-max-saved-items.patch Content-Description: Change customization type of recentf-max-saved-items to allow for nil >From 46a0d4715ce49aee376a4d253a129c5d6b5b97a8 Mon Sep 17 00:00:00 2001 From: Dario Gjorgjevski Date: Fri, 17 May 2019 11:46:54 +0200 Subject: [PATCH] Customization type of recentf-max-saved-items Change the customization type of recentf-max-saved-items to include nil, as it is an allowed value (Bug#35771). * lisp/recentf.el (recentf-max-saved-items): Change the customization type in the defcustom. --- lisp/recentf.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/recentf.el b/lisp/recentf.el index 9b70017a38..4112b44e48 100644 --- a/lisp/recentf.el +++ b/lisp/recentf.el @@ -67,7 +67,8 @@ You should define the options of your own filters in this group." A nil value means to save the whole list. See the command `recentf-save-list'." :group 'recentf - :type 'integer) + :type '(choice (integer :tag "Entries" :value 1) + (const :tag "No Limit" nil))) (defcustom recentf-save-file (locate-user-emacs-file "recentf" ".recentf") "File to save the recent list into." -- 2.20.1 --=-=-= Content-Type: text/plain -- Dario Gjorgjevski :: dario.gjorgjevski@gmail.com :: +389 (0)70 784 142 --=-=-=-- From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 May 2019 05:29: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 To: "Basil L. Contovounesios" Cc: dario.gjorgjevski@gmail.com, 35771@debbugs.gnu.org, drew.adams@oracle.com Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155850290110623 (code B ref 35771); Wed, 22 May 2019 05:29:01 +0000 Received: (at 35771) by debbugs.gnu.org; 22 May 2019 05:28:21 +0000 Received: from localhost ([127.0.0.1]:41403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTJnZ-0002lH-Jj for submit@debbugs.gnu.org; Wed, 22 May 2019 01:28:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTJnX-0002ky-N5 for 35771@debbugs.gnu.org; Wed, 22 May 2019 01:28:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTJnS-000082-5A; Wed, 22 May 2019 01:28:14 -0400 Received: from [176.228.60.248] (port=1440 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hTJnR-0007SZ-1I; Wed, 22 May 2019 01:28:13 -0400 Date: Wed, 22 May 2019 08:28:18 +0300 Message-Id: <83mujf83d9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87r28vp34y.fsf@tcd.ie> (contovob@tcd.ie) References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> <87r28vwvh4.fsf@tcd.ie> <11926b48-89a8-47f9-bce9-f71ad6aa2a57@default> <87r28vp34y.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "Basil L. Contovounesios" > Date: Sun, 19 May 2019 03:52:13 +0100 > Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org > > I have already presented my arguments and recommended discussing this > elsewhere, so I will now remain quiet to give others a chance to chime > in. Chiming in: I think we should install the latest version of the patch, and disregard all the rest. Thanks. From unknown Mon Sep 08 10:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 May 2019 00:22:02 +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 To: Dario Gjorgjevski Cc: 35771@debbugs.gnu.org Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155857091212972 (code B ref 35771); Thu, 23 May 2019 00:22:02 +0000 Received: (at 35771) by debbugs.gnu.org; 23 May 2019 00:21:52 +0000 Received: from localhost ([127.0.0.1]:43463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTbUW-0003NA-Do for submit@debbugs.gnu.org; Wed, 22 May 2019 20:21:52 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:33645) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTbUU-0003Ms-1W for 35771@debbugs.gnu.org; Wed, 22 May 2019 20:21:50 -0400 Received: by mail-ed1-f67.google.com with SMTP id n17so6455150edb.0 for <35771@debbugs.gnu.org>; Wed, 22 May 2019 17:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:message-id:references:date:in-reply-to :user-agent:mime-version; bh=T+DQcz1g45ZV1kxXBwHWNlTlOziKRR2ehwRBXDlz9Yo=; b=1D1Vg34DDGE/TDk6j1ib6n4Z9MA3pKCuBg9YoAjhzaEGWj0+WzYfXTXlPTnYq8MrWu ydt7z3NcztqzAf/FZsyLTXDmG2mXyqd2uBo1WtsZ7PJLwC6kh1v2O1sLDqW7rsf5BKyy 1Qf9wOe+yT02tS5UHyUXi33YsEH5l+3vnxRXF5jWINeYpyOtcD8xXp/LL0NL+obat3co curpAXShZUt8rZQWZPwihXaRQGfqOH+qbLt8On2bbQFt0NT+VQtkuQs/nGis5hCXXAUY kNshKLXmeRfVhTbnYYHMecRRcj0wjTAVTLpvEZuW1WuaMWNAY9A/yNOrfIeLSzc0TDz5 vFDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:message-id:references:date :in-reply-to:user-agent:mime-version; bh=T+DQcz1g45ZV1kxXBwHWNlTlOziKRR2ehwRBXDlz9Yo=; b=jNVK5ro0OPcoHaiUhEX4T8gs/6yv/8ErU7L5K98yUfVHN9CgnXFfoMrJ8rKcqNauU3 2EjMC8xYXUvr6PGHiJQyYBbzr+pB8XHiRpmVOmgoAywW1zFKpn+LPtKbXFEgqsjkMyyQ JwuUTJh4K0MYdwJiO20asBPrgGIx0p+hOCywBhga2X38ZsSgjGkf3gnLnyVoTHKgk0t9 Mf9IK9uyG0iq/QXahOQI3N1IXrMe6LQGdZqpCp0nKZ7LS60juSOwEDtlp8oUTqKTLcIt tDgbZpRiz3urjfdWJlhAlPISYYhUwlN51BwL/vWvZx05D+LQbpMvXtFuK4WZ3pAm/NEN hRBA== X-Gm-Message-State: APjAAAUOEpkuzn2Y9CI61N8LI4d6mgkNDgPMQFy12+8QDQH7Wu/xyWWw 4E7Km0c9kStFIrLvnenXOCzvPQ== X-Google-Smtp-Source: APXvYqwLRU3pHokyWi1a9Pk93NGtUX0NWRZIEsQA5AciJaeljHTRgUJnkaxsWH9IQ+b4+/s2mrrsJg== X-Received: by 2002:a50:991d:: with SMTP id k29mr92024283edb.29.1558570904197; Wed, 22 May 2019 17:21:44 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:8cad:ae29:555d:852d]) by smtp.gmail.com with ESMTPSA id g47sm7403861edc.33.2019.05.22.17.21.42 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 22 May 2019 17:21:43 -0700 (PDT) From: "Basil L. Contovounesios" Message-ID: <87woii6mzf.fsf@tcd.ie> References: <87pnohb79x.fsf@gmail.com> <87r28xxlzu.fsf@tcd.ie> <87pnoe4xg3.fsf@gmail.com> Date: Thu, 23 May 2019 01:21:36 +0100 In-Reply-To: <87pnoe4xg3.fsf@gmail.com> (Dario Gjorgjevski's message of "Sun, 19 May 2019 11:15:24 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) Dario Gjorgjevski writes: > I am attaching a patch file with a properly formatted commit message. Thanks, pushed to emacs-26[1]. [1: e61349c224]: Fix customization type of recentf-max-saved-items 2019-05-23 01:14:21 +0100 https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e61349c22412c0eaa7c03e08bfb0467a0a79708a -- Basil From debbugs-submit-bounces@debbugs.gnu.org Wed May 22 20:24:31 2019 Received: (at control) by debbugs.gnu.org; 23 May 2019 00:24:31 +0000 Received: from localhost ([127.0.0.1]:43472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTbX5-0003Rr-61 for submit@debbugs.gnu.org; Wed, 22 May 2019 20:24:31 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:34220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTbX2-0003RR-MG for control@debbugs.gnu.org; Wed, 22 May 2019 20:24:29 -0400 Received: by mail-ed1-f65.google.com with SMTP id p27so6456963eda.1 for ; Wed, 22 May 2019 17:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=0JS42vYEa4iIpi9qwpBLsm/GrQQHCudy6IQNY9pm1TI=; b=fv92cu2Hu8Js71fmxI/D55dQs73jbZ0qaY55eAkgW5nCQdSgn5UXNTLwSdj6/KSgma bcVREYKoiWq44sn1r+BYSscdGAJ0d3OgVERNrq0auL1tD/Q7otfMDHsFl5hv74IXGiAg DL6hVGZ2ToJEl34YVY1VN/KTNi3juNX9UQIL/RDGVcZ47lY1RcXHGhIezJETkwCPN4XJ ZwYph3fhz2Sb5aTPJ4XaQ2pgyZ8RXE/yJDV1aVFo3Y6DPPhZqSnfytoPzi9TGvR+0Mhl hcVquj/4WUNJNCs6vlLHfH8pIQzJhwzIOerfz8U4l5d1gZfS9LXiKst3FqkeFvYVpwOV lx5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=0JS42vYEa4iIpi9qwpBLsm/GrQQHCudy6IQNY9pm1TI=; b=pnXNxyo2iD0jKNpBTH2PO2JxyaLatrnDzZN5Gt6cUoIkPFwmFvoRF9y4u8X7adO6QP BgwDE7kXpFDzeptxLhYvUEv9mzI3R6wv7w5kLrA14jbiYImU0WfV6jo4BomtOPjAZ2iL zqNBT+r+aTptCRbDgWowNGTh+R/q6EUW7/C9fe0SMEFWOeDXjzB+/jodVLG04RmbphUw jr7WvBkObhNUO/mcjhSjieK9sUGTXiwsMq3OXfK2vyAWp8zYryN/qjN0nsh71AGocfBc RN8lzwMTdDuHm6ZIlEVhkwxxIR4UlRfEACDzYK/dfFpw1sDZPSN0WGBaP3vUjgQ20fSV ZNkQ== X-Gm-Message-State: APjAAAUFsi5JfhTyi0IaoT90mjrAM4oO9QGiYlOI3fkMqPly+IWy+NE+ jOXT29g+NYEybLuS3foulHVVvQ== X-Google-Smtp-Source: APXvYqwvLNRhfof9oPbTabNDO7jNr4P1e1JIS2L8KzfdTEFN5gAwcZrXYR1DcQhiuDGzredY54OThg== X-Received: by 2002:a50:ee11:: with SMTP id g17mr77687512eds.242.1558571063029; Wed, 22 May 2019 17:24:23 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:8cad:ae29:555d:852d]) by smtp.gmail.com with ESMTPSA id y30sm7573457edc.83.2019.05.22.17.24.22 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 22 May 2019 17:24:22 -0700 (PDT) From: "Basil L. Contovounesios" To: Eli Zaretskii Subject: Re: bug#35771: [PATCH] Customization type of recentf-max-saved-items References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> <87r28vwvh4.fsf@tcd.ie> <11926b48-89a8-47f9-bce9-f71ad6aa2a57@default> <87r28vp34y.fsf@tcd.ie> <83mujf83d9.fsf@gnu.org> Date: Thu, 23 May 2019 01:24:21 +0100 In-Reply-To: <83mujf83d9.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 May 2019 08:28:18 +0300") Message-ID: <87o93u6mru.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: control Cc: dario.gjorgjevski@gmail.com, 35771-done@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) tags 35771 fixed close 35771 26.3 quit Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Date: Sun, 19 May 2019 03:52:13 +0100 >> Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org >> >> I have already presented my arguments and recommended discussing this >> elsewhere, so I will now remain quiet to give others a chance to chime >> in. > > Chiming in: I think we should install the latest version of the patch, > and disregard all the rest. Done, so I'm closing this report. Thanks, -- Basil