[PATCH] left-fringe for speedbar

[PATCH] left-fringe for speedbar

[Nick Roberts]

In gud.el I've made visibility of some tool bar buttons e.g the unintuitive
break and clear buttons, conditional on the fringe (these operations can be
done in the fringe, if present).  Unfortunately window-fringes uses the
selected window and not the one that determines the tool-bar, when multiple
frames are used:

    ([break]	menu-item "Set Breakpoint" gud-break
                  :enable (not gud-running)
		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
                      (> (car (window-fringes 0))))))

This means that the extra buttons appear every time the speedbar is selected.

The speedbar is a key part of gdba for watch expressions so I'd like to put
the left-fringe back.  Are there any objections?

Nick



*** speedbar.el	16 Oct 2005 19:01:20 +1300	1.73
--- speedbar.el	13 Nov 2005 10:59:21 +1300	
***************
*** 270,276 ****
  				       (menu-bar-lines . 0)
  				       (tool-bar-lines . 0)
  				       (unsplittable . t)
- 				       (left-fringe . 0)
  				       )
    "*Parameters to use when creating the speedbar frame in Emacs.
  Any parameter supported by a frame may be added.  The parameter `height'

RE: [PATCH] left-fringe for speedbar

[Drew Adams]

    The speedbar is a key part of gdba for watch expressions so I'd
    like to put the left-fringe back.  Are there any objections?

I have not been following this thread, so forgive me if I misunderstand.

If you are suggesting to impose fringe display on speedbar users, then I am
against that. User preferences should be respected. I don't want to see
fringe, and I don't want to jump through hoops to get rid of it. Then again,
I don't use gdba (haven't so far), so maybe you can ignore this. I do use
speedbar, however.

RE: [PATCH] left-fringe for speedbar

[Nick Roberts]

Drew Adams writes:
 >     The speedbar is a key part of gdba for watch expressions so I'd
 >     like to put the left-fringe back.  Are there any objections?
 > 
 > I have not been following this thread, so forgive me if I misunderstand.
 > 
 > If you are suggesting to impose fringe display on speedbar users, then I am
 > against that. User preferences should be respected.

I'm proposing to change a default setting, not to interfere with user
preferences.  The usual default for frames is a fringe on each side.  This
allows the indication of line truncation and continuation lines.

 > I don't want to see fringe, and I don't want to jump through hoops to get
 > rid of it. 

Previously the speedbar did have a left fringe.  I don't know why it was
removed because there's no ChangeLog entry.  Perhaps you can say what
the advantage is (apart from saving one character width which would be
an argument against the fringe, in general, not just for the speedbar.

 > Then again, I don't use gdba (haven't so far), so maybe you can ignore
 > this. I do use speedbar, however.

Then you won't see much benefit, but you won't lose much either.

Nick

Re: [PATCH] left-fringe for speedbar

[Miles Bader]

2005/11/13, Nick Roberts <nickrob@snap.net.nz>:
> I'm proposing to change a default setting, not to interfere with user
> preferences.  The usual default for frames is a fringe on each side.  This
> allows the indication of line truncation and continuation lines.

Typically speedbar frames are much, much narrower than normal frames,
and are far more impacted by a fringe.

I guess a right-fringe-only would be OK.

-Miles
--
Do not taunt Happy Fun Ball.

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 >     ([break]	menu-item "Set Breakpoint" gud-break
 >                   :enable (not gud-running)
 > 		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
 >                       (> (car (window-fringes 0))))))

That should read:

    ([break]	menu-item "Set Breakpoint" gud-break
                  :enable (not gud-running)
		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
                      (> (car (window-fringes)) 0))))

Nick

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

Miles Bader writes:
 > 2005/11/13, Nick Roberts <nickrob@snap.net.nz>:
 > > I'm proposing to change a default setting, not to interfere with user
 > > preferences.  The usual default for frames is a fringe on each side.  This
 > > allows the indication of line truncation and continuation lines.
 > 
 > Typically speedbar frames are much, much narrower than normal frames,
 > and are far more impacted by a fringe.
 > 
 > I guess a right-fringe-only would be OK.

I'm not sure what you're saying.  Currently the speedbar does only have the
right-fringe.  I'm asking to put the left fringe back.

Nick

RE: [PATCH] left-fringe for speedbar

[Drew Adams]

    Previously the speedbar did have a left fringe.  I don't know why it was
    removed because there's no ChangeLog entry.

I don't know why any change was made.

The behavior should not override a user's setting - that's my only concern.

I express the concern because I know that at one point merely loading
fringe.el (which happened just by clicking a navigational button in
Customize!) overrode user settings in `default-frame-alist'. That bug was
fixed, but I would not want to see other libraries (e.g. speedbar) put back
the fringe a user might have tried to prevent.

