unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 66750@debbugs.gnu.org, Andrea Corallo <acorallo@gnu.org>,
	Stefan Kangas <stefankangas@gmail.com>,
	acm@muc.de
Subject: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value
Date: Sun, 29 Oct 2023 11:25:14 +0000	[thread overview]
Message-ID: <ZT5BGkuX7SJkF5R5@ACM> (raw)
In-Reply-To: <jwv1qdeoz6l.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Sun, Oct 29, 2023 at 00:14:24 -0400, Stefan Monnier wrote:
> >> > There are lots of detailed changes in eval.c and bytecomp.el (and
> >> > friends).  Also the macro `lambda' in subr.el has been amended to insert
> >> > the current global defining-symbol if there isn't already a non-nil
> >> > symbol in that position.
> >> So the source code can manually provide this extra symbol in `lambda`?
> >> Where have you found that useful?
> > The first few functions in debug-early.el and byte-run.el, for a start.
> > There, there is not yet a defmacro macro.  Also in
> > comp-trampoline-compile, where there doesn't seem to be any other way to
> > get the name of the primitive into the defining symbol.  I think there'll
> > be quite a few other places, too.

> Hmm... it seems like keeping the LINE+COL info rather than
> a surrounding definition would be better in this regard since it wouldn't
> require any changes at all to the actual lambdas, regardless where
> they are.

I don't agree with this.  Whether we add FILE+LINE+COL info is to a
large degree a separate question from that of adding defining symbol
info.

If you don't add information to the actual lambda, then that information
won't be available when that lambda turns up in a backtrace or as a
value in C-h v.  Surely you'd have to keep FILE+LINE+COL in the lambda
itself, somehow.

That also assumes that the source file will be available and unchanged
when it's needed.

It will also stress the user somewhat, since it will force her to look
up a file location to get any idea of what is failing.  A defining
symbol is much more immediately useful, even if it may not be 100%
dependable because of the issues you raise below.

> >> Hmm... as a user, rather than the enclosing definition I think I'd
> >> expect to get some kind of source information like FILE+LINE+COL.
> > Possibly: either is a good deal better than what we have at the moment.

> The notion of "surrounding definition" is less precise (there can be
> several lambdas inside a given definition, there can be lambdas outside
> of any definition, ...).

Yes, there can be several lambdas in a function, though I don't think
this is common.  Certainly it hasn't given me any problems in use, so
far.  But lambdas outside of definitions?  I doubt very much there are
any in the Emacs sources, or even in the packages.

Or are you thinking about something like an explicit (defalias foo
(lambda (..) ...))?

> Furthermore, that info is already available to the bytecompiler, so it's
> actually easier to keep that info.

How are you actually going to use this information?  What are you going
to print in a backtrace, in particular in a batch mode backtrace where
things like buttons are not useful?

For that matter, what are you going to print in that C-h v example?

> >> Actually, the bytecode functions can already keep the FILE info (in
> >> the form of the (FILE . OFFSET) cons cell in the docstring slot of the
> >> bytecode object), we just opt never to expose that FILE info to the user
> >> (we only use it to fetch the actual docstring).
> > That's the offset in the .elc file, though, not the source.

> Yup.  [ Tho now that you make me think about it, if we want to be cheap,
> we could go to that OFFSET position and look around for a `^(defalias`
> and that might be sufficient to give us "the surrounding definition" in
> many cases :-)  ]

That doesn't sound systematic, or at all attractive.  ;-)

> >> [ Tho, admittedly, it's also that the byte-compiler only uses such
> >>   (FILE . OFFSET) for named functions, but it wouldn't be hard to change.  ]
> >> As for how/where to store the LINE+COL, I guess (aref form 5) is still
> >> an option, although, maybe we should store that info alongside the
> >> docstring, like we already do for the arglist.
> > Well, the doc string is at (aref form 4).  :-)

> What I meant is that the docstring is in the `.elc` file.  So the
> bytecode object would be literally unchanged, it's just that the
> bytes found at OFFSET inside FILE would be extended to hold:
> - the docstring
> - the human-readable arglist
> - the LINE+COL info

Don't forget, all this info would have to go into .eln files too,
probably in the struct Lisp_Subr.  It would be better if it were also
somehow available in uncompiled lambdas, something which is needed for
debugging failures in early bootstrapping.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2023-10-29 11:25 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 [this message]
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                 ` bug#66750: help-split-fundoc (was: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value) 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=ZT5BGkuX7SJkF5R5@ACM \
    --to=acm@muc.de \
    --cc=66750@debbugs.gnu.org \
    --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).