[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstr

From: Paul Eggert
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Thu, 29 Nov 2018 13:28:06 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 11/28/18 4:04 AM, Alan Mackenzie wrote:

Assuming the macro is compiled, just where are these cons positions
going to be stored?

The same place we store the rest of compiled output. That is, when we byte-compile macros, we store the uncompiled macros (with source-pos info) into the .elc file. Then, any code that wants accurate line number or similar debugging information for the macro can use the uncompiled version. It's pretty common to bloat object files to support debugging in this way.

This approach wouldn't work for .elc files generated by older versions of Emacs, but that's OK; the old macros should still work, it's just that the byte-compiler's diagnostics will be just as bad as before.

(Sorry, I don't know how edebug works so I don't know how this would affect edebug.)

You're wrong, here.  Symbols-with-pos works on the output from macros.
Conses-with-pos will only do so for some "nice" macros, ones which
preserve their input conses.
I'm afraid we'll have to disagree here, as I can see examples where symbols-with-pos fails and conses-with-pos works (as well as vice versa). The only good way I see to resolve the disagreement would be to build it both ways and see which typically works better in the real world. A daunting prospect, admittedly.

reply via email to

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