[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67455: (Record source position, etc., in doc strings, and use this i
From: |
Alan Mackenzie |
Subject: |
bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) |
Date: |
Wed, 27 Mar 2024 22:00:09 +0000 |
Hello, Stefan.
On Wed, Mar 27, 2024 at 08:23:52 -0400, Stefan Monnier wrote:
> >> > 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 terms of code, I can't see why it'd be simpler: we already have the
> >> r-p-s function, ....
> > We also already have r-p-d-s.
> You're playing on words here: we don't "already have" `r-p-d-s` on master.
I'm not playing on words. My point is that
read-positioning-defined-symbols exists and works. It is not a
speculative "would be nice to have". The work has already been done.
> > Both functions (together with plain read) have read0 as their core
> > engine. The enhancement to read0 to support r-p-d-s was only moderate
> > in size and not complicated to anybody who understands finite
> > state machines.
> Just because it's not a complex change doesn't mean it's "simpler" than
> no change at all.
No change isn't an option, here. Something has to determine which
symbols are to be positioned / stripped of their positions. Currently,
this is done economically in r-p-d-s.
> >> .... and we already have a function to strip that info when we don't
> >> need it any more, so it would be less new code to write if we just
> >> used r-p-s, I think.
> > I think you're envisaging an extensive redesign where SWPs would not be
> > tightly and individually controlled as they are at the moment, but
> > instead would be created en masse and stripped en masse a bit later.
> Yes, that's the starting design I had in mind (and that I described
> a few emails back). it's also what we do in the byte-compilation case, ...
It's not. In each case, the optimum number of symbols gets positioned.
Positioning "everything" is sub-optimal for everything bar byte
compilation.
> so it's code we already have and use.
See above.
> The "en masse" doesn't make it complex.
It changes the design extensively, thus introducing new complications.
Why do you think this design change will be better than the existing
design?
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), (continued)
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/25
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/25
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/27
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.),
Alan Mackenzie <=
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Drew Adams, 2024/03/26
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/27
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/27
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/27
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/28
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/28
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/30
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Alan Mackenzie, 2024/03/30
- bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.), Stefan Monnier, 2024/03/30