GNU bug report logs - #24549
25.1; Customizing group `text'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24549 in the body.
You can then email your comments to 24549 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; Customizing group `text'
Date: Mon, 26 Sep 2016 13:46:26 -0700 (PDT)

1. M-x customize-group RET emacs RET

That shows a group named "Text".

2. M-x customize-group RET text RET

says "[No match]"

There is apparently no such group - at least none reachable using
completion.

Something seems wrong, somewhere, e.g., for `customize-group'.



In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'

Message #8 received at 24549 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 24549 <at> debbugs.gnu.org
Subject: RE: bug#24549: 25.1; Customizing group `text'
Date: Mon, 26 Sep 2016 13:54:52 -0700 (PDT)

See this thread of help-gnu-emacs, for more information:

http://lists.gnu.org/archive/html/help-gnu-emacs/2016-09/msg00162.html

Message #11 received at 24549 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24549 <at> debbugs.gnu.org
Subject: Re: bug#24549: 25.1; Customizing group `text'
Date: Tue, 27 Sep 2016 17:27:20 +0300

> Date: Mon, 26 Sep 2016 13:46:26 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> 1. M-x customize-group RET emacs RET
> 
> That shows a group named "Text".
> 
> 2. M-x customize-group RET text RET
> 
> says "[No match]"
> 
> There is apparently no such group - at least none reachable using
> completion.

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)

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").

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.

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;

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

Any better ideas?

Patches welcome, TIA.

Message #14 received at 24549 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24549 <at> debbugs.gnu.org
Subject: RE: bug#24549: 25.1; Customizing group `text'
Date: Tue, 27 Sep 2016 07:49:09 -0700 (PDT)

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

Message #17 received at 24549 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24549 <at> debbugs.gnu.org
Subject: Re: bug#24549: 25.1; Customizing group `text'
Date: Tue, 27 Sep 2016 18:05:57 +0300

> Date: Tue, 27 Sep 2016 07:49:09 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 24549 <at> debbugs.gnu.org
> 
> > 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.

If this works, it is probably better, yes.

Message #20 received at 24549 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24549 <at> debbugs.gnu.org
Subject: RE: bug#24549: 25.1; Customizing group `text'
Date: Tue, 27 Sep 2016 09:58:29 -0700 (PDT)

> > > 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.
> 
> If this works, it is probably better, yes.

IOW, something like the code below.

Question 1: Why is group `outlines' declared in both
cus-edit.el and outline.el?  And in outline.el it has a
prefix declared, but not in cus-edit.el.  Group `outlines'
is not _used_ in cus-edit.el, AFAICT.  What would happen
if we removed group `outlines' from cus-edit.el?
(This question has nothing to do with this bug report.
Just happened to notice the duplication.)

Question 2: Should group `text' inherit directly from group
`emacs'?  Should it also inherit from group `wp'?

I think the answer to both of these is yes.  WDYT?

Question 3: Should group `wp' still be inherited from, by a
group that now inherits from `text'?  E.g., should group
`tildify' inherit from both `wp' as well as from `text'?

I don't think so.  If group `text' itself inherits from `wp'
then I don't think there is any reason that we need to have
other groups still inherit directly from `wp' (as well as
from `text').  WDYT?

I think that the more we can hide `wp' from users, the better.
If it needs to continue to be there for a while, because of
possibly existing 3rd-party code, then we should keep it
around.  But we can try to minimize its obvious exposure.

;;; cus-edit.el

