unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
	Noam Postavsky <npostavs@gmail.com>,
	26301@debbugs.gnu.org
Subject: bug#26301: 24.5; `define-derived-mode': different signatures for doc string & manual
Date: Sat, 27 Jul 2019 17:01:30 -0700 (PDT)	[thread overview]
Message-ID: <04854612-43af-4085-8f2f-ff481ce329cb@default> (raw)
In-Reply-To: <87zhkzdssw.fsf@web.de>

> > However, in that case, KEYWORDS is the _wrong_ name.
> 
> In a similar case, `define-globalized-minor-mode' uses the name KEYS
> (it's the name of the &rest arg though).

If each of the args in the &rest list is a KEY
then that's fine.

> > The name should be KEYWORD or KEYWORD-ENTRY or KEYWORD-PAIR or some
> > such.
> 
> I all find that not better.  KEYWORD fails to say that values are
> included.  KEYWORD-ENTRY and KEYWORD-PAIR are confising, they make it
> look like you would have to specify conses or two element lists.
> 
> I would prefer something like [KEYWORD VALUE ...], though I guess that
> would then confuse eldoc.

That's incorrect, I think, because it indicates
that VALUE is what is possibly repeated.  If the
convention doesn't actually specify that (I'm not
sure) that's at least what someone might suppose.

Dunno whether our convention allows [KEYWORD VALUE]...
(i.e., with the ... after the optional indication).

Otherwise, I'd suggest a name such as KEYWORD+VALUE:

 [KEYWORD+VALUE...]

(If this were not something added automatically by
handling (fn ...) then a single name (e.g. FOOBAR)
could be broken down in the doc string, saying that
FOOBAR is a keyword followed by its value.)





  reply	other threads:[~2019-07-28  0:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 15:03 bug#26301: 24.5; `define-derived-mode': different signatures for doc string & manual Drew Adams
2019-07-26 11:04 ` Lars Ingebrigtsen
2019-07-26 14:50   ` Drew Adams
2019-07-26 14:54   ` Noam Postavsky
2019-07-26 15:08     ` Lars Ingebrigtsen
2019-07-26 15:51       ` Drew Adams
2019-07-26 15:38     ` Drew Adams
2019-07-27 10:03     ` Lars Ingebrigtsen
2019-07-27 16:54       ` Drew Adams
2019-07-27 22:19         ` Michael Heerdegen
2019-07-28  0:01           ` Drew Adams [this message]
2019-07-28  0:14             ` Michael Heerdegen

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=04854612-43af-4085-8f2f-ff481ce329cb@default \
    --to=drew.adams@oracle.com \
    --cc=26301@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=michael_heerdegen@web.de \
    --cc=npostavs@gmail.com \
    /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).