unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Mauro Aranda <maurooaranda@gmail.com>,
	Lars Ingebrigtsen <larsi@gnus.org>
Cc: 35133@debbugs.gnu.org
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 15:30:43 -0800 (PST)	[thread overview]
Message-ID: <3bae30db-9eb9-4185-b549-1cdfd60efc59@default> (raw)
In-Reply-To: <CABczVwfDOHXULnC4iqDHWc+Ex59LkTZ8FuCXmCA02BTbUzMfpg@mail.gmail.com>

> 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?

Thanks for looking into this Mauro.

I'd suggest handling this in two stages:

1. Take care of what is clearly, or pretty clearly,
   straightforward.
2. Think about how to handle other cases.
____

But in general, for defcustom I think I'm in favor of
allowing the realization of a :tag, regardless of
whether using it might be problematic sometimes.

After all, using :tag is optional.  If the result
isn't helpful, someone won't use it.

But I guess you're asking about default tags?  What
happens if there's no default :tag for some widget
(such as `repeat') but when you use the widget you
provide a :tag?  Would that be possible?  IOW, maybe
a :tag for `repeat' isn't useful by default, but
maybe adding a :tag when you use some `repeat' could
be useful.

(For the problematic cases, maybe the tag text should be
shown without the trailing colon?  Maybe it depends on
where the tag is placed and how long the string is.)

Anyway, for now at least, #1 would be great.  Thx.





  reply	other threads:[~2020-12-09 23:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  3:05 bug#35133: 26.1; 1) `:tag' for `restricted-sexp' (not in a choice, set, etc.), 2) Remove `Value Menu' if a no-op Drew Adams
2020-12-09 14:51 ` Lars Ingebrigtsen
2020-12-09 22:27   ` Mauro Aranda
2020-12-09 23:30     ` Drew Adams [this message]
2020-12-11 14:05       ` Mauro Aranda
2020-12-11 17:26         ` Drew Adams
2020-12-11 14:31     ` Lars Ingebrigtsen
2020-12-11 17:06       ` Mauro Aranda
2020-12-12 10:59         ` Lars Ingebrigtsen
2020-12-13 13:50           ` Mauro Aranda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3bae30db-9eb9-4185-b549-1cdfd60efc59@default \
    --to=drew.adams@oracle.com \
    --cc=35133@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=maurooaranda@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).