From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#35133: 26.1; 1) `:tag' for `restricted-sexp' (not in a choice, set, etc.), 2) Remove `Value Menu' if a no-op Date: Wed, 9 Dec 2020 19:27:31 -0300 Message-ID: References: <4bd9e603-0d75-4de4-9bd3-6fa94a96e8a4@default> <87360f2fsp.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003b247005b60f9178" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27929"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 35133@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 09 23:28:14 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 1kn7wT-0007Ar-KL for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Dec 2020 23:28:13 +0100 Original-Received: from localhost ([::1]:32946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kn7wS-0007LS-Eo for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Dec 2020 17:28:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53486) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kn7wI-0007L9-Px for bug-gnu-emacs@gnu.org; Wed, 09 Dec 2020 17:28:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53142) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kn7wI-0000h4-JK for bug-gnu-emacs@gnu.org; Wed, 09 Dec 2020 17:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kn7wI-0004gv-Ev for bug-gnu-emacs@gnu.org; Wed, 09 Dec 2020 17:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Dec 2020 22:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35133 X-GNU-PR-Package: emacs Original-Received: via spool by 35133-submit@debbugs.gnu.org id=B35133.160755286818010 (code B ref 35133); Wed, 09 Dec 2020 22:28:02 +0000 Original-Received: (at 35133) by debbugs.gnu.org; 9 Dec 2020 22:27:48 +0000 Original-Received: from localhost ([127.0.0.1]:36455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn7w3-0004gQ-Vz for submit@debbugs.gnu.org; Wed, 09 Dec 2020 17:27:48 -0500 Original-Received: from mail-wr1-f54.google.com ([209.85.221.54]:42272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn7w2-0004gD-QG for 35133@debbugs.gnu.org; Wed, 09 Dec 2020 17:27:47 -0500 Original-Received: by mail-wr1-f54.google.com with SMTP id m5so3437329wrx.9 for <35133@debbugs.gnu.org>; Wed, 09 Dec 2020 14:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h6ythBasB+UbSInIUEKNyouJwuO7uyVmb0+Qjk0fy3k=; b=SwMsOce+/xN4miGpmN0/nGyusV7c9udHNoOZKmOnAmO5ZwqogQeR/qzsPfq/YlSIFk CFL+lu8usIJ9z6c0f7474lwUuWv0tXsUH1l1uVcN6ovpo8MsdZS0FCAa8WNmfI3Q1bZe 1smWP+aIWbjR0f5XHDwMVzp2ScUcX0IG6mYyePt+wiRCr9f147KNfjM+N2r6JQLHBqbP AjP7h3cu4XX9cokDvytzen46EI0t71QwCz4GHoK5VH3KNI4lATVIlp2gSJ9usB8KFGmp L3bwRuBBbvoiqfV35wLBc6ZqfA0cKhtN8+sWBAEkzP07ydTXEDho4o6nDOZYOwcUa8CW HxmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h6ythBasB+UbSInIUEKNyouJwuO7uyVmb0+Qjk0fy3k=; b=RegnOHbhBiQdZwIjf+tdf5QapjZEWXALSfRXjHauxmo6j4hi7D2eHh3tM+iDaTnTvy +gZW0mAhDPEWQiMChXy5TFxsQA1MzNyCE2DQ1fuEJkvcit/f2OEzIdTMYWIrV85ExEt2 aGLN6SZrgUAqaseXwVEmAqDEl1M31htKgwOaKRialDhEHza3kxB/WcTWTfIn1OzNtpS/ 59ZvWmrN/4i3qa4CYK2hLdWl/HIZbDqUUSn5swui8z2qjNjKzaJ+jCNpQyZZCnfdhAsF pNOInFqAlqRVjs7EDaAFu6AdazD8bPf8QM35pRBAyJrIwGijEbP1tLMRjIHnIknFj4QB dE0g== X-Gm-Message-State: AOAM530d1frWbZvL5z/UMotgYMJ2ZQqa1ABmXTidJbSHubDMLDBeq2jE nRD7pOhwqK25QpS33PBaxOQOSHU9ld6BAuYXxtk= X-Google-Smtp-Source: ABdhPJx+ztz3jsLm8BxjCCdCs1bKHhuKZKcGp/ZYpEiixdroMIWkDRB9kIWPrPC0cxv8eZk0+PnYpYG267XVk1TCSyA= X-Received: by 2002:a5d:61ca:: with SMTP id q10mr4998366wrv.124.1607552860889; Wed, 09 Dec 2020 14:27:40 -0800 (PST) In-Reply-To: <87360f2fsp.fsf@gnus.org> 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:195605 Archived-At: --0000000000003b247005b60f9178 Content-Type: text/plain; charset="UTF-8" > Drew Adams writes: > > > 1. Use `M-x customize-option' for each of these: > > > > (defcustom foo 42 > > "Foo..." > > :type '(restricted-sexp > > :tag "Positive integer" > > :match-alternatives ((lambda (x) (and (natnump x) (not (zerop x))))) > > :value ignore)) > > > > (defcustom bar 42 > > "Bar..." > > :type '(choice (restricted-sexp > > :tag "Positive integer" > > :match-alternatives ((lambda (x) (and (natnump x) (not (zerop x))))) > > :value ignore))) > > > > The `:tag' has no effect for `foo' - there is no label. I think that > > according to the doc it should have the same effect as for `bar'. > > I can confirm that this behaviour is still present in Emacs 28. Mauro, > if you have time, could you take a look at this? Not much time until the weekend, I'm afraid. Dropping the tag is intentional, in custom-variable-value-create: (push (widget-create-child-and-convert widget type :format value-format ^^^^^^^^^^^^^^^^^^^ :value value) children)) I suppose we could stop overriding the :format property, but for some widgets overriding it might make sense. For example, for the choice widget, deleting the :format value-format line would create the following: Foo: Choice: [Value Menu] The-Tag: Which isn't good, IMO. Other customization types I can think of that we should pay attention if we go with this change would be: repeat, set and radio. I think that those three, if we print their tag, won't give too much valuable information about the variable. I mean, we'd end up with something like this: Foo: Repeat: [INS] [DEL] Something [INS] And any user may ask what does "repeat" mean. Maybe changing the tags to something slightly more useful is all we need, and with this change the Custom buffer will show the customization type of the variable to the user, which looks like a win to me. What do you think about the "problematic" tags? --0000000000003b247005b60f9178 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Drew Adams <drew.adams@oracle.com> writes:
>
> = > 1. Use `M-x customize-option' for each of these:
> >
&= gt; > (defcustom foo 42
> > =C2=A0 "Foo..."
> &= gt; =C2=A0 :type '(restricted-sexp
> > =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 :tag "Positive integer"
> > =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 :match-alternatives ((lambda (x) (and (natnump x) =C2= =A0(not (zerop x)))))
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :valu= e ignore))
> >
> > (defcustom bar 42
> > =C2=A0 = "Bar..."
> > =C2=A0 :type '(choice (restricted-sexp<= br>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= :tag "Positive integer"
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :match-alternatives ((lambda (x) (and (= natnump x) =C2=A0(not (zerop x)))))
> > =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :value ignore)))
> >
>= ; > The `:tag' has no effect for `foo' - there is no label.=C2= =A0 I think that
> > according to the doc it should have the same = effect as for `bar'.
>
> I can confirm that this behaviour= is still present in Emacs 28.=C2=A0 Mauro,
> if you have time, could= you take a look at this?

Not much time until the weekend, I'm a= fraid.

Dropping the tag is intentional, in custom-variable-value-cre= ate:
(push (widget-create-child-and-convert
=C2=A0 =C2=A0widget ty= pe
=C2=A0 =C2=A0:format value-format
=C2=A0 =C2=A0 ^^^^^^^^^^^^^^^= ^^^^
=C2=A0 =C2=A0:value value)
=C2=A0 children))

I supp= ose we could stop overriding the :format property, but for some
widgets = overriding it might make sense.=C2=A0 For example, for the choice
widget= , deleting the :format value-format line would create the
following:
=
Foo: Choice: [Value Menu] The-Tag:

Which isn't good, IMO.=C2= =A0 Other customization types I can think of that we
should pay attentio= n if we go with this change would be: repeat, set and
radio.

I think that those three, if we print their tag, = won't give too much
valuable information about the variable.=C2=A0 = =C2=A0I mean, we'd end up with
something like this:

Foo= : Repeat:
[INS] [DEL] Something
[INS]

And any user may ask wha= t does "repeat" mean.=C2=A0 Maybe changing the tags
to somethi= ng slightly more useful is all we need, and with this change
the Custom = buffer will show the customization type of the variable to
the user, whi= ch looks like a win to me.=C2=A0 What do you think about the
"probl= ematic" tags?
--0000000000003b247005b60f9178--