From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: acm@muc.de, Eli Zaretskii <eliz@gnu.org>, 67455@debbugs.gnu.org
Subject: bug#67455: Record source position, etc., in doc strings, and use this in *Help* and backtraces.
Date: Mon, 4 Dec 2023 22:30:31 +0000 [thread overview]
Message-ID: <ZW5TB-6nnwXWkLfb@ACM> (raw)
In-Reply-To: <jwv34whlk4t.fsf-monnier+emacs@gnu.org>
Hello, Stefan.
On Mon, Dec 04, 2023 at 16:56:41 -0500, Stefan Monnier wrote:
> >> Why include the file name? Presumably we will rely on a `(FILE . POS)`
> >> to find that docstring so including FILE in there is rather redundant
> >> (and in addition to that, this file name can be wrong if it's absolute
> >> since files often get moved between compilation and use).
> > No, the (FILE . POS) is the .elc file, the one I'm putting into the new
> > info is the source file.
> Until now, Emacs has always lived with the `.elc` file names (e.g. in
> `load-history`) and managed to find the corresponding `.el` file (when
> you try to jump to the source via `M-.` or by clicking in `C-h f`).
> It comes with its share of problems, but we've learned to live with them.
Yes. I've come to the same conclusion in the last hour or so that, no
doubt, early Emacs hackers reached forty years ago. We can find the
..elc full filename from load-history (via symbol-file), but there's no
more useful way of finding the corresponding source than removing the
'c' from the end of foo.elc. And if it's not there, it's nowhere.
> Is there any reason you think this new functionality should go through
> the extra trouble to record the `.el` name (and thus develop its own
> set of workarounds for the cases where the `.el` doesn't live where we
> think it should)?
Not any more, having thought it through.
Maybe, though, it would be useful in some circumstances to record the
buffer the definition was loaded from if it's not a file. But it's
getting rather late here, so I haven't thought this through at all.
> >> > the position of the defining symbol in the file, and the position of
> >> > the lambda (should we be in one) in the file.
> >> Why two positions?
> >> Why not use the same position info as used in `byte-compile-warn-x`?
> > I'm not sure, yet, but I suspect both positions will be useful.
> Can you give an example scenario?
Something about a lambda form, when we need to find the lambda itself,
but also its containing form. Sorry I can't be more definite, yet.
When I start hacking out the code to use all this information, it will
become clearer what we actually need. It's very easy to change at this
stage.
> >> > or (defining-symbol (if (consp struct) (car struct) struct))
> >> [ Haven't seen that yet. ]
> > Have a look at cl-defgeneric and cl-defmethod in cl-generic.el.
> Ah, got it. I like the way you can refer to args by name.
> So I guess all the (defining-symbol 1) could similarly be replaced with
> (defining-symbol THE-ARG-NAME).
Yes, I hadn't really thought of that. But (defining-symbol 1) matches
similar forms like (docstring 3) which are used somewhere.
> [ I also notice that this extension is somewhat incompatible with the
> use I proposed for `font-lock`. :-( ]
> [ As you noted, this info is also related to the `&define` debug spec.
> I wish we could unify that information. ]
Ah, the debug spec; yet another difficult domain specific language. ;-(
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2023-12-04 22:30 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-26 14:30 bug#67455: Record source position, etc., in doc strings, and use this in *Help* and backtraces Alan Mackenzie
2023-12-04 17:36 ` Alan Mackenzie
2023-12-04 18:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-04 21:32 ` Alan Mackenzie
2023-12-04 21:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-04 22:30 ` Alan Mackenzie [this message]
2023-12-04 22:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-15 18:23 ` Alan Mackenzie
2023-12-15 23:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <handler.67455.B.170100905232659.ack@debbugs.gnu.org>
2024-03-04 15:38 ` bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) Alan Mackenzie
2024-03-09 21:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-10 16:02 ` Alan Mackenzie
2024-03-10 17:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-10 19:22 ` Alan Mackenzie
2024-03-10 21:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-24 11:04 ` Alan Mackenzie
2024-03-25 18:23 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 21:03 ` Alan Mackenzie
2024-03-25 22:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-26 9:48 ` Alan Mackenzie
2024-03-26 13:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-26 16:55 ` Alan Mackenzie
2024-03-26 19:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-26 20:21 ` Alan Mackenzie
2024-03-26 20:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 3:35 ` Alan Mackenzie
2024-03-27 12:23 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 22:00 ` Alan Mackenzie
2024-03-26 20:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-26 21:13 ` Drew Adams
2024-03-27 10:04 ` Alan Mackenzie
2024-03-27 12:22 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 21:43 ` Alan Mackenzie
2024-03-28 16:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 16:48 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 9:10 ` Alan Mackenzie
2024-03-30 9:53 ` Alan Mackenzie
2024-03-31 2:22 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 11:35 ` Alan Mackenzie
2024-04-08 2:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 2:56 ` Alan Mackenzie
2024-04-10 8:53 ` Alan Mackenzie
2024-03-30 11:03 ` Alan Mackenzie
2024-03-31 2:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 10:57 ` Alan Mackenzie
2024-04-08 3:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 8:32 ` Alan Mackenzie
2024-04-08 12:00 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-02 13:38 ` Alan Mackenzie
2024-06-03 4:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-05 15:01 ` Alan Mackenzie
2024-03-10 22:27 ` Alan Mackenzie
2024-03-11 0:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-13 10:54 ` Alan Mackenzie
2024-03-13 11:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-19 16:18 ` Alan Mackenzie
2024-03-19 20:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-19 21:40 ` Alan Mackenzie
2024-03-19 22:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-24 11:21 ` Alan Mackenzie
2024-06-01 17:40 ` Alan Mackenzie
2024-06-01 18:01 ` Eli Zaretskii
2024-06-01 18:15 ` Eli Zaretskii
2024-06-01 18:17 ` Alan Mackenzie
2024-06-01 23:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=ZW5TB-6nnwXWkLfb@ACM \
--to=acm@muc.de \
--cc=67455@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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).