From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#39887: 26.3; Customize buffer does not show type expected Date: Mon, 26 Oct 2020 15:51:13 -0700 (PDT) Message-ID: References: <2b1287b530e902d23c7c28cdd05dbf482ec97450.camel@gmail.com> <877drcu09e.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="539"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39887@debbugs.gnu.org To: Lars Ingebrigtsen , dalanicolai@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 26 23:52:34 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXBLt-000AcS-Gb for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Oct 2020 23:52:33 +0100 Original-Received: from localhost ([::1]:42470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXBLs-0004GI-IA for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Oct 2020 18:52:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXBLQ-0004Fp-2e for bug-gnu-emacs@gnu.org; Mon, 26 Oct 2020 18:52:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58623) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXBLO-0003wC-5X for bug-gnu-emacs@gnu.org; Mon, 26 Oct 2020 18:52:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXBLO-0000hs-3S for bug-gnu-emacs@gnu.org; Mon, 26 Oct 2020 18:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Oct 2020 22:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 39887-submit@debbugs.gnu.org id=B39887.16037526852657 (code B ref 39887); Mon, 26 Oct 2020 22:52:02 +0000 Original-Received: (at 39887) by debbugs.gnu.org; 26 Oct 2020 22:51:25 +0000 Original-Received: from localhost ([127.0.0.1]:41936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXBKm-0000gn-S6 for submit@debbugs.gnu.org; Mon, 26 Oct 2020 18:51:25 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:59660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXBKl-0000gZ-3A for 39887@debbugs.gnu.org; Mon, 26 Oct 2020 18:51:23 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09QMk0T8116862; Mon, 26 Oct 2020 22:51:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=s+BQS87TgjlKge+eOVlvdb/umaXDuqBNHqftIR6WYII=; b=aBc44Q/Fh3ZpNI9WNF1zrU9j15+ao7a6bWHR48WBLZj0Rw4kPkFnHLBdMwHXC16UwQxE o5fjNZg/K36NroDeBGsQXFm6sJd3lL55pDwKu5iFLiPqxYquocjEjk/IMZwMyAdDjHSA k32pcnVjo6NoONaDyf6yhFGUxUFH8D7bTM/EdBOL9nqYsDFssbKuSsUK2gW4KAHK89Pf EgTpyVKpM+wUQeAtdt7RsD3akL9wwusJ9STsVTRhV3/sOQXww4ag+WNu73wBiIvkorrU CEHsKtHd8V/FE75P3XqR0clSfikjx7t2aBUyflEFANa7lOksXhzmBY4AniDsY2h77Ecm bA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2130.oracle.com with ESMTP id 34c9saq9j3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 26 Oct 2020 22:51:17 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09QMjHxw025790; Mon, 26 Oct 2020 22:51:16 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 34cx6v98p0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Oct 2020 22:51:16 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 09QMpFnB016416; Mon, 26 Oct 2020 22:51:15 GMT In-Reply-To: <877drcu09e.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9786 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010260148 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9786 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 impostorscore=0 mlxlogscore=999 malwarescore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 spamscore=0 phishscore=0 clxscore=1011 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010260148 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191686 Archived-At: > > The title already explains the bug. It would be great if the customize > > buffer shows which type of variable is expected. Although the :type > > keyword is included in the defcustom declaration, it is not shown in > > the customization buffer which type is expected. If the wrong type is > > filled in then the only error message given is "(mismatch)". Quite > > some package writers do not - additionally - document their variables. >=20 > The Customize buffer is supposed to be a user-friendly, easy interface > to use, and displaying types like >=20 > (alist :key-type symbol :value-type (choice symbol integer)) >=20 > which only would make sense to a programmer would be the wrong way to go > here. The Customize interface already tries to guide the users as much > as the type spec allows. >=20 > I'm sure there are individual doc strings that could stand improving, > though, in which case bug reports for those would be welcome. But I'm > closing this bug report. FWIW -=20 My comment went in the opposite direction: +1. Great idea. The type declaration in the help might also even be a link to the doc for :type. I disagree that just because the Customize UI needs be able to be amenable to non-lispers it should ONLY have ever help for non-lispers. That doesn't follow. Many (most?) Emacs users are also to some extent lispers. And there's no reason that defcustoms are necessarily limited to simple structures. Users who who can understand complex Lisp structures can also benefit from Customize, including the UI - especially its type-checking. Customize is not only for non-lispers. When a defcustom type is simple, a non-lisper can likely grok its spec in the help. Why do you suppose that we put a command's signature in the `C-h f' help? Why should a novice who uses `C-h k C-f' be presented with `(forward-char &optional N)'? Why? Because some Emacs users can benefit from that info. And when a custome type is complex, a novice can just ignore the type signature, and a knowledgeable lisper can appreciate seeing it. For the same reason that menu `State' has item `Show Saved Lisp Expression', we should be able to show users the :type expression. How that's made available is a different (and open) question. But whether users should be able to see it within Customize should be answered with YES, not NO (IMHO). Option types can be a bear. The more help we offer users, the better. This enhancement request was a wonderful suggestion. Yes, a user can use `C-h v' and move to the source code to see the defcustom. But we can make it easier to see the :type info - in context with the existing value. (Just one opinion.)