emacs-devel
[Top][All Lists]
Advanced

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

Re: Tracking buffer positions across time, without markers (was Re: PL s


From: Clément Pit-Claudel
Subject: Re: Tracking buffer positions across time, without markers (was Re: PL support)
Date: Sun, 10 May 2020 16:52:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 10/05/2020 15.49, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <address@hidden> Date: Sun, 10 May
>> 2020 15:27:47 -0400
>> 
>> The general problem is this: I send the contents of a buffer to a
>> subprocess.  Some time later, the subprocess returns a list of
>> positions (offsets from the beginning of the buffer, or line/column
>> pairs, etc).  At that point, these positions may be stale, since
>> the contents of the buffer may have changed.  I need a way to
>> translate these positions (relative to the old buffer contents)
>> into positions relative to the new buffer contents.
> 
> If by the time the output arrives the user have edited the buffer,
> you will have to throw the output away, and send a new request.

No, it's quite acceptable to use the old output in my case, as long as it can 
be displayed in the right place.

> Rinse, repeat.  Eventually, the user will stop typing, at least for a
> short time, and the output that arrives after that could be used for 
> fontifying because no changes have been done.  But if this never 
> happens, i.e. the user keeps being ahead of the subprocess, it would 
> mean the buffer will not be fontified for a time that is long enough 
> to be an annoyance.  Which means the solution is not workable.
> Right?

My use case is not fontification, it's showing errors and hints from a 
compiler.  It's not unusual for compilation cycles or checking to take up to a 
minute, and resending the query doesn't help.
 
> IOW, the process of sending whatever you need to send and receiving 
> the output should be fast enough to be completed before the user
> types a lot, or at least short enough to hold off buffer
> modifications, or else this is simply not going to work.

It works OK currently, although often the highlights are not exactly in the 
right place.




reply via email to

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