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: Tue, 26 Mar 2024 20:21:50 +0000	[thread overview]
Message-ID: <ZgMuXkD07TRSe__n@ACM> (raw)
In-Reply-To: <jwvzfuk3inj.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Tue, Mar 26, 2024 at 15:40:05 -0400, Stefan Monnier wrote:
> >> >> > Sorry about that.  A quick summary: defined symbols (and lambda) get
> >> >> > positioned by the new reader function read-positioning-defined symbols.
> >> >> > The new declare clause defining-symbol marks a macro such as defun or
> >> >> > cl-defgeneric as a macro which defines such symbols.

> >> Since I still don't understand the general picture, let me tell you how
> >> I would plan to do it, so you can tell me where it matches your
> >> approach and where it doesn't:

> >> - Change `load-source-file-function` so it uses
> >>   `read-positioning-symbols` instead of plain `read`.
> >>   [ This means that macro-expansion will now almost always have sympos,
> >>     rather than only during compilation,  ]

> > load-source-file-function is set to read-positioning-defined-symbols.

> [ I see it's `load-read-function`.  ]

Yes!

> How does this differ from `read-positioning-symbols` and why do we need
> it to be different?

r-p-defined-s positions only lambdas and NAMEs defined by defun,
defmacro, defvar, .... (around 50 defining symbols).  r-p-s positions
every symbol apart from nil.  They have different purposes.  r-p-d-s
gets info for the doc strings, which requires SWPs only for some
symbols.  r-p-s is needed to get warning message locations.  Were r-p-s
used for the doc string position information, most of the symbols would
need to be stripped of their positions before the form could be used.
It is simpler and faster not to position them at all.

> > (In a change to be committed, it gets bound to this function in Fload).
> > In reading

> >     (defun foo () "foo doc" (lambda (bar) "lambda doc" (car bar)))

> > , foo gets positioned (because it follows defun), and so does lambda
> > (because it is a lambda following "(").

> IIUC "gets positioned" means that it is a symbol-with-pos rather than
> a bare symbol?

Yes.

> > I'm not entirely sure, but I think in non-eager macro expansion the
> > position information in SWPs is typically available.

> In lazy macro-expansion, SWPs are not available, no.
> But that's OK, it's rare and there's very little we can do about it (the
> reason it's lazy is indeed because we only discover very late that those
> sexps were meant to represent code.  It's typically when a sexp is
> passed to `eval`).

OK.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2024-03-26 20:21 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 [this message]
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

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

  git send-email \
    --in-reply-to=ZgMuXkD07TRSe__n@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.