unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Howard Melman <hmelman@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 55527@debbugs.gnu.org
Subject: bug#55527: 28.1; Clearer abbrev docstrings
Date: Sat, 21 May 2022 13:49:48 -0400	[thread overview]
Message-ID: <96FE2CC0-8A4C-4099-A3D5-5FDD351C739F@gmail.com> (raw)
In-Reply-To: <83fsl37z9k.fsf@gnu.org>

On May 21, 2022, at 10:09 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Howard Melman <hmelman@gmail.com>
>> Date: Sat, 21 May 2022 09:41:41 -0400
>> Cc: 55527@debbugs.gnu.org
>> 
>> For the non-inverse commands I'd love to see the "word(s)"
>> construction retained as it jumps out when skimming the docstring and
>> is a bit more accurate.  So how about:
>> 
>>  (defun add-mode-abbrev (arg)
>>  "Define a mode-specific abbrev which expands into the word(s) before point.
>> 
>>  (defun add-global-abbrev (arg)
>>  "Define a global (all modes) abbrev which expands into word(s) before point.
> 
> This is IMO a tradeoff for the worse: it makes the first line less
> clear on behalf of including information that is non-essential.
> 

> In many commands, we describe in the first line what the command does
> by default, and defer the description of what ARG does to the body of
> the doc string.  A random example:
> 
>  (transpose-chars ARG)
> 
>  Interchange characters around point, moving forward one character.
>  With prefix arg ARG, effect is to take character before point
>  and drag it forward past ARG other characters (backward if ARG negative).

The existing docstrings for these commands had "word(s)" in them
and I don't think that's what made them unclear.  I also think it's a
common case to define an abbrev for a multi-word expansion.

I count about 80 first line docstrings in Emacs lisp code that use a "(s)" construct.
  
But looking at forward-word's docstring for inspiration, how about this:

    "Define a mode-specific abbrev which expands into ARG words before point.
    "Define a global (all modes) abbrev which expands into ARG words before point.

I think using ARG as above includes the common case of an expansion
being more than one word and defers the less common uses of
a zero or negative arg to the docstring body.  I think too that an ARG 
of zero is unclear so the user would read the body.  A negative ARG would
often reverse direction so perhaps it's unintuitive, but I think that's the case
if ARG is mentioned in the first line or not.

Also, I see now that the inverse- versions of these command treat a 
negative argument as reversing the direction to find the word to use
as the abbreviation but the (old and new) docstrings fails to mention 
this.  I'm not sure if that's intentional or not (IMO it's an odd use case).

Howard






  reply	other threads:[~2022-05-21 17:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19 18:32 bug#55527: 28.1; Clearer abbrev docstrings Howard Melman
2022-05-19 18:52 ` Eli Zaretskii
2022-05-19 19:30   ` Howard Melman
2022-05-19 19:46     ` Eli Zaretskii
2022-05-19 20:38       ` Howard Melman
2022-05-20  5:48         ` Eli Zaretskii
2022-05-20 13:35           ` Howard Melman
2022-05-20 15:59             ` Eli Zaretskii
2022-05-20 17:03               ` Howard Melman
2022-05-21  7:23                 ` Eli Zaretskii
2022-05-21 13:41                   ` Howard Melman
2022-05-21 14:09                     ` Eli Zaretskii
2022-05-21 17:49                       ` Howard Melman [this message]
2022-05-21 18:06                         ` Eli Zaretskii
2022-05-21 18:26                           ` Howard Melman
2022-05-21 18:46                             ` Eli Zaretskii
2022-05-20  7:41 ` Juri Linkov
2022-05-20 13:12   ` Howard Melman

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=96FE2CC0-8A4C-4099-A3D5-5FDD351C739F@gmail.com \
    --to=hmelman@gmail.com \
    --cc=55527@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 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).