;; No :tag anymore
;;
(defgroup wp nil
  "Support for editing text files.
Use group `text' for this instead.  Group `wp' is deprecated."
  :group 'emacs)

(defgroup text nil
  "Support for editing text files."
  :group 'emacs
  ;; Inherit from deprecated `wp' for compatibility, for now.
  :group 'wp)

(defgroup outlines nil
  "Support for hierarchical outlining."
  :group 'text)

(defgroup tex nil
  "Code related to the TeX formatter."
  :link '(custom-group-link
           :tag "Font Lock Faces group" font-lock-faces)
  :group 'text)

;;; delim-col.el

(defgroup columns nil
  "Prettify columns."
  :link '(emacs-library-link
           :tag "Source Lisp File" "delim-col.el")
  :prefix "delimit-columns-"
  :group 'text)

;;; lpr.el

(defgroup lpr nil
  "Print Emacs buffer on line printer."
  :group 'text)

;;; outline.el

(defgroup outlines nil
  "Support for hierarchical outlining."
  :prefix "outline-"
  :group 'text)

;;; printing.el

(defgroup printing nil
  "Printing Utilities group."
  :tag "Printing Utilities"
  :link '(emacs-library-link :tag "Source Lisp File" "printing.el")
  :prefix "pr-"
  :version "22.1"
  :group 'text
  :group 'postscript)

;;; ps-print.el

(defgroup ps-print nil
  "PostScript generator for Emacs."
  :link '(emacs-library-link :tag "Source Lisp File" "ps-print.el")
  :prefix "ps-"
  :version "20"
  :group 'text
  :group 'postscript)

;;; view.el

(defgroup view nil
  "Peruse file or buffer without editing."
  :link '(function-link view-mode)
  :link '(custom-manual "(emacs)Misc File Ops")
  :group 'text)

;;; nxml/rng-valid.el

(defgroup relax-ng nil
  "Validation of XML using RELAX NG."
  :group 'text
  :group 'nxml
  :group 'languages)

;;; obsolete/scribe.el

(defgroup scribe nil
  "Scribe mode."
  :prefix "scribe-"
  :group 'text)

;;; progmodes/ebnf2ps.el

(defgroup ebnf2ps nil
  "Translate an EBNF to a syntactic chart on PostScript."
  :prefix "ebnf-"
  :version "20"
  :group 'text
  :group 'postscript)

;;; textmodes/bib-mode.el

(defgroup bib nil
  "Major mode for editing bib files."
  :prefix "bib-"
  :group 'external
  :group 'text)

;;; textmodes/enriched.el

(defgroup enriched nil
  "Read and save files in text/enriched format."
  :group 'text)

;;; textmodes/nroff-mode.el

(defgroup nroff nil
  "Nroff mode."
  :link '(custom-group-link :tag "Font Lock Faces group" font-lock-faces)
  :group 'text
  :prefix "nroff-")

;;; textmodes/picture.el

(defgroup picture nil
  "Editing text-based pictures (\"ASCII art\")."
  :prefix "picture-"
  :group 'text)

;;; textmodes/refbib.el

(defgroup refbib nil
  "Convert refer-style references to ones usable by Latex bib."
  :prefix "r2b-"
  :group 'text)

;;; textmodes/refer.el

(defgroup refer nil
  "Look up references in bibliography files."
  :prefix "refer-"
  :group 'text)

;;; textmodes/rst.el

(defgroup rst nil "Support for reStructuredText documents."
  :group 'text
  :version "23.1"
  :link '(url-link "http://docutils.sourceforge.net/rst.html"))

;;; textmodes/table.el

(defgroup table nil
  "Text based table manipulation utilities."
  :tag "Table"
  :prefix "table-"
  :group 'text
  :version "22.1")

;;; textmodes/text-mode.el

(defcustom text-mode-hook '(text-mode-hook-identify)
  "Normal hook run when entering Text mode and many related modes."
  :type 'hook
  :options '(turn-on-auto-fill turn-on-flyspell)
  :group 'text)

;;; textmodes/tildify.el

(defgroup tildify nil
  "Add hard spaces or other text fragments to text buffers."
  :version "21.1"
  :group 'text)

Message #25 received at 24549-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24549-done <at> debbugs.gnu.org
Subject: Re: bug#24549: 25.1; Customizing group `text'
Date: Sat, 08 Oct 2016 16:40:49 +0300

> Date: Tue, 27 Sep 2016 09:58:29 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 24549 <at> debbugs.gnu.org
> 
> > > IOW, we can (1) make a group `text' that behaves essentially
> > > like `wp' and (2) let users know that `wp' is considered
> > > deprecated.
> > 
> > If this works, it is probably better, yes.
> 
> IOW, something like the code below.

Thanks, done on the master branch.

> Question 1: Why is group `outlines' declared in both
> cus-edit.el and outline.el?  And in outline.el it has a
> prefix declared, but not in cus-edit.el.  Group `outlines'
> is not _used_ in cus-edit.el, AFAICT.  What would happen
> if we removed group `outlines' from cus-edit.el?
> (This question has nothing to do with this bug report.
> Just happened to notice the duplication.)

This duplication is an oversight from when outline.el was converted to
use Custom.  I fixed this now.

> Question 2: Should group `text' inherit directly from group
> `emacs'?  Should it also inherit from group `wp'?

I left it inherit from both.  It cannot do any harm, I think.

> I think the answer to both of these is yes.  WDYT?
> 
> Question 3: Should group `wp' still be inherited from, by a
> group that now inherits from `text'?  E.g., should group
> `tildify' inherit from both `wp' as well as from `text'?
> 
> I don't think so.  If group `text' itself inherits from `wp'
> then I don't think there is any reason that we need to have
> other groups still inherit directly from `wp' (as well as
> from `text').  WDYT?

I agree.

I think this bug is now done.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.