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

["Clément Pit-Claudel" <cpitclaudel@gmail.com>]

On 01/12/2018 12.21, Alan Mackenzie wrote:
> Not one reply has offered to try to help optimise the new code, rather
> than discarding it.

Hey Alan,

I'm very thankful for your efforts to fix this longstanding bug (incorrectly-located warnings are a continuing source of confusion for me, and positions in backtraces, which I think would be a natural extension of your work, would make a lot of debugging work easier).

On the other hand, I understand worries about performance.  Besides vim, Emacs is roughly the only full-featured editor that runs on my raspberry pi at a reasonable speed.  I'm sure there's no malice in the worries expressed by others on this list; rather, it's easy to worry that somewhat costly changes will accumulate until we get performance as bad as many other more recent IDEs.

Here's one technical question about the branch:

IIUC, your code's strategy is to attach location info to symbols as they are read; this is a clever trick, because macroexpansion tends to preserve symbols more than it preserves conses (interestingly, Racket macros are given syntax objects that include position information instead of raw SEXPs for precisely this reason).  But, again IIUC, attaching position information on symbols means that they cannot be compared using pointer equality anymore, which means that EQ must get slower.  I wonder: after byte-compiling and reporting accurately-positioned warnings, couldn't we strip position information from symbols, so that usual Emacs execution isn't affected? The idea would be to start by reading in symbols with position information, preserve this position information throughout byte-compilat
 ion, and then strip it so that the rest of the code can use raw pointer equality.

If that is still too slow, could we have two version of read, one acting just like today and one returning sexps whose symbols contain position information?  Then we would change the byte-compiler to use the latter, and use eq-with-position-information instead of eq throughout the file.  Wouldn't such a scheme make use of the code you wrote, while restricting the performance impact to the byte-compiler and leaving the rest of Emacs unchanged?

Cheers and thanks again for your work,
Clément.