all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Sun, 7 Apr 2024 10:57:50 +0000	[thread overview]
Message-ID: <ZhJ8Ltr3DuuAyFOD@ACM> (raw)
In-Reply-To: <jwvplvbta02.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

Sorry about the delay - I lost my email server after an obsolete SSL
library got deleted from my system, and one or two other things, too.

On Sat, Mar 30, 2024 at 22:54:18 -0400, Stefan Monnier wrote:
> > Some symbols must not be stripped.  For example, in cl-generic.el L403
> > we have:

> >     (fun `(cl-function (lambda ,plain-args ,@body)))              

> > ..  There the position on the lambda must be preserved until ME2 time
> > when it becomes clear what the shape of the lambda is.  In particular,
> > whether there is already a doc string in ,@body to amend, or we need to
> > insert a new one.

> I could see some reasons you *may* want to keep some info here, but it's
> definitely not a "must" because the source position of those functions
> should generally not point to `cl-generic.el:403` but to where
> `cl-defmethod` was used.

Pretending the problem doesn't exist won't solve it.  In the ;POS...
structures for a lambda, there are two pointers - one to the definition
of the lambda, the other to the point of use.

> Also, if you do want to preserve some info there (presumably with the
> intent to combine it with the more important info that will be available
> at ME2) it will need cooperation from `cl-generic.el` because, as far as
> the semantic of Emacs Lisp is concerned, the above constructs a list
> with a `lambda` symbol inside of it, with no guarantee that it will be
> used as a function, ....

Mostly there is the symbol `function' in that position.  Here we've got
`cl-function' which expands to function.  Surely with (function (lambda
....)) we know we're dealing with a function.

> .... and even if ever used as a function there's no guarantee that this
> list will pass through the few places where we strip SWPs, so keeping
> SWPs in there without some explicit request from `cl-generic.el` would
> be a bug.

I don't think this is right.  The code will pass through
macroexp--expand-all, which is where the SWP wii be stripped.

> IOW, I don't think it's a good reason to rule out

>     (strip-all-symbol-positions
>      (macroexp--expand-all
>       (read-positioning-symbols)))

As I've said, we'd need code to preserve the SWPs on "complicated"
lambdas.  I haven't even begun to think about how this could work.

> BTW, AFAIK the above is conceptually what the byte-compiler does (except
> it performs a few more transformations between `macroexp--expand-all`
> and `strip-all-symbol-positions`).

It is a bad idea to conflate these two radically different uses of SWPs.
That can only lead to confusion and bugs.

> Is it the case that `cl-defmethod` generates a function whose source
> position (partly) points to `generic.el:403` if `cl-generic.el` was
> interpreted but not if it compiled?

No, the intention is that the source positions are independent of whether
the code is compiled.

> >> >> >> Also, IIUC you don't have a separate phase to strip the SWPs when
> >> >> >> loading from source, but instead you strip them as you "consume" their
> >> >> >> info during macroexpansion.  If so, how/when/where do you strip the
> >> >> >> false positives that may occur inside quoted data or in code like:

> >> >> >>     (defmacro foo (lambda bar) ...)

> > (defmacro foo (lambda bar)
> >   `(cons ,lambda ,bar))

> > expands to

> > (macro closure (t) (lambda bar) ";POS^^^A^A^A [foo *scratch* 158 nil]
> > " (list 'cons lambda bar))

> IIUC your reader will make the `lambda` formal argument into an SWP.
> Where is that SWP stripped?

In macroexp--expand-all in the "guard arm" near the end.

> > so it is clear this case is getting handled OK.  I'm afraid I can't
> > point out the exact place in the code at the moment where this is
> > getting done.

> I think it would be good to know, so as to be able to decide whether
> it'll indeed always work right, or we just got lucky this time.

See above.

> >> I don't actually know whether it will be better.  It just seems it could
> >> lead to simpler code, with no change at all to the reader, for example.
> > The exercise is intrinsically complicated.

> Could you explain what you think makes it intrinsically complex?

The mass of detail that needs dealing with that Emacs has collected over
the decades.  As a counter question, why do you think the exercise ought
to be simple (assuming you do think this)?

> > What you're suggesting is that the code to decide which SWPs to strip
> > is going to be simpler than the enhancements to the reader.

> As seen above, I suggest to leave the reader unchanged and to strip all
> SWPs.  I'm pretty sure it would give comparable info to what you have
> and it would be simpler (also, it would make it much less likely to
> have discrepancies between the compiled case and the interpreted case).

"Comparable" isn't good enough - we need the position info on
"complicated" lambdas to endure, somehow.  There are no discrepancies
between compiled and interpreted forms because they both use the same
mechanism in macro expansion.

> My main worry with it would be performance.

Yhat, too.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2024-04-07 10:57 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZhJ8Ltr3DuuAyFOD@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.