bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Stefan Monnier
Subject: bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.)
Date: Sat, 30 Mar 2024 22:22:52 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>> We're still miscommunicating.  You're talking about how your code is
>> implemented, apparently, whereas I'm asking about what is the
>> intended behavior.
> I am still mystified by your failure to understand "currently being
> defined", a phrase that to me could hardly be clearer.

AFAIK, the definition itself happens inside `Fdefalias`.  It's a very
short amount of time during which none of your code is executed, so that
can't be it.  The rest is the actual construction of the value/function
object which will make up the definition.  This construction is done
piecemeal in various phases at potentially various different times, not
all of them necessarily on the same machine.  Some of the code executed
during the course of the construction of this object have nothing at all
to do with that object, they just happen to be used by some code which
participates in the construction of that object.

So "currently" (i.e. referring to *time*) is very problematic because
it's only loosely correlated to what you're interested in.

>> It's like I'm asking what the C spec says and you're answering me by
>> telling me how GCC works.
>
> OK, let's try again.  defining-symbol records the symbol currently being
> defined.  It's used to set the defining symbol and buffer offset fields
> in the position structure in that symbol's doc string, and also in the
> doc strings of contained lambda forms.

I can try it again also if you want: to do it right, I think you want to
store that information in `macroexpand-all-environment`.

> Is my previous paragraph sufficiently clear?  If so, can you envisage a
> scenario where a symbol being defined would fail to get the two fields
> correctly set in its doc string or a lambda form's doc string?

Yes, for example I can imagine a lazy macroexpansion done to run some
code during the eager macroexpansion could mistakenly think that it is
part of the eagerly macroexpanded function (whereas it's only part of
the code used during the construction of that function).

I'm sure there are other cases, by thinking of it makes my head hurt.
Which is why I recommend you put that info into
`macroexpand-all-environment` which is designed specifically for such
purpose of "currently within the scope of something".


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]