And it seems that there are some lingering problems with the fringe-mode
mechanism to keep in mind. From Richard's email of 2004-10-17:

      I made a fix that prevents loading of fringe.el from overriding
      any explicit settings of fringe properties in default-frame-alist.
      Instead detects that the properties have been specified there,
      and updates the value of fringe-mode to match them.

      This is not totally clean.  fringe-mode really ought, I think,
      to apply only to frames in which nothing else has been done
      to individually set their properties.  However, there is no
      existing mechanism which is natural for that, and I don't
      think this is worth the trouble to implement one.

      If other such problems are encountered, a variant of this approach
      should do the job.

    Perhaps you can say what
    the advantage is (apart from saving one character width which would be
    an argument against the fringe, in general, not just for the speedbar.

I have no argument to change the default setting - for the speedbar or in
general. I just want to be able, as a user, to set it as I please (in my
case, turn off fringe).

Re: [PATCH] left-fringe for speedbar

[Miles Bader]

2005/11/13, Nick Roberts <nickrob@snap.net.nz>:
> I'm not sure what you're saying.  Currently the speedbar does only have the
> right-fringe.  I'm asking to put the left fringe back.

I guess I'm saying it sounds dubious.

Anway, the reason you want to add the left fringe is to work around a
bug, not actually because you need the left fringe in speedbars; maybe
it's possible fix the bug instead.

-Miles
--
Do not taunt Happy Fun Ball.

RE: [PATCH] left-fringe for speedbar

[Nick Roberts]

Drew Adams writes:
 >     Previously the speedbar did have a left fringe.  I don't know why it was
 >     removed because there's no ChangeLog entry.
 > 
 > I don't know why any change was made.
 > 
 > The behavior should not override a user's setting - that's my only concern.
 > 
 > I express the concern because I know that at one point merely loading
 > fringe.el...

That's a red herring, at best, speedbar doesn't even load fringe.el.

Nick

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 > > I'm not sure what you're saying.  Currently the speedbar does only have the
 > > right-fringe.  I'm asking to put the left fringe back.
 > 
 > I guess I'm saying it sounds dubious.
 > 
 > Anway, the reason you want to add the left fringe is to work around a
 > bug, not actually because you need the left fringe in speedbars; maybe
 > it's possible fix the bug instead.

I imagine users want fringes or they don't.  I've declared my self-interest,
but I'm also saying that a state of limbo, where frames have differing numbers
of fringes by default, is probably not desirable anyway.

Nick

Re: [PATCH] left-fringe for speedbar

[Miles Bader]

2005/11/13, Nick Roberts <nickrob@snap.net.nz>:
> I imagine users want fringes or they don't.  I've declared my self-interest,
> but I'm also saying that a state of limbo, where frames have differing numbers
> of fringes by default, is probably not desirable anyway.

I think that's wrong; in some cases very different uses call for
different defaults.

-miles
--
Do not taunt Happy Fun Ball.

Re: [PATCH] left-fringe for speedbar

[Kim F. Storm]

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

>  >     ([break]	menu-item "Set Breakpoint" gud-break
>  >                   :enable (not gud-running)
>  > 		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
>  >                       (> (car (window-fringes 0))))))
>
> That should read:
>
>     ([break]	menu-item "Set Breakpoint" gud-break
>                   :enable (not gud-running)
> 		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
>                       (> (car (window-fringes)) 0))))
>

