bug#24549: 25.1; Customizing group `text'

bug#24549: 25.1; Customizing group `text'

[Drew Adams]

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'

bug#24549: 25.1; Customizing group `text'

[Drew Adams]

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

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

bug#24549: 25.1; Customizing group `text'

[Eli Zaretskii]

> Date: Mon, 26 Sep 2016 13:46:26 -0700 (PDT)
> From: Drew Adams <drew.adams@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.

bug#24549: 25.1; Customizing group `text'

[Drew Adams]

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

bug#24549: 25.1; Customizing group `text'

[Eli Zaretskii]

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

bug#24549: 25.1; Customizing group `text'

[Drew Adams]

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

bug#24549: 25.1; Customizing group `text'

[Eli Zaretskii]

> Date: Tue, 27 Sep 2016 09:58:29 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 24549@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.