Re: Is there a package which uses markers to guess how to remap line numbers?

[rocky]

On Nov 19, 10:25 am, des...@verizon.net wrote:
> rocky <ro...@gnu.org> writes:
> > I am writing a package (an interface to debuggers) that sets markers
> > on various lines (e.g. the lines at which the debugger stops at). Over
> > time, the buffer (source code) can change and the markers move around
> > with that. This is good.
>
> > Is there however a package which will suggest after buffer
> > modification how a particular line number might have changed given the
> > existingmarkerinformation and associated line number information for
> > that buffer?
>
> > Here is a concrete example. Let's say I have a buffer with amarkerat
> > lines 1, 5, 10 and 20. Let's say themarkerfor 10 moves to line 11
> > after modification but not the one for 1, 5 or 20.
>
> > If I ask about lines in the range 2-4, I may warn that overall the
> > buffer has changed but possibly not the one in that range. Of course
> > if I ask about lines 1, 5, or 20, I can warn that although the buffer
> > has changed, (parts of) those lines haven't. If I ask about a line in
> > the range 6-19 I can suggest there may be a move ahead a line with
> > more certainty of line 10.
>
> > Has anyone thought about this problem. Does such a package exist or
> > has anything like this been done as part of an existing package?
>
> Part of the compile package does something like that.
> As you do "next-error" it accounts for any fixes you may have made
> for previous errors.

Thanks for the suggestion.

I looked at compile.el. It seems to be to parse all of the error
messages in the compilation buffer and set markers for each of those
locations referred to. That is why it can track edits.

The difference here is that we are interactive, so I don't know in
advance all of the lines that might be stopped at.

Assuming a debugger that only reports line positions and nothing finer
grained, I could set marks at every line in the file, or better sets
marks at every stoppable line in the file (i.e. the lines that you can
set a breakpoint on). However I suspect that will be too slow and/or
use lots of memory.

But perhaps not - we'll see.