Would it work to test explicitly for speedbar mode?

([break]	menu-item "Set Breakpoint" gud-break
                :enable (not gud-running)
                :visible (not (or (eq major-mode 'speedbar-mode) 
				  (and (memq gud-minor-mode '(gdbmi gdba))
				       (> (car (window-fringes)) 0)))))


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

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 > Would it work to test explicitly for speedbar mode?
 > 
 > ([break]	menu-item "Set Breakpoint" gud-break
 >                 :enable (not gud-running)
 >                 :visible (not (or (eq major-mode 'speedbar-mode) 
 > 				  (and (memq gud-minor-mode '(gdbmi gdba))
 > 				       (> (car (window-fringes)) 0)))))

No I don't think so.  When there is more than one frame the tool-bar of the
frame without focus is not determined by the buffer local values of the
selected window but by those of the window that becomes selected if that frame
is given focus (the function frame-selected-window hints at this concept as
it can have frame as an argument).

Try this: 

1) Put the GUD buffer in full frame (with fringes).
2) Do C-x 5 2 to generate an identical frame.
3) M-x set-fringe-style RET none so that one frame has no fringes.
4) Click alternately on each frame.
5) The extra icons disappear and appear _simultaneously_ on both frames
   depending on whether the fringes are present on the frame with focus or not.

Ideally the extra icons should be present in the frame with fringes and not
in the frame without them.

Nick

Re: [PATCH] left-fringe for speedbar

[Kim F. Storm]

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

>  > Would it work to test explicitly for speedbar mode?
>  > 
>  > ([break]	menu-item "Set Breakpoint" gud-break
>  >                 :enable (not gud-running)
>  >                 :visible (not (or (eq major-mode 'speedbar-mode) 
>  > 				  (and (memq gud-minor-mode '(gdbmi gdba))
>  > 				       (> (car (window-fringes)) 0)))))
>
> No I don't think so.  When there is more than one frame the tool-bar of the
> frame without focus is not determined by the buffer local values of the
> selected window but by those of the window that becomes selected if that frame
> is given focus (the function frame-selected-window hints at this concept as
> it can have frame as an argument).
>
> Try this: 
>
> 1) Put the GUD buffer in full frame (with fringes).
> 2) Do C-x 5 2 to generate an identical frame.
> 3) M-x set-fringe-style RET none so that one frame has no fringes.
> 4) Click alternately on each frame.
> 5) The extra icons disappear and appear _simultaneously_ on both frames
>    depending on whether the fringes are present on the frame with focus or not.
>
> Ideally the extra icons should be present in the frame with fringes and not
> in the frame without them.

The problem seems to be that update_tool_bar only sets the current buffer
to the buffer of the selected window of the frame being updated, but
keeps the selected window (and selected frame) unchanged, so any functions
used by the tool-bar menu-items will refer to the wrong info.

