all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 24549@debbugs.gnu.org
Subject: bug#24549: 25.1; Customizing group `text'
Date: Tue, 27 Sep 2016 07:49:09 -0700 (PDT)	[thread overview]
Message-ID: <9eab3611-2ed6-422b-93bc-4270ef1b6082@default> (raw)
In-Reply-To: <837f9xct9z.fsf@gnu.org>

> The group's _symbol_ is 'wp', "Text" is only its label (a.k.a. :tag):
> 
>   (defgroup wp nil
>     "Support for editing text files."
>     :tag "Text"
>     :group 'emacs)

Ah yes.  I should have checked that.

IMHO, this is a gotcha.  Emacs itself, especially, should not do
this by default.

If there is no good way to create an alias for group `text' here,
then perhaps we should at least create another group `text',
which inherits from this.  The problem (gotcha) should be taken
care of in some way.

> The ELisp manual says:
> 
>   ‘:tag LABEL’
>        Use LABEL, a string, instead of the item’s name, to label the item
>        in customization menus and buffers.  *Don’t use a tag which is
>                                             ^^^^^^^^^^^^^^^^^^^^^^^^^
>        substantially different from the item’s real name; that would cause
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        confusion.*
>        ^^^^^^^^^^^
> 
> (a.k.a. "do as I say, not as I do").

Exactly.
 
> Unfortunately, this is a very old problem, and the 'wp' thingy is by
> now probably spread too much, including outside of Emacs, for us to
> even consider renaming the symbol itself.

See above.  I don't think there is a way to alias it (and then
deprecate `wp'.  But at least we can make a group `text' that
DTRT.

> So I think one band-aid solution could be:
> 
>   . mention the group's symbol in its doc string, so that it could be
>     seen in the Custom buffer;

Yes, but a user using `M-x customize' and then trying to drill
down, will not necessarily take time to read that doc.

>   . extend customize-read-group so it also accepts group tags, not
>     just their symbols.

That's not a bad idea.  But in that case, we would essentially
get near-duplicate names for those groups that actually followed
the instructions and used a similar (but not identical) name for
the tag label.  IOW, a tag that is more explicit (e.g. longer)
or is an abbreviation of the group name (i.e., shorter) would
be present for completion, along with the group name itself.

That's not a big problem, IMO.  This could indeed be a solution.

> Any better ideas?

See above.  We can create another group, `text', which inherits
from `wp'.  Emacs itself could move toward using group `text'
everywhere.  The doc for group `text' could say that `wp' is
deprecated (even though there is no code-enforcement via
warning etc.).

IOW, we can (1) make a group `text' that behaves essentially
like `wp' and (2) let users know that `wp' is considered
deprecated.

Yes, this would mean that both `text' and `wp' would appear
for completion.  But unlike your proposed solution, this
would be a one-off bug fix, and not a generalization that
applies to every use of a tag.

A priori - i.e., until I hear more pros & cons, I think this
would be a better solution that what you suggested.  What do
you think?

One way or another, we need, I think, to make `text' work.





  reply	other threads:[~2016-09-27 14:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-26 20:46 bug#24549: 25.1; Customizing group `text' Drew Adams
2016-09-26 20:54 ` Drew Adams
2016-09-27 14:27 ` Eli Zaretskii
2016-09-27 14:49   ` Drew Adams [this message]
2016-09-27 15:05     ` Eli Zaretskii
     [not found] <<8aaf30c2-ceb2-4803-9e2e-cd10ad8a3802@default>
     [not found] ` <<837f9xct9z.fsf@gnu.org>
     [not found]   ` <<9eab3611-2ed6-422b-93bc-4270ef1b6082@default>
     [not found]     ` <<83twd1bcx6.fsf@gnu.org>
2016-09-27 16:58       ` Drew Adams
2016-10-08 13:40         ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=9eab3611-2ed6-422b-93bc-4270ef1b6082@default \
    --to=drew.adams@oracle.com \
    --cc=24549@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.