[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 15:27:47 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 10/05/2020 00.32, Eli Zaretskii wrote:
> On May 10, 2020 6:45:13 AM GMT+03:00, "Clément Pit-Claudel" <address@hidden>
> wrote:
>> On 09/05/2020 19.26, João Távora wrote:
>>> This is done with an idle timer, much the way that Flycheck
>>> works, I believe.
>>
>> Yup, it's a longstanding issue in Flycheck ^^
>>
>>>> A bit. But this works only if the interaction is fast enough,
>> right? (Same for syntax errors: positions may well be outdated by the
>> time the errors come back)
>>
>>> By that time another request is probably already underway.
>>
>> As long as the requests are fast. With slow checkers (typically,
>> proof assistants and automated reasoning tools, a single query can
>> easily take a minute — by that point lots can have changed in a
>> buffer.
>>
>> The APIs that make this work in Visual Studio (spans and snapshots)
>> are described here:
>> https://docs.microsoft.com/en-us/visualstudio/extensibility/inside-the-editor?view=vs-2019
>>
>> I'd love to hear opinions on what the proper implementation of this
>> would for Emacs be.
>
> Can you explain why using markers is not a good solution for this?
Of course: in brief, because we don't know where to put the markers.
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.
Since we don't know beforehand what positions the subprocess will return, I
don't think markers can help; right?
- Tracking buffer positions across time, without markers (was Re: PL support), Clément Pit-Claudel, 2020/05/09
- Re: Tracking buffer positions across time, without markers (was Re: PL support), João Távora, 2020/05/09
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Clément Pit-Claudel, 2020/05/09
- Re: Tracking buffer positions across time, without markers (was Re: PL support), João Távora, 2020/05/09
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Clément Pit-Claudel, 2020/05/09
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Eli Zaretskii, 2020/05/10
- Re: Tracking buffer positions across time, without markers (was Re: PL support),
Clément Pit-Claudel <=
- RE: Tracking buffer positions across time, without markers (was Re: PL support), Drew Adams, 2020/05/10
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Eli Zaretskii, 2020/05/10
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Clément Pit-Claudel, 2020/05/10
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Eli Zaretskii, 2020/05/11
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Clément Pit-Claudel, 2020/05/11
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Stefan Monnier, 2020/05/11
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Stefan Monnier, 2020/05/10
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Eli Zaretskii, 2020/05/10
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Stefan Monnier, 2020/05/10
- Re: Tracking buffer positions across time, without markers (was Re: PL support), Vladimir Sedach, 2020/05/10