We could fix this (by changing frame/window temporarily while updating
the tool bar [and menu bar?], or we could make new variables
tool-bar-updating-frame and tool-bar-updating-window which are
exported from C to Lisp to be used explicitly in such cases where a
tool-bar item should reflect the hosting frame/window rather than the
selected frame/window.

WDYT?

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

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 > The problem seems to be that update_tool_bar only sets the current buffer
 > to the buffer of the selected window of the frame being updated, but
 > keeps the selected window (and selected frame) unchanged, so any functions
 > used by the tool-bar menu-items will refer to the wrong info.
 > 
 > We could fix this (by changing frame/window temporarily while updating
 > the tool bar [and menu bar?], or we could make new variables
 > tool-bar-updating-frame and tool-bar-updating-window which are
 > exported from C to Lisp to be used explicitly in such cases where a
 > tool-bar item should reflect the hosting frame/window rather than the
 > selected frame/window.
 > 
 > WDYT?

I think that the former would be best.  I don't see any need to configure the
behaviour with lisp variables.  By "we" I hope you mean you, as I haven't
got a clue about how to do it!

Nick

Re: [PATCH] left-fringe for speedbar

[Richard M. Stallman]

Why is it so important whether the speedbar has a left fringe?

Re: [PATCH] left-fringe for speedbar

[Kim F. Storm]

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

>  > The problem seems to be that update_tool_bar only sets the current buffer
>  > to the buffer of the selected window of the frame being updated, but
>  > keeps the selected window (and selected frame) unchanged, so any functions
>  > used by the tool-bar menu-items will refer to the wrong info.
>  > 
>  > We could fix this (by changing frame/window temporarily while updating
>  > the tool bar [and menu bar?], or we could make new variables
>  > tool-bar-updating-frame and tool-bar-updating-window which are
>  > exported from C to Lisp to be used explicitly in such cases where a
>  > tool-bar item should reflect the hosting frame/window rather than the
>  > selected frame/window.
>  > 
>  > WDYT?
>
> I think that the former would be best.  I don't see any need to configure the
> behaviour with lisp variables.  By "we" I hope you mean you, as I haven't
> got a clue about how to do it!

Problem is that I don't know what other code may be broken by this
change.

In any case, why not just always show the STOP/GO/UNTIL icons, even
when there is a fringe.  They don't harm -- and for the novice, they
are less cryptic than clicking on the fringe.

BTW, I still totally dislike the current STOP/GO icons -- they don't
stop or go, they set or clears a breakpoint.  As such "stop" should
show a (solid) red circle, and the "go" should be the same circle with
a big X over it.

WDYT?

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

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 > >  > We could fix this (by changing frame/window temporarily while updating
 > >  > the tool bar [and menu bar?], or we could make new variables
 > >  > tool-bar-updating-frame and tool-bar-updating-window which are
 > >  > exported from C to Lisp to be used explicitly in such cases where a
 > >  > tool-bar item should reflect the hosting frame/window rather than the
 > >  > selected frame/window.
 > >  > 
 > >  > WDYT?
 > >
 > > I think that the former would be best.  I don't see any need to configure the
 > > behaviour with lisp variables.  By "we" I hope you mean you, as I haven't
 > > got a clue about how to do it!
 > 
 > Problem is that I don't know what other code may be broken by this
 > change.

Its an unusual requirement, so its probably best to leave things as they
are, certainly till after the release.

 > In any case, why not just always show the STOP/GO/UNTIL icons, even
 > when there is a fringe.  They don't harm -- and for the novice, they
 > are less cryptic than clicking on the fringe.

One reason is because they are un-intuitive, as you say below.  Using on the
fringe only requires one click.  Also, why have them when they are not needed?
It leaves more room for other buttons.

 > BTW, I still totally dislike the current STOP/GO icons -- they don't
 > stop or go, they set or clears a breakpoint.  As such "stop" should
 > show a (solid) red circle, and the "go" should be the same circle with
 > a big X over it.

Richard tried to find a graphic designer a few years back.  There were one or
two attempts to improve the icons, but people on the list, including myself,
didn't really like the results.

Nick

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 > Why is it so important whether the speedbar has a left fringe?

In an earlier post, I said:

Me> In gud.el I've made visibility of some tool bar buttons e.g the
Me> unintuitive break and clear buttons, conditional on the fringe (these
Me> operations can be done in the fringe, if present).  Unfortunately
Me> window-fringes uses the selected window and not the one that determines
Me> the tool-bar, when multiple frames are used.

Me> This means that the extra buttons appear every time the speedbar is
Me> selected.

Although this is probably due to a bug in Emacs, Kim has said it would be
difficult to fix.  Its an unusual requirement, so it probably not worth
risking breaking something else to fix it now.

So, I would still like to put the left fringe back.  No-one complained about
it being there for the last four years and it makes things more consistent.
However, these issues become larger than they really should.  I think it as an
insignificant change to the general user.

Nick

Re: [PATCH] left-fringe for speedbar

[Kim F. Storm]

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

> So, I would still like to put the left fringe back.  No-one complained about
> it being there for the last four years and it makes things more consistent.
> However, these issues become larger than they really should.  I think it as an
> insignificant change to the general user.

If this problem is primarily observed with speedbar, the following patch
seems to give good results without enabling left fringe in speedbar frame:


*** gud.el	13 Nov 2005 21:04:40 +0100	1.69
--- gud.el	15 Nov 2005 00:07:12 +0100	
***************
*** 122,127 ****
--- 122,132 ----
  	(info "(emacs)GDB Graphical Interface")
        (info "(emacs)Debuggers"))))
  
+ (defun gud-tool-bar-item-visible-no-fringe ()
+   (not (or (eq (buffer-local-value 'major-mode (window-buffer)) 'speedbar-mode)
+ 	   (and (memq gud-minor-mode '(gdbmi gdba))
+ 		(> (car (window-fringes)) 0)))))
+ 
  (easy-mmode-defmap gud-menu-map
    '(([help]     "Info" . gud-goto-info)
      ([tooltips] menu-item "Toggle GUD tooltips" gud-tooltip-mode
***************
*** 136,154 ****
      ([until]	menu-item "Continue to selection" gud-until
                    :enable (and (not gud-running)
  			       (memq gud-minor-mode '(gdbmi gdba gdb perldb)))
! 		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
!                      (> (car (window-fringes)) 0))))
      ([remove]	menu-item "Remove Breakpoint" gud-remove
                    :enable (not gud-running)
! 		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
!                       (> (car (window-fringes)) 0))))
      ([tbreak]	menu-item "Temporary Breakpoint" gud-tbreak
  		  :enable (memq gud-minor-mode
  				'(gdbmi gdba gdb sdb xdb bashdb)))
      ([break]	menu-item "Set Breakpoint" gud-break
                    :enable (not gud-running)
! 		  :visible (not (and (memq gud-minor-mode '(gdbmi gdba))
!                       (> (car (window-fringes)) 0))))
      ([up]	menu-item "Up Stack" gud-up
  		  :enable (and (not gud-running)
  			       (memq gud-minor-mode
--- 141,156 ----
      ([until]	menu-item "Continue to selection" gud-until
                    :enable (and (not gud-running)
  			       (memq gud-minor-mode '(gdbmi gdba gdb perldb)))
! 		  :visible (gud-tool-bar-item-visible-no-fringe))
      ([remove]	menu-item "Remove Breakpoint" gud-remove
                    :enable (not gud-running)
! 		  :visible (gud-tool-bar-item-visible-no-fringe))
      ([tbreak]	menu-item "Temporary Breakpoint" gud-tbreak
  		  :enable (memq gud-minor-mode
  				'(gdbmi gdba gdb sdb xdb bashdb)))
      ([break]	menu-item "Set Breakpoint" gud-break
                    :enable (not gud-running)
! 		  :visible (gud-tool-bar-item-visible-no-fringe))
      ([up]	menu-item "Up Stack" gud-up
  		  :enable (and (not gud-running)
  			       (memq gud-minor-mode

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

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 > If this problem is primarily observed with speedbar, the following patch
 > seems to give good results without enabling left fringe in speedbar frame:
 > ...

Yes, that looks good.  I'll install it if the speedbar is to keep its fringe.

> BTW, I still totally dislike the current STOP/GO icons -- they don't
> stop or go, they set or clears a breakpoint.  As such "stop" should
> show a (solid) red circle, and the "go" should be the same circle with
> a big X over it.

1) Like these below?  I'm not sure that red is a good colour for clear but I
guess the X carries the idiom.  

2) I could then use the STOP icon to interrupt the inferior
(comint-inrreupt-subjob).

3) With gdba, I could also use the GO icon for both run and continue.  It
would just test if gdb-active-process is t or not to work out which command
to send.

What do people think of these options.  If they should be changed, now is the
best time to do it.

Nick


/* XPM */
static char * stop_xpm[] = {
"24 24 2 1",
" 	c None",
".	c #F8F810104040",
"                        ",
"                        ",
"         ......         ",
"      ............      ",
"     ..............     ",
"    ................    ",
"   ..................   ",
"   ..................   ",
"  ....................  ",
"  ....................  ",
" ...................... ",
" ...................... ",
" ...................... ",
" ...................... ",
"  ....................  ",
"  ....................  ",
"   ..................   ",
"   ..................   ",
"    ................    ",
"     ..............     ",
"      ............      ",
"         ......         ",
"                        ",
"                        "};


/* XPM */
static char * stop_xpm[] = {
"24 24 3 1",
" 	c None",
".	c #F8F810104040",
"X	c #F8F8FCFCF8F8",
"                        ",
"                        ",
"         ......         ",
"      ............      ",
"     ..............     ",
"    ................    ",
"   ..XX..........XX..   ",
"   ...XX........XX...   ",
"  .....XX......XX.....  ",
"  ......XX....XX......  ",
" ........XX..XX........ ",
" .........XXXX......... ",
" .........XXXX......... ",
" ........XX..XX........ ",
"  ......XX....XX......  ",
"  .....XX......XX.....  ",
"   ...XX........XX...   ",
"   ..XX..........XX..   ",
"    ................    ",
"     ..............     ",
"      ............      ",
"         ......         ",
"                        ",
"                        "};

Re: [PATCH] left-fringe for speedbar

[Kim F. Storm]

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

>  > If this problem is primarily observed with speedbar, the following patch
>  > seems to give good results without enabling left fringe in speedbar frame:
>  > ...
>
> Yes, that looks good.  I'll install it if the speedbar is to keep its fringe.
>
>> BTW, I still totally dislike the current STOP/GO icons -- they don't
>> stop or go, they set or clears a breakpoint.  As such "stop" should
>> show a (solid) red circle, and the "go" should be the same circle with
>> a big X over it.
>
> 1) Like these below?  I'm not sure that red is a good colour for clear but I
> guess the X carries the idiom.  

They are a bit dominant IMO.
See some alternatives below.


>
> 2) I could then use the STOP icon to interrupt the inferior
> (comint-inrreupt-subjob).

Indeed!! That would be the logical thing for a stop-sign to do, yes.

>
> 3) With gdba, I could also use the GO icon for both run and continue.  It
> would just test if gdb-active-process is t or not to work out which command
> to send.

That would be excellent IMO.

>
> What do people think of these options.  If they should be changed, now is the
> best time to do it.

I 100% in favour.


/* XPM */
static char * bpset_xpm[] = {
"24 24 2 1",
" 	c None",
".	c #E80B0B",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"          ....          ",
"        ........        ",
"        ........        ",
"       ..........       ",
"       ..........       ",
"       ..........       ",
"       ..........       ",
"        ........        ",
"        ........        ",
"          ....          ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        "};

/* XPM */
static char * bpclear_xpm[] = {
"24 24 3 1",
" 	c None",
".	c #000000",
"+	c #E80B0B",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"        . ++++ .        ",
"        +.++++...       ",
"        +..++....       ",
"       +++..+...+       ",
"       +++.....++       ",
"       ++++...+++       ",
"       +++.....++       ",
"        +.......        ",
"        ...++....       ",
"       ...++++....      ",
"      ...      ..       ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        ",
"                        "};


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

GUD icons [was: Re: [PATCH] left-fringe for speedbar]

[Nick Roberts]

 > > 1) Like these below?  I'm not sure that red is a good colour for clear
 > > but I guess the X carries the idiom.
 > 
 > They are a bit dominant IMO.

I've reduced their size, although they're still larger than yours.  I've
also subdued the red so that it matches the other icons more.  For the
moment, I've installed these.

 > See some alternatives below.

I don't like black on red and the cross obscures a bit too much.  I'm not sure
that I like mine either.  We can replace them later.  The main thing is that
the logic is in place.

 > > 2) I could then use the STOP icon to interrupt the inferior
 > > (comint-inrreupt-subjob).
 > 
 > Indeed!! That would be the logical thing for a stop-sign to do, yes.
 > 
 > >
 > > 3) With gdba, I could also use the GO icon for both run and continue.  It
 > > would just test if gdb-active-process is t or not to work out which command
 > > to send.
 > 
 > That would be excellent IMO.
 > 
 > >
 > > What do people think of these options.  If they should be changed, now is the
 > > best time to do it.
 > 
 > I 100% in favour.

I've done this now.  The "running man" icon is still used for all debuggers
apart from gdba.

Nick

Re: GUD icons [was: Re: [PATCH] left-fringe for speedbar]

[Kim F. Storm]

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

> I don't like black on red and the cross obscures a bit too much.  I'm not sure
> that I like mine either.  We can replace them later.  The main thing is that
> the logic is in place.

Ok.

>
>  > > 2) I could then use the STOP icon to interrupt the inferior
>  > > (comint-inrreupt-subjob).
>  > 
>  > Indeed!! That would be the logical thing for a stop-sign to do, yes.

But now it kills the process rather than stopping it.
I suggest -stop-instead of -interrupt- here:

    ([stop]	menu-item "Stop" comint-interrupt-subjob
                  :enable gud-running)


BTW, since STOP and GO can never be enabled at the same time, it might
save a little space to only make one of them visible at a time too.

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

Re: [PATCH] left-fringe for speedbar

[Richard M. Stallman]

    Me> In gud.el I've made visibility of some tool bar buttons e.g the
    Me> unintuitive break and clear buttons, conditional on the fringe (these
    Me> operations can be done in the fringe, if present).  Unfortunately
    Me> window-fringes uses the selected window and not the one that determines
    Me> the tool-bar, when multiple frames are used.

So pass the proper window as argument to window-fringes.
That should be a simple, self-contained way to fix what GUD does.

Re: GUD icons

[Nick Roberts]

 > >  > > 2) I could then use the STOP icon to interrupt the inferior
 > >  > > (comint-inrreupt-subjob).
 > >  > 
 > >  > Indeed!! That would be the logical thing for a stop-sign to do, yes.
 > 
 > But now it kills the process rather than stopping it.
 > I suggest -stop-instead of -interrupt- here:

It doesn't kill it on my computer. comint-kill-subjob and comint-quit-subjob
do that.  I think SIGINT, which is what comint-interrupt-subjob sends, is
usual.  SIGTSTP (comint-stop-subjob) needs two continue commands to restart
whereas SIGINT only needs one:

   C-c C-z
Program received signal SIGTSTP, Stopped (user).
0x005657a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) c
Continuing.

Program received signal SIGTSTP, Stopped (user).
0x005657a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) c
Continuing.  C-c C-c

Program received signal SIGINT, Interrupt.
0x005657a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) c
Continuing.

This is because SIGTSTP gets passed to the program but SIGINT doesn't:

(gdb) info sig
Signal        Stop      Print   Pass to program Description

...
SIGINT        Yes       Yes     No              Interrupt
...
SIGTSTP       Yes       Yes     Yes             Stopped (user)

The only problem with using SIGINT is that it doesn't work when debugging
Emacs.  I could make this a special case, as with gud-pp, I guess.


 >     ([stop]	menu-item "Stop" comint-interrupt-subjob
 >                   :enable gud-running)
 > 
 > 
 > BTW, since STOP and GO can never be enabled at the same time, it might
 > save a little space to only make one of them visible at a time too.

Yes, of course!  I've done that.

Nick

Re: [PATCH] left-fringe for speedbar

[Nick Roberts]

 >     Me> In gud.el I've made visibility of some tool bar buttons e.g the Me>
 >     unintuitive break and clear buttons, conditional on the fringe (these
 >     Me> operations can be done in the fringe, if present).  Unfortunately
 >     Me> window-fringes uses the selected window and not the one that
 >     determines Me> the tool-bar, when multiple frames are used.
 > 
 > So pass the proper window as argument to window-fringes.
 > That should be a simple, self-contained way to fix what GUD does.

I don't think you can specify the window that the tool-bar is using to update.
Kim has provided a patch for the case of the speedbar.  I've applied that

Nick

Re: GUD icons

[Kim F. Storm]

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

> It doesn't kill it on my computer. comint-kill-subjob and comint-quit-subjob
> do that.  I think SIGINT, which is what comint-interrupt-subjob sends, is
> usual.  

Sorry, I checked in my change to call -stop- rather than -interrupt- without
waiting for you response.  I shouldn't have done that.  I hope you can DTRT.

However, I had only tried this with debugging emacs, so indeed C-c C-c kills
emacs -- so I'm accustomed to ALWAYS use C-c C-z (stop), as this is safer.

>         SIGTSTP (comint-stop-subjob) needs two continue commands to restart
> whereas SIGINT only needs one:

Yes, that is annoying (but I'm so used to it, that I hardly think
about it anymore).

> This is because SIGTSTP gets passed to the program but SIGINT doesn't:

I see.

> The only problem with using SIGINT is that it doesn't work when debugging
> Emacs.  

Why not?

>         I could make this a special case, as with gud-pp, I guess.

Wouldn't it be better to make emacs work with SIGINT instead?

But if SIGINT can kill emacs, it can kill other apps too (I suppose);
so for that reason SIGTSTP is safer -- but if emacs is really the only
app where this is relevant, maybe we could special-case it.

[and then Go could automatically send two c's to continue ... if stopped
by SIGTSTP].

> Yes, of course!  I've done that.

Nice!

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

Re: GUD icons

[Nick Roberts]

 > However, I had only tried this with debugging emacs, so indeed C-c C-c kills
 > emacs -- so I'm accustomed to ALWAYS use C-c C-z (stop), as this is safer.
 > 
 > >         SIGTSTP (comint-stop-subjob) needs two continue commands to restart
 > > whereas SIGINT only needs one:
 > 
 > Yes, that is annoying (but I'm so used to it, that I hardly think
 > about it anymore).

You could put this in ~/.gdbinit:

handle SIGTSTP nopass

 > > The only problem with using SIGINT is that it doesn't work when debugging
 > > Emacs.  
 > 
 > Why not?

Its explained in DEBUG:

    The src/.gdbinit file in the Emacs distribution arranges for SIGINT
    (C-g in Emacs) to be passed to Emacs and not give control back to GDB.

Actually this only seems to be necessary when Emacs is running in a
terminal.

 > >         I could make this a special case, as with gud-pp, I guess.
 > 
 > Wouldn't it be better to make emacs work with SIGINT instead?

In general, it can't, for the reason above.
 
 > But if SIGINT can kill emacs, it can kill other apps too (I suppose);
 > so for that reason SIGTSTP is safer -- but if emacs is really the only
 > app where this is relevant, maybe we could special-case it.

It would generally only be the case if the the app has its own use for SIGINT.

Nick

Re: GUD icons

[Andreas Schwab]

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

> Nick Roberts <nickrob@snap.net.nz> writes:
>
>> The only problem with using SIGINT is that it doesn't work when debugging
>> Emacs.  
>
> Why not?

See src/.gdbinit:

# Don't enter GDB when user types C-g to quit.
# This has one unfortunate effect: you can't type C-c
# at the GDB to stop Emacs, when using X.
# However, C-z works just as well in that case.
handle 2 noprint pass

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."