`overlay-arrow-position' should be automatically buffer-local

`overlay-arrow-position' should be automatically buffer-local

[Daniel Brockman]

I believe the variable `overlay-arrow-position' should
automatically become buffer-local whenever it is set.

It appears that Gnus fails to do this manually, instead
ending up setting the global value to a marker that refers
to the Gnus summary buffer, which doesn't make sense.

In fact, I see no reason to ever set the global value of
this variable.  In any case, it should not be the default.

-- 
Daniel Brockman <daniel@brockman.se>

Re: `overlay-arrow-position' should be automatically buffer-local

[Ryan Yeske]

   I believe the variable `overlay-arrow-position' should
   automatically become buffer-local whenever it is set.

   It appears that Gnus fails to do this manually, instead
   ending up setting the global value to a marker that refers
   to the Gnus summary buffer, which doesn't make sense.

   In fact, I see no reason to ever set the global value of
   this variable.  In any case, it should not be the default.

I recently noticed when adding an overlay arrow to rcirc that making
it `overlay-arrow-position' buffer local *does* work (you can get an
arrow in multiple buffers), even though (elisp)Overlay Arrow says:

 - Variable: overlay-arrow-position

     [...]

     The overlay string is displayed only in the buffer that this marker
     points into.  Thus, only one buffer can have an overlay arrow at
     any given time.

Which I think was true in 21.

Re: `overlay-arrow-position' should be automatically buffer-local

[Daniel Brockman]

Ryan Yeske <rcyeske@gmail.com> writes:

>  - Variable: overlay-arrow-position
>
>      [...]
>
>      The overlay string is displayed only in the buffer
>      that this marker points into.  Thus, only one buffer
>      can have an overlay arrow at any given time.
>
> Which I think was true in 21.

Interesting.  That would certainly explain why it has not
been made to automatically become buffer-local.

Here is a seemingly relevant entry from src/ChangeLog:

2004-03-02  Kim F. Storm  <storm@cua.dk>

	* window.h (struct window): New member
        overlay_arrow_bitmap.

	* window.c (make_window): Initialize
        overlay_arrow_bitmap.

	* xdisp.c (Voverlay_arrow_variable_list):
	New variable to properly implement and integrate
	multiple overlay arrows with redisplay.

        [...]

Since the restriction seems to have been lifted, I think we
should remove the paragraph that Ryan quoted from the manual
and make the variable automatically become buffer-local.

-- 
Daniel Brockman <daniel@brockman.se>

Re: `overlay-arrow-position' should be automatically buffer-local

[Richard M. Stallman]

    Since the restriction seems to have been lifted, I think we
    should remove the paragraph that Ryan quoted from the manual
    and make the variable automatically become buffer-local.

It isn't worth bothering with, given overlay-arrow-variable-list.

Re: `overlay-arrow-position' should be automatically buffer-local

[Nick Roberts]

 >    I believe the variable `overlay-arrow-position' should
 >    automatically become buffer-local whenever it is set.
 > 
 >    It appears that Gnus fails to do this manually, instead
 >    ending up setting the global value to a marker that refers
 >    to the Gnus summary buffer, which doesn't make sense.
 > 
 >    In fact, I see no reason to ever set the global value of
 >    this variable.  In any case, it should not be the default.

Have you found this a problem in practice?

I think Gnus and Edebug are the only two features that now use the global
values of overlay-arrow-position (so they would steal the arrow from each
other if they were both active at the same time).

 > I recently noticed when adding an overlay arrow to rcirc that making
 > it `overlay-arrow-position' buffer local *does* work (you can get an
 > arrow in multiple buffers), even though (elisp)Overlay Arrow says:
 > 
 >  - Variable: overlay-arrow-position
 > 
 >      [...]
 > 
 >      The overlay string is displayed only in the buffer that this marker
 >      points into.  Thus, only one buffer can have an overlay arrow at
 >      any given time.
 > 
 > Which I think was true in 21.

I think you've always been able to make overlay-arrow-position buffer-local.
The problem arises when two arrows try to display in the _same_ buffer, then
the local value masks the global value.  Perhaps this will never happen in
Gnus, but in case it does, a good way is to use overlay-arrow-variable-list
(which _is_ new to to Emacs 22):

(defvar gnus-overlay-arrow-position nil)

At startup:

(setq gnus-overlay-arrow-position nil)
(add-to-list 'overlay-arrow-variable-list 'gnus-overlay-arrow-position)

On finishing:

(delq 'gnus-overlay-arrow-position overlay-arrow-variable-list))

Nick

Re: `overlay-arrow-position' should be automatically buffer-local

