fringe arrow conflict between compile and gud?

[Nick Roberts]

Here's my take on this:

In the beginning there was just one overlay-arrow-position shared between GUD
and Edebug. Now there are more modes competing for it, there are conflicts.
Compilation modes, as you describe uses it in two places and tries to get
round the problem by making overlay-arrow-position a local-variable. I think
this is the wrong way. Kim Storm created a variable overlay-arrow-variable-list
to allow multiple overlay arrows (see info). I have used this for buffers
displaying assembler in gdb-ui.el (gdb-overlay-arrow-position).

I can offer to try fix this problem but my analysis might be wrong. There
may be others who understand it better than me and who can fix it.


Nick


 > I have:
 > 
 > (setq next-error-highlight 'fringe-arrow)
 > 
 > If I find error while compiling, next-error put a fringe arrow in the
 > error line. If I fix the error and compile again, the fringe arrow
 > does not dissapear (I do not if this is intended to be this way).
 > 
 > If the I open a gud session, I cannot track execution on file where
 > compilation fringe arrow is (I suppose some sort of conflict occurs).
 > 
 > Sometimes an error occurs:
 > 
 > Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
 >   set-window-point(#<window 382 on *Backtrace*> nil)
 >   gud-display-line("/home/leon/Testing/C/foo.c" 2182)
 >   gud-display-frame()
 >   gud-filter(#<process gud-a.out> 
 > "/home/leon/Testing/C/foo.c:2182:59257:beg:0x805663b\n")
 > 
 > And sometimes no error, but "next" and "step" gud commands do not
 > scroll to line where program execution is.
 > 
 > Of course these problems dissapear as soon I reload source file where
 > fringe arrow was.