I'm still chasing my Holy Grail: the newer Emacs debugger interfaces.
I'll soon send in the changes to comint.el that I needed to make some of
this stuff work. However, I'm facing another problem where I could use
the help of my fellow designers.
We support overlay-arrow-position and overlay-arrow-string, which are
used by our GDB support to show which line control has reached. The
newer Emacs stuff draws multiple overlaid arrows and things to show
various bits of information in debugger buffers. To support this, they
have introduced overlay-arrow-variable-list, which has the following
docstring:
List of variables (symbols) which hold markers for overlay arrows.
The symbols on this list are examined during redisplay to determine
where to display overlay arrows.
They modified their redisplay engine to support this list. The newer
debugger support uses this variable.
I could attempt to modify our redisplay engine to support
overlay-arrow-variable-list as well, but that doesn't help. The
debugger changes are going to go into packages, so I can't use
capabilities that aren't already present in released XEmacsen.
What do we have in place that I might be able to use instead?
Thanks,
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University

I'm still chasing my Holy Grail: the newer Emacs debugger interfaces.
I'll soon send in the changes to comint.el that I needed to make some of
this stuff work. However, I'm facing another problem where I could use
the help of my fellow designers.
We support overlay-arrow-position and overlay-arrow-string, which are
used by our GDB support to show which line control has reached. The
newer Emacs stuff draws multiple overlaid arrows and things to show
various bits of information in debugger buffers. To support this, they
have introduced overlay-arrow-variable-list, which has the following
docstring:
List of variables (symbols) which hold markers for overlay arrows.
The symbols on this list are examined during redisplay to determine
where to display overlay arrows.
They modified their redisplay engine to support this list. The newer
debugger support uses this variable.
I could attempt to modify our redisplay engine to support
overlay-arrow-variable-list as well, but that doesn't help. The
debugger changes are going to go into packages, so I can't use
capabilities that aren't already present in released XEmacsen.
What do we have in place that I might be able to use instead?

the only thing i know of that might help is `annotations', i.e. marginal
extents. these are designed for exactly this sort of thing (although they
won't exactly overlay the text).

What, I wasn't specific enough? :-) I didn't know what bits of
information myself; I just saw the uses of overlay-arrow-variable-list
in the code. Further digging shows that the Emacs GDB support is still
only using a single overlay arrow per debug buffer. The trick is that
overlay-arrow-position and overlay-arrow-string can be used by only 1
buffer at a time. With the new Emacs stuff, they can support having
multiple debug sessions going simultaneously, with an overlay arrow in
each.
A grep through the Emacs sources show that overlay-arrow-variable-list
is used only by the gud/gdb-ui modes, and by simple.el to support
next-error in compilation buffers. The Emacs approach means that minor
modes can safely use overlay arrows, though, if anyone ever comes up
with a minor mode that can meaningfully use one.
As I see it, I have at least the following choices when porting the
newer debugger interfaces:
1) Replace overlay-arrow-variable-list with the existing
overlay-arrow-position/string and tell our users not to try to have
multiple debugger sessions going simultaneously.
1a) Add overlay-arrow-variable-list to 21.5 and make the debugger
Lisp detect and use it when available.
2) Take Ben's suggestion and check out the annotation package to see if
it provides the needed functionality.
3) See whether any existing extent properties make them suffice for the
purposes of the debugger code.
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University

Jerry> 2) Take Ben's suggestion and check out the annotation
Jerry> package to see if it provides the needed functionality.
I like that one. And how about
4) Make the variables buffer-local in 21.5 and warn 21.4 users that
they'll get hosed if they have more than one session going at once.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.