[Ryan Yeske]

   I think you've always been able to make overlay-arrow-position buffer-local.
   The problem arises when two arrows try to display in the _same_ buffer, then
   the local value masks the global value.  Perhaps this will never happen in
   Gnus, but in case it does, a good way is to use overlay-arrow-variable-list
   (which _is_ new to to Emacs 22):

Well, the following doesn't work in 21.3 but does in recent cvs
versions (I get an arrow in each buffer in the latter):

(progn
  (switch-to-buffer "buf1")
  (delete-other-windows)
  (make-variable-buffer-local 'overlay-arrow-position)
  (setq overlay-arrow-position (make-marker))
  (set-marker overlay-arrow-position (point-min))
  (with-current-buffer (pop-to-buffer "buf2")
    (make-variable-buffer-local 'overlay-arrow-position)
    (setq overlay-arrow-position (make-marker))
    (set-marker overlay-arrow-position (point-min))))

Maybe I'm missing something, but I don't see why you need to use
`overlay-arrow-variable-list' since you can just make
`overlay-arrow-position' buffer local where you need it and get a
local arrow that way.  Or is that abusing `overlay-arrow-position'
which might be intended to be a single global arrow?

Re: `overlay-arrow-position' should be automatically buffer-local

[Nick Roberts]

 > Well, the following doesn't work in 21.3 but does in recent cvs
 > versions (I get an arrow in each buffer in the latter):
 > 
 > (progn
 >   (switch-to-buffer "buf1")
 >   (delete-other-windows)
 >   (make-variable-buffer-local 'overlay-arrow-position)
 >   (setq overlay-arrow-position (make-marker))
 >   (set-marker overlay-arrow-position (point-min))
 >   (with-current-buffer (pop-to-buffer "buf2")
 >     (make-variable-buffer-local 'overlay-arrow-position)
 >     (setq overlay-arrow-position (make-marker))
 >     (set-marker overlay-arrow-position (point-min))))

But this works in 21.3:

(progn
  (switch-to-buffer "buf1")
  (delete-other-windows)
+  (setq overlay-arrow-string "=>")                
  (make-local-variable 'overlay-arrow-position)
  (setq overlay-arrow-position (make-marker))
  (set-marker overlay-arrow-position (point-min))
  (with-current-buffer (pop-to-buffer "buf2")
    (make-local-variable 'overlay-arrow-position)
    (setq overlay-arrow-position (make-marker))
    (set-marker overlay-arrow-position (point-min))))

This line is not needed in 22.0.50 because of this change:

2005-04-08  Kim F. Storm  <storm@cua.dk>

	* xdisp.c (syms_of_xdisp): Init overlay-arrow-string to "=>".

 > Maybe I'm missing something, but I don't see why you need to use
 > `overlay-arrow-variable-list' since you can just make
 > `overlay-arrow-position' buffer local where you need it and get a
 > local arrow that way.  Or is that abusing `overlay-arrow-position'
 > which might be intended to be a single global arrow?

I've already given one reason.  With Edebug, the overlay arrow can hop from
file to file and hence, from buffer to buffer.  I'm not sure what the
consequences are.  You'd have to reset all their values to nil after debugging
for a start.

Nick

Re: `overlay-arrow-position' should be automatically buffer-local

[Richard M. Stallman]

    I recently noticed when adding an overlay arrow to rcirc that making
    it `overlay-arrow-position' buffer local *does* work (you can get an
    arrow in multiple buffers), even though (elisp)Overlay Arrow says:

I will fix the manual.

Re: `overlay-arrow-position' should be automatically buffer-local

[Kim F. Storm]

Daniel Brockman <daniel@brockman.se> writes:

> I believe the variable `overlay-arrow-position' should
> automatically become buffer-local whenever it is set.
>
> It appears that Gnus fails to do this manually, instead
> ending up setting the global value to a marker that refers
> to the Gnus summary buffer, which doesn't make sense.
>
> In fact, I see no reason to ever set the global value of
> this variable.  In any case, it should not be the default.

In principle, there is only one overlay-arrow-position variable,
and since its value is a marker, its value includes the buffer
in which it occurs.

This is how e.g. gdb can easily move the overlay arrow between buffers
-- just modify the global variable.  

If the variable was buffer local, you would have to be sure to clear
out the old buffer-local value whenever the arrow was moved to another
source buffer.

Besides, having buffer-local overlay arrow variables may confuse the
redisplay engine in some obsure cases (or at least it used to do that
-- can't remember if I managed to fix that).

GNU probably doesn't have this problem, so it would be ok to make it
buffer local in the summary buffer.  

In emacs 22, GNU may use its own overlay arrow variable and add it to
the overlay-arrow-variable-list.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: `overlay-arrow-position' should be automatically buffer-local

[Ryan Yeske]

   In principle, there is only one overlay-arrow-position variable,
   and since its value is a marker, its value includes the buffer
   in which it occurs.

   This is how e.g. gdb can easily move the overlay arrow between buffers
   -- just modify the global variable.  

gdb could use a *gud* buffer local variable.  That way multiple
instances of gud wouldn't steal the arrow from eachother.

Re: `overlay-arrow-position' should be automatically buffer-local

[Nick Roberts]

 >    In principle, there is only one overlay-arrow-position variable,
 >    and since its value is a marker, its value includes the buffer
 >    in which it occurs.
 > 
 >    This is how e.g. gdb can easily move the overlay arrow between buffers
 >    -- just modify the global variable.  
 > 
 > gdb could use a *gud* buffer local variable.  That way multiple
 > instances of gud wouldn't steal the arrow from eachother.

Its not about multiple instances of GUD.  The overlay arrow is displayed in
the _source_ buffer, not the GUD buffer.  As execution proceeds it can move
from file to file and hence, buffer to buffer i.e it would have the same
problem as Edebug.  Incidentally, GUD does have its own overlay arrow now and
it seems to work fine.

Nick

Re: `overlay-arrow-position' should be automatically buffer-local

[Kim F. Storm]

Ryan Yeske <rcyeske@gmail.com> writes:

>    In principle, there is only one overlay-arrow-position variable,
>    and since its value is a marker, its value includes the buffer
>    in which it occurs.
>
>    This is how e.g. gdb can easily move the overlay arrow between buffers
>    -- just modify the global variable.  
>
> gdb could use a *gud* buffer local variable.  That way multiple
> instances of gud wouldn't steal the arrow from eachother.

Redisplay looks at the buffer-local value of overlay-arrow-position in
the current buffer (window) being displayed -- so if you set it
buffer-local in *gud* buffer, it will still be nil in the source
buffer -- so no arrow is shown in the source buffer...

IOW, what you suggest does not work as a general feature, so can we
please stop this thread.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: `overlay-arrow-position' should be automatically buffer-local

[Miles Bader]

2005/10/20, Ryan Yeske <rcyeske@gmail.com>:
> gdb could use a *gud* buffer local variable.  That way multiple
> instances of gud wouldn't steal the arrow from eachother.

BTW, in case nobody's noticed the current gud/gdba routinely gets
completely confused by multiple debugging sessions already...

-miles
--
Do not taunt Happy Fun Ball.

Re: `overlay-arrow-position' should be automatically buffer-local

[Nick Roberts]

 > BTW, in case nobody's noticed the current gud/gdba routinely gets
 > completely confused by multiple debugging sessions already...

It's come up at least twice before.  I rarely debug two programs at the same
time and when I do, I can do it with two instances of Emacs.  For those that
need multiple debugging sessions there's a note in the Emacs manual to use
"gdb -fullname" (even this isn't perfect: try setting a breakpoint with C-x
SPC in both source buffers).  Its a lot of work to implement this feature and
until there is a release any perceived need can only be anecdotal.

Nick

Re: `overlay-arrow-position' should be automatically buffer-local

[Miles Bader]

2005/10/20, Nick Roberts <nickrob@snap.net.nz>:
>  > BTW, in case nobody's noticed the current gud/gdba routinely gets
>  > completely confused by multiple debugging sessions already...
>
> It's come up at least twice before.  I rarely debug two programs at the same
> time and when I do, I can do it with two instances of Emacs.

This is OK as a temporary workaround before the release, but I think
it's unacceptable in the long term -- I, at least, want to debug
multiple programs routinely, and it's very inconvenient to juggle
multiple emacs sessions to do so.

> For those that
> need multiple debugging sessions there's a note in the Emacs manual to use
> "gdb -fullname"

I recall that before gdba, this was the default; why was it changed?

-miles
--
Do not taunt Happy Fun Ball.

Multiple debugging sessions [was Re: `overlay-arrow-position' should be automatically buffer-local]

[Nick Roberts]

 > > It's come up at least twice before.  I rarely debug two programs at the
 > > same time and when I do, I can do it with two instances of Emacs.
 > 
 > This is OK as a temporary workaround before the release, but I think
 > it's unacceptable in the long term -- I, at least, want to debug
 > multiple programs routinely, and it's very inconvenient to juggle
 > multiple emacs sessions to do so.

I can understand that it's not as ideal as working with one instance.  Could
you please explain, in practical terms, what makes it "very inconvenient".

After the release, I want to migrate Emacs from using annotations to using
GDB/MI, since this is the new interface for GDB and the GDB developers
plan to obsolete annotations.  I also want to help make GDB asynchronous
so that front ends can be event driven rather than work by polling.  I'm
afraid that managing multiple debugging sessions is low down on my list
of things to do... unless, of course, someone offers to pay me to do it!

 > > For those that
 > > need multiple debugging sessions there's a note in the Emacs manual to use
 > > "gdb -fullname"
 > 
 > I recall that before gdba, this was the default; why was it changed?

It wasn't changed.  The mode that I've written is almost completely different
to what was there before.  If you only have rudimentary features, it's a lot
easier to be general.

Nick

Re: Multiple debugging sessions

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

> I can understand that it's not as ideal as working with one instance.  Could
> you please explain, in practical terms, what makes it "very inconvenient".

IMO, the improvents you have added to gdb support in emacs 22.x by far
outweights this "minor inconvenience".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Multiple debugging sessions

[Miles Bader]

2005/11/10, Kim F. Storm <storm@cua.dk>:
> > I can understand that it's not as ideal as working with one instance.  Could
> > you please explain, in practical terms, what makes it "very inconvenient".
>
> IMO, the improvents you have added to gdb support in emacs 22.x by far
> outweights this "minor inconvenience".

wtf does that have to do with it?  Are they somehow mutually exclusive?

-miles

--
Do not taunt Happy Fun Ball.

Re: Multiple debugging sessions

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> 2005/11/10, Kim F. Storm <storm@cua.dk>:
>> > I can understand that it's not as ideal as working with one instance.  Could
>> > you please explain, in practical terms, what makes it "very inconvenient".
>>
>> IMO, the improvents you have added to gdb support in emacs 22.x by far
>> outweights this "minor inconvenience".
>
> wtf does that have to do with it?  Are they somehow mutually exclusive?

In practice, yes.

IMO, it is _good_ that Nick focussed on (vastly) improving debugging
capabilities for one program, rather than spending his valuable time
on that "minor inconvenience" (for which there is a trivial work-around).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Multiple debugging sessions

[Miles Bader]

2005/11/10, Kim F. Storm <storm@cua.dk>:
> > wtf does that have to do with it?  Are they somehow mutually exclusive?
>
> In practice, yes.

Why?

> IMO, it is _good_ that Nick focussed on (vastly) improving debugging
> capabilities for one program, rather than spending his valuable time
> on that "minor inconvenience" (for which there is a trivial work-around).

You make the (dubious, as far as I can tell) assumption that it was a
conscious tradeoff rather than a simple lack of awareness of the
issue.

These things happen, and we have to deal with them, but we should try
to do better in the future.

-Miles
--
Do not taunt Happy Fun Ball.

Re: Multiple debugging sessions [was Re: `overlay-arrow-position' should be automatically buffer-local]

[Miles Bader]

2005/11/10, Nick Roberts <nickrob@snap.net.nz>:
> I can understand that it's not as ideal as working with one instance.  Could
> you please explain, in practical terms, what makes it "very inconvenient".

Because having multiple emacs instances is almost always a horrible
nuisance -- you get multiple instances of open files etc (even worse
is multiple gnus sessions -- I've done this a few times!).  One of the
biggest benefits of Emacs is having a shared global workspace.

[Do I really need to say this?!?]

> I'm
> afraid that managing multiple debugging sessions is low down on my list
> of things to do...

Retrofitting such a feature is probably a lot harder than simply being
a bit careful to keep things well-parameterized from the beginning
(well i guess it's too late now, but ...).

If you plan to make large scale change anyway, simply being aware of
the issue may go a long way towards avoiding such problems in the
rewritten code.

-miles
--
Do not taunt Happy Fun Ball.

Re: Multiple debugging sessions

[Stefan Monnier]

>> I'm afraid that managing multiple debugging sessions is low down on my
>> list of things to do...

> Retrofitting such a feature is probably a lot harder than simply being
> a bit careful to keep things well-parameterized from the beginning
> (well i guess it's too late now, but ...).

The main problem (based on my experience making it possible to have multiple
PCL-CVS buffers) is that you need both to understand the code you're
changing and to understand how to use buffer-local variables to their best
advantage.

In the end the change to PCL-CVS was "fairly" easy, but it was delicate.


        Stefan

Re: Multiple debugging sessions

[Nick Roberts]

 > > Retrofitting such a feature is probably a lot harder than simply being
 > > a bit careful to keep things well-parameterized from the beginning
 > > (well i guess it's too late now, but ...).
 > 
 > The main problem (based on my experience making it possible to have multiple
 > PCL-CVS buffers) is that you need both to understand the code you're
 > changing and to understand how to use buffer-local variables to their best
 > advantage.

I've only just started using pcl-cvs, but doesn't it just use one buffer?  A
debugging session with gdb can comprise many buffers: stack, locals,
breakpoints etc.  There is only one GUD buffer per session, so maybe variables
could be local to that and some sort of indirection used, but it would be
more complicated.

 > In the end the change to PCL-CVS was "fairly" easy, but it was delicate.

What might be "fairly" easy to you, I might find a bit more difficult ;-)

Nick

Re: Multiple debugging sessions

[Stefan Monnier]

>> > Retrofitting such a feature is probably a lot harder than simply being
>> > a bit careful to keep things well-parameterized from the beginning
>> > (well i guess it's too late now, but ...).
>> 
>> The main problem (based on my experience making it possible to have multiple
>> PCL-CVS buffers) is that you need both to understand the code you're
>> changing and to understand how to use buffer-local variables to their best
>> advantage.

> I've only just started using pcl-cvs, but doesn't it just use one buffer?  A
> debugging session with gdb can comprise many buffers: stack, locals,
> breakpoints etc.

I'm not claiming PCL-CVS is as complex as gdba.  But yes, PCL-CVS uses more
than one buffer: one *cvs* buffer for the display, a *cvs-tmp* for the
output of the process (not shown to the user), then some others like
*cvs-info* to show cvs log or cvs status output (the cvs status output is
also parsed, just like the *cvs-tmp* output), ...

> There is only one GUD buffer per session, so maybe variables
> could be local to that and some sort of indirection used, but it would be
> more complicated.

That's whay I do it in PCL-CVS: each one of those buffers has a buffer-local
variable `cvs-buffer' which points to the *cvs* buffer where all the
relevant info is kept.  So a process can find the corresponding info by
checking its buffer's `cvs-buffer' variable, and then looking up the info in
that buffer.

It requires a bit of discipline, but really nothing too terrible.
It actually all becomes fairly intuitive when you start thinking in terms of
the most general/scary case rather than in terms of the "normal" case.


        Stefan

Re: Multiple debugging sessions

[Nick Roberts]

Miles Bader writes:
 > 2005/11/10, Nick Roberts <nickrob@snap.net.nz>:
 > > I can understand that it's not as ideal as working with one instance.
 > > Could you please explain, in practical terms, what makes it "very
 > > inconvenient".
 >
 > Because having multiple emacs instances is almost always a horrible
 > nuisance -- you get multiple instances of open files etc (even worse
 > is multiple gnus sessions -- I've done this a few times!).  One of the
 > biggest benefits of Emacs is having a shared global workspace.
 > 
 > [Do I really need to say this?!?]

I'm impressed that you can debug multiple programs and read gnus all at the
same time.  You could open the files and read gnus in just one instance,
changing the background colour, for example, so that you can distinguish
between the two.

By practical, I really meant something more concrete and unavoidable.

 > > I'm
 > > afraid that managing multiple debugging sessions is low down on my list
 > > of things to do...
 > 
 > Retrofitting such a feature is probably a lot harder than simply being
 > a bit careful to keep things well-parameterized from the beginning
 > (well i guess it's too late now, but ...).

I've already said that I'm not planning to retrofit such a feature but
keep the code simple by not having it.  Of course, if many users share
your view after the release, I will reconsider.

 > If you plan to make large scale change anyway, simply being aware of
 > the issue may go a long way towards avoiding such problems in the
 > rewritten code.

I was aware of the issue. The file gdba.el, which I used as my starting point,
used many buffer local variables, presumably to allow multiple sessions.  It
didn't work, so I made them global.

Nick

Re: Multiple debugging sessions

[Andreas Schwab]

Nick Roberts <nickrob@snap.net.nz> writes:

> I've already said that I'm not planning to retrofit such a feature but
> keep the code simple by not having it.  Of course, if many users share
> your view after the release, I will reconsider.

Being able to debug two programs in parallel is a very important feature.
I do miss it, too.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multiple debugging sessions

[Richard M. Stallman]

It seems I was mistaken in thinking that Nick recognized that
debugging multiple programs in one Emacs was a desirable goal.

I agree that this should be a goal, for after the Emacs 22 release.

Re: Multiple debugging sessions

[Nick Roberts]

Richard M. Stallman writes:
 > It seems I was mistaken in thinking that Nick recognized that
 > debugging multiple programs in one Emacs was a desirable goal.

I've not said that it's not desirable, but that its not a trivial task and I
think there are more immediate and important goals.  Moving over to GDB/MI
aligns us with GDB development and will make a much more reliable interface.
Since gdb-ui.el uses annotations, it hangs together on a wing and a prayer,
and every time GDB developers change CLI output, which they have every right
to do as its intended for the user and not the front end, it may break.

 > I agree that this should be a goal, for after the Emacs 22 release.

Moving over to GDB/MI will change the lisp code considerably, so if someone
wants to do that twice: once for gdb-ui.el and once for the new code, thats
fine.

Nick

Re: Multiple debugging sessions

[Miles Bader]

2005/11/12, Nick Roberts <nickrob@snap.net.nz>:
> Moving over to GDB/MI will change the lisp code considerably, so if someone
> wants to do that twice: once for gdb-ui.el and once for the new code, thats
> fine.

It would certainly help a lot if the rewrite for GDB/MI at least is a
bit more careful about such issues -- not necessarily implementing
multiple sessions, but taking some time to carefully design data
structures to avoid using global state where possible, so that adding
the feature later doesn't require so much work.  A little foresight
goes a long way.

-Miles
--
Do not taunt Happy Fun Ball.

Re: Multiple debugging sessions

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 12 Nov 2005 17:56:44 +1300
> Cc: miles@gnu.org, Andreas Schwab <schwab@suse.de>, snogglethorpe@gmail.com,
> 	emacs-devel@gnu.org
> 
> I've not said that it's not desirable, but that its not a trivial task and I
> think there are more immediate and important goals.  Moving over to GDB/MI
> aligns us with GDB development and will make a much more reliable interface.
> Since gdb-ui.el uses annotations, it hangs together on a wing and a prayer,
> and every time GDB developers change CLI output, which they have every right
> to do as its intended for the user and not the front end, it may break.

I agree that moving to GDB/MI is much more important than adding the
ability to debug several programs.

Re: Multiple debugging sessions

[Richard M. Stallman]

    I've not said that it's not desirable, but that its not a trivial task and I
    think there are more immediate and important goals.  Moving over to GDB/MI
    aligns us with GDB development and will make a much more reliable interface.

Can preparing to support multiple debug sessions be a secondary design goal
when you switch to GDB/MI?

Re: Multiple debugging sessions

[Nick Roberts]

 >     I've not said that it's not desirable, but that its not a trivial task
 >     and I think there are more immediate and important goals.  Moving over
 >     to GDB/MI aligns us with GDB development and will make a much more
 >     reliable interface.
 > 
 > Can preparing to support multiple debug sessions be a secondary design goal
 > when you switch to GDB/MI?

This issue is becoming more than a technical one.  I will, of course, try to
work alongside the wishes of others.  Nothing much can be done until after the
release, so I suggest that we discuss it then, when hopefully a clearer
picture will emerge.

Nick

Re: Multiple debugging sessions

[Miles Bader]

2005/11/11, Nick Roberts <nickrob@snap.net.nz>:
> I'm impressed that you can debug multiple programs and read gnus all at the
> same time.  You could open the files and read gnus in just one instance,
> changing the background colour, for example, so that you can distinguish
> between the two.

That is the vi way.  It isn't the Emacs way.  Running multiple emacs
sessions is simply not an acceptable long-term workaround.

> I've already said that I'm not planning to retrofit such a feature but
> keep the code simple by not having it.  Of course, if many users share
> your view after the release, I will reconsider.

I'll do it myself if necessary (after the release of course).

> I was aware of the issue. The file gdba.el, which I used as my starting point,
> used many buffer local variables, presumably to allow multiple sessions.  It
> didn't work, so I made them global.

Lovely.  You made it worse.

-miles
--
Do not taunt Happy Fun Ball.

Re: Multiple debugging sessions

[Miles Bader]

BTW, I should note that the behavior I'm complaining about is _not_ in
the "hard case" where there's actual ambiguity.

I'm talking about the simplest possible case, where you're debugging
two completely different programs, which have no common source-file
names, and you're mainly using gdb command-line functions -- relying
on gdba only for e.g. showing breakpoint icons in the fringe.

Even in this apparently easy case, there are very weird interactions
between the gdb sessions.

I understand that there might be greater difficulties in supporting a
truly complicated scenario -- e.g. debugging the _same_ program
multiple times simultaneously (or, due to the way gdb works, different
programs with common source-file names), because there is actual
ambiguity that must somehow be resolved -- but that's not what I'm
really talking about.

-Miles
--
Do not taunt Happy Fun Ball.

Re: Multiple debugging sessions

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> BTW, I should note that the behavior I'm complaining about is _not_ in
> the "hard case" where there's actual ambiguity.
>
> I'm talking about the simplest possible case, where you're debugging
> two completely different programs, which have no common source-file
> names, and you're mainly using gdb command-line functions -- relying
> on gdba only for e.g. showing breakpoint icons in the fringe.
>
> Even in this apparently easy case, there are very weird interactions
> between the gdb sessions.
>
> I understand that there might be greater difficulties in supporting a
> truly complicated scenario -- e.g. debugging the _same_ program
> multiple times simultaneously (or, due to the way gdb works, different
> programs with common source-file names), because there is actual
> ambiguity that must somehow be resolved -- but that's not what I'm
> really talking about.

If we want to fix this, the solution should definitely allow
debugging the _same_ program or programs sharing the same
source files.

Consider the common case of a client-server system which will often
share some low-level communication modules; we should be able to
debug that in one emacs session too.


It occurred to me that things might be quite simple if each source
buffer had a local variable (gud-*gud*-buffer) pointing back to the
corresponding *gud* buffer.

Then each *gud* buffer would have all the current global variables as
buffer local variables, and every gud function had a call to a function
which did something like:

(unless (eq current-gud-*gud*-buffer gud-*gud*-buffer)
  (with-current-buffer gud-*gud*-buffer
    (for "each global gud variable" do
      (set global-gud-variable buffer-local-value)))
  (setq current-gud-*gud*-buffer gud-*gud*-buffer))

[alternatively, accessing the global gud variables would
simply be wrapped in
  (with-current-buffer current-gud-*gud*-buffer
     some-gud-variable)]

Now, to handle the case of source buffers shared between multiple
debugging sessions, the above scheme must be slightly tweaked to
NOT do the above for such buffer, but rather just use the current
defaults, as it will then simply correspond to the currently
active gud session.

The final thing that must be fixed is to fix visual stuff when
switching between which gud session is active (such as clearing
and showing breakpoint icons, updating the "stack" window, etc.)

In fact, each session should still have all the "stack" buffers, and
switching projects should simply show the right set of buffers in the
gud windows.

About the breakpoint icons, you could make the display depend on
whether the corresponding gud project is active, i.e. use a 'when
clause on the display property which make the display of the fringe
bitmap selective on current-gud-*gud*-buffer matching a specific *gud*
buffer.

Does any of this make sense?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Multiple debugging sessions

[Juri Linkov]

> Now, to handle the case of source buffers shared between multiple
> debugging sessions, the above scheme must be slightly tweaked to
> NOT do the above for such buffer, but rather just use the current
> defaults, as it will then simply correspond to the currently
> active gud session.

Finding an appropriate *gud* buffer could use heuristics similar
to the rules used by `next-error' to find the *compilation* or *grep*
buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Multiple debugging sessions

[Nick Roberts]

 > > I've already said that I'm not planning to retrofit such a feature but
 > > keep the code simple by not having it.  Of course, if many users share
 > > your view after the release, I will reconsider.
 > 
 > I'll do it myself if necessary (after the release of course).

What is perhaps more important than supporting multiple sessions, is
confidence that the debugger is not going to crash on you while you are
debugging.  In the past, gdba has certainly failed on that count, and
discussions on this list have shown that people don't take too kindly to it.

If you can demonstrate a mode that has the same level of reliability and
supports multiple sessions, that will certainly be a welcome addition.

 > > I was aware of the issue. The file gdba.el, which I used as my starting
 > > point, used many buffer local variables, presumably to allow multiple
 > > sessions.  It didn't work, so I made them global.
 > 
 > Lovely.  You made it worse.

There is a bit more to allowing multiple sessions than creating a few buffer
local variables, as I'm sure you'll find out.

Nick

Re: Multiple debugging sessions

[Stefan Monnier]

> What is perhaps more important than supporting multiple sessions, is
> confidence that the debugger is not going to crash on you while you are
> debugging.  In the past, gdba has certainly failed on that count, and
> discussions on this list have shown that people don't take too kindly
> to it.

Agreed.  Reliability is a more serious issue.  I still often use --fullname
when I'm debugging something where I don't want to have to do it all over
again in case GDB/GUD messes up.


        Stefan

Re: Multiple debugging sessions

[Richard M. Stallman]

Everyone, could we please stop this argument?  It is not constructive.
Nick already knows it would be desirable to support multiple GDB
processes in one Emacs process.  Now is the wrong time for such a
rewrite.  There is nothing here to discuss.

Re: Multiple debugging sessions

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Fri, 11 Nov 2005 02:41:01 -0500
> Cc: snogglethorpe@gmail.com, emacs-devel@gnu.org, miles@gnu.org
> 
> Everyone, could we please stop this argument?  It is not constructive.
> Nick already knows it would be desirable to support multiple GDB
> processes in one Emacs process.  Now is the wrong time for such a
> rewrite.  There is nothing here to discuss.

Indeed.  And on top of that, the attitude is extremely unkind to Nick.
I think Nick did a very good job[1] by introducing a feature that was
awaiting a volunteer for years (and continually contributes to GDB on
related issues).

In any case, bashing a volunteer for donating useful code is a bad
mantra; if someone thinks the code isn't good enough, they are free to
do better.

[1] I know people with a generally anti-Emacs orientation who, after
being shown "M-x gdba", told me that this single feature might
convince them to start using Emacs.

Re: Multiple debugging sessions

[Richard M. Stallman]

    Indeed.  And on top of that, the attitude is extremely unkind to Nick.
    I think Nick did a very good job[1] by introducing a feature that was
    awaiting a volunteer for years (and continually contributes to GDB on
    related issues).

Hear, hear!

Re: Multiple debugging sessions

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

> I was aware of the issue. The file gdba.el, which I used as my starting point,
> used many buffer local variables, presumably to allow multiple sessions.  It
> didn't work, so I made them global.

Indeed, buffer-local-variables (in source buffers) typically don't
help if the same file/buffer is shared between multiple debugging
sessions.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Multiple debugging sessions

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Nick Roberts <nickrob@snap.net.nz> writes:
>
>> I was aware of the issue. The file gdba.el, which I used as my
>> starting point, used many buffer local variables, presumably to
>> allow multiple sessions.  It didn't work, so I made them global.
>
> Indeed, buffer-local-variables (in source buffers) typically don't
> help if the same file/buffer is shared between multiple debugging
> sessions.

The way to do that would be to have the source buffers contain a
buffer-local variable pointing to the current debugger buffer, and
maintain all important state in buffer-local variables there.

This does not cater for multiple gdb sessions, but you can do this
somehat like that even in the most complicated cases:

(defmacro with-current-gdb-buffer (&rest form)
  `(progn (while (and gdb-session-buffers
                      (null (buffer-name (car gdb-session-buffers))))
             (pop gdb-session-buffers))
          (unless gdb-session-buffers
             (error "No GDB session active"))
          (with-current-buffer (car gdb-session-buffers) ,@form)))

You would then get and set variables wrapped with
with-current-gdb-buffer in order to fetch the buffer-local settings
from the session.

The above loop and check may be unnecessary if gdb-session-buffers is
normally maintained by the proper buffer deletion hooks in the gdb
buffers.  There would be commands to change the "current gdb session"
in a source file if there were more than one around.  I don't think
that they would often be needed.  An active gdb session would push its
position in the gdb-session-buffers variable of an accessed buffer to
the front.

This would almost always do the right thing and have manual override
where really necessary.

Having a list instead of a single variable actually is only necessary
so that after stepping through one file with one debugger, the
association with the previous debugger is restored.  It would be
tolerable, I think, if instead the association was completely broken
and would have to be reestablished manually (by pressing RET in the
appropriate GDB session buffer or executing a special "select gdb
session" command): that way, the user might not get surprised by
unexpected debug session leftovers suddenly being in control.

In that case, the above macro just becomes

(defmacro with-current-gdb-buffer (&rest forms)
  `(progn
     (unless (and gdb-session-buffer (buffer-name gdb-session-buffer))
        (error "No current gdb session"))
     (with-current-buffer gdb-session-buffer ,@forms)))

In fact, this second approach seems programmatically simpler.  A debug
session leaving a buffer would set its gdb-session-buffer variable to
nil.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum