From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Alan Mackenzie <acm@muc.de>, Andrea Corallo <acorallo@gnu.org>,
66750@debbugs.gnu.org
Subject: bug#66750: help-split-fundoc (was: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value)
Date: Thu, 02 Nov 2023 17:20:00 -0400 [thread overview]
Message-ID: <jwva5rvg94b.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CADwFkmmDmkO1Rq6KOFc8UP570w8MEBd+Q81QaHwR=jpPCiL1+g@mail.gmail.com> (Stefan Kangas's message of "Thu, 2 Nov 2023 13:53:34 -0700")
>> The way we do it for the arglist is hideous and a pain in the rear (I
>> blame the maintainers who accepted my patch back then), so it would be
>> an opportunity to "do it right" this time.
> What is bad about it, and how do you propose it could be improved?
It shouldn't be hidden under a `help-` prefix.
`help-split-fundoc` should not return "either a cons or nil".
Things like that.
It's clunky.
Part of the problem is that arglists often need to be
manipulated/provided by macros whose output is a language that only
knows about docstrings and not arglists, so it necessarily exposes
this hack of storing the arglist inside the docstring.
It's somewhat difficult to make it much better without significant
changes elsewhere (like an extension to the syntax of `lambda` where we
can provide side info like arglists).
Maybe it would help to rename `function-documentation` to `function-info`
whose output is type shouldn't matter because we only access it via
other functions like `function-info-documentation`,
`function-info-arglist`, ...
And then provide a (function-info-join INFO TYPE VALUE) where type can
be `documentation` or `arglist` or ...
The function arglist thingy was originally designed so that function
arglists could be easily provided from the DEFUNs in the C code, so it
was important to use a syntax that was somewhat human-readable, but it's
not indispensable to use the same format in the DEFUNs as elsewhere, so
we could choose a less human-friendly encoding that's more robust and
easier to extend.
Stefan
prev parent reply other threads:[~2023-11-02 21:20 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 17:09 bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Alan Mackenzie
2023-10-25 20:53 ` Andrea Corallo
2023-10-27 11:35 ` Alan Mackenzie
2023-10-28 9:27 ` Alan Mackenzie
2023-10-28 15:04 ` Stefan Kangas
2023-10-28 15:59 ` Alan Mackenzie
2023-10-28 16:26 ` Eli Zaretskii
2023-10-28 16:57 ` Alan Mackenzie
2023-10-28 17:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28 18:17 ` Alan Mackenzie
2023-10-28 18:38 ` Eli Zaretskii
2023-10-28 18:59 ` Alan Mackenzie
2023-10-28 19:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28 19:59 ` Alan Mackenzie
2023-10-29 4:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-29 11:25 ` Alan Mackenzie
2023-10-29 16:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-29 18:50 ` Alan Mackenzie
2023-10-29 21:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-30 9:44 ` Alan Mackenzie
2023-11-01 12:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-01 15:03 ` Alan Mackenzie
2023-11-01 18:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-01 20:30 ` Alan Mackenzie
2023-11-01 22:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-02 6:13 ` Eli Zaretskii
2023-11-02 9:37 ` Alan Mackenzie
2023-11-02 10:09 ` Eli Zaretskii
2023-11-02 11:52 ` Alan Mackenzie
2023-11-02 13:50 ` Eli Zaretskii
2023-11-02 15:55 ` Alan Mackenzie
2023-11-02 16:50 ` Eli Zaretskii
2023-11-02 17:12 ` Andrea Corallo
2023-11-02 21:44 ` Stefan Kangas
2023-11-02 22:24 ` Alan Mackenzie
2023-11-03 3:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-03 19:46 ` Alan Mackenzie
2023-11-03 22:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-04 15:31 ` Alan Mackenzie
2023-11-26 12:32 ` Alan Mackenzie
2023-11-27 17:23 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 12:03 ` Alan Mackenzie
2023-11-02 20:53 ` Stefan Kangas
2023-11-02 21:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
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=jwva5rvg94b.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=66750@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=acorallo@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stefankangas@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).