[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: Clément Pit-Claudel
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Sat, 1 Dec 2018 12:50:20 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

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-compilation, 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,

reply via email to

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