unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Thierry Volpiatto <thievol@posteo.net>, monnier@iro.umontreal.ca
Cc: 70163@debbugs.gnu.org, schwab@linux-m68k.org
Subject: bug#70163: 29.3; hexl-mode incorrect docstring
Date: Thu, 04 Apr 2024 15:18:27 +0300	[thread overview]
Message-ID: <86r0fl723w.fsf@gnu.org> (raw)
In-Reply-To: <87r0fly8zn.fsf@posteo.net> (message from Thierry Volpiatto on Thu, 04 Apr 2024 05:47:40 +0000)

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: schwab@linux-m68k.org,  monnier@iro.umontreal.ca,  70163@debbugs.gnu.org
> Date: Thu, 04 Apr 2024 05:47:40 +0000
> 
> >> >>> Hexl-mode docstring specify "\<hexl-mode-map>" in its first line, this
> >> >>> to specify some keybinding related to this map at end, as a result the
> >> >>> documentation command returns a three line string, the first line beeing
> >> >>> a blank line until hexl.el is loaded.  I think docstrings generally
> >> >>> should not have this specification in their first line.
> >> >>> 
> >> >>>     (defun hexl-mode (&optional arg)
> >> >>>       "\\<hexl-mode-map>A mode for editing binary files in hex dump format.
> >> >>>       [...] 
> >> >>>       Most cursor movement bindings are the same: use \\[hexl-backward-char],
> >> >>>       [...]
> >> >>
> >> >> What do you suggest to do instead?
> >> >
> >> > Customary is to put it directly before the (first) keymap reference.
> >> 
> >> Exactly.
> >
> > So we don't want an empty line at the beginning of a doc string, but
> > are okay with having it farther into the doc string?
> 
> Yes, this would avoid loading the whole file just for having the first line of
> the documentation.
> 
> Actually, (documentation 'hexl-mode) returns:
> 
> "\nUses keymap `hexl-mode-map', which is not currently defined.\nA mode for editing binary files in hex dump format..."
> 
> But once it is loaded:
> 
> "A mode for editing binary files in hex dump format..."
> 
> I think it is a good practice to specify keymap just when needed as
> specified in the manual:
> 
>    • In documentation strings for a major mode, you will want to refer
>      to the key bindings of that mode’s local map, rather than global
>      ones.  Therefore, use the construct ‘\\<...>’ once in the
>      documentation string to specify which key map to use.  Do this
>      before the first use of ‘\\[...]’.  The text inside the ‘\\<...>’
>      should be the name of the variable containing the local keymap for
>      the major mode.

Does the patch below gives any better results?  It doesn't look better
to me: the "Uses keymap..." blurb gets in the way and makes the
documentation text wrong.  And it will happen regardless of where you
stuff the \\<..> thing, just in different places of the test.  It
looks like this feature was not meant to be used with libraries that
aren't loaded, or maybe the intent is to use the RAW argument in those
cases.

Stefan, why do we inject this ugly blurb into the text we return when
the library is not loaded? why not simply return the same as RAW does
in those cases?

diff --git a/lisp/hexl.el b/lisp/hexl.el
index 1288cf4..938b218 100644
--- a/lisp/hexl.el
+++ b/lisp/hexl.el
@@ -256,10 +256,10 @@ hexl-line-displen
 
 ;;;###autoload
 (defun hexl-mode (&optional arg)
-  "\\<hexl-mode-map>A mode for editing binary files in hex dump format.
+  "A mode for editing binary files in hex dump format.
 This is not an ordinary major mode; it alters some aspects
 of the current mode's behavior, but not all; also, you can exit
-Hexl mode and return to the previous mode using `hexl-mode-exit'.
+Hexl mode and return to the previous mode using \\<hexl-mode-map>\\[hexl-mode-exit].
 
 This function automatically converts a buffer into the hexl format
 using the function `hexlify-buffer'.





  reply	other threads:[~2024-04-04 12:18 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 15:02 bug#70163: 29.3; hexl-mode incorrect docstring Thierry Volpiatto
2024-04-03 15:50 ` Eli Zaretskii
2024-04-03 16:37   ` Andreas Schwab
2024-04-03 17:04     ` Thierry Volpiatto
2024-04-03 18:14       ` Eli Zaretskii
2024-04-04  5:47         ` Thierry Volpiatto
2024-04-04 12:18           ` Eli Zaretskii [this message]
2024-04-04 12:45             ` Andreas Schwab
2024-04-04 13:07               ` Eli Zaretskii
2024-04-04 13:20                 ` Andreas Schwab
2024-04-04 12:54             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-04 13:16               ` Andreas Schwab
2024-04-04 13:23               ` Eli Zaretskii
2024-04-04 13:37                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-04 18:41                   ` Thierry Volpiatto
2024-04-05  5:46                     ` Eli Zaretskii
2024-04-05  6:29                       ` Thierry Volpiatto
2024-04-06 10:46                         ` Eli Zaretskii
2024-04-06 11:27                           ` Thierry Volpiatto
2024-04-06 12:52                           ` Ihor Radchenko
2024-04-06 14:05                             ` Andreas Schwab
2024-04-06 14:15                               ` Eli Zaretskii
2024-04-06 15:05                                 ` Andreas Schwab
2024-04-06 15:27                                   ` Eli Zaretskii
2024-04-06 15:49                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 16:16                           ` Eli Zaretskii
2024-04-06 20:01                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 20:21                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07  5:29                               ` Eli Zaretskii
2024-04-07 14:48                                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 14:57                                   ` Eli Zaretskii
2024-04-07 16:07                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 16:11                                       ` Eli Zaretskii
2024-04-03 17:04   ` Thierry Volpiatto

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=86r0fl723w.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=70163@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=schwab@linux-m68k.org \
    --cc=thievol@posteo.net \
    /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).