Display feature request: gud-overlay-arrow

Display feature request: gud-overlay-arrow

[Nick Roberts]

GUD currently points to the current line of the "selected frame" with the
gud-overlay-arrow.  This might be the innermost frame, where execution stops
which is called the "current frame", or it might be on higher in the stack
for example after the GDB command "up" or "frame N" where N > 0.

I would like to distinguish between the current frame and any other frame
by making keeping the gud-overlay-arrow solid when the selected frame is
the current frame and making it hollow (or different in some other way)
otherwise i.e make its appearance depend on a variable's value.

Is this possible?  Could it be a TODO item for the next release?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Display feature request: gud-overlay-arrow

[Kim F. Storm]

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

> GUD currently points to the current line of the "selected frame" with the
> gud-overlay-arrow.  This might be the innermost frame, where execution stops
> which is called the "current frame", or it might be on higher in the stack
> for example after the GDB command "up" or "frame N" where N > 0.
>
> I would like to distinguish between the current frame and any other frame
> by making keeping the gud-overlay-arrow solid when the selected frame is
> the current frame and making it hollow (or different in some other way)
> otherwise i.e make its appearance depend on a variable's value.
>
> Is this possible?  Could it be a TODO item for the next release?

Can't you do that via the fringe-indicator-alist variable ?

I guess it would be easier to do if we had a "post-switch-buffer-hook" that
is called (after post-command-hook) whenever a new buffer is selected
in the command loop.

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

Re: Display feature request: gud-overlay-arrow

[Nick Roberts]

 > Can't you do that via the fringe-indicator-alist variable ?

Yes.

 > I guess it would be easier to do if we had a "post-switch-buffer-hook" that
 > is called (after post-command-hook) whenever a new buffer is selected
 > in the command loop.

No, the variable fringe-indicator-alist works fine (for my purpose anyway),
I just wasn't familiar with it.

Is it OK to commit the patch below?  It includes some minor corrections
to the doco.


-- 
Nick                                           http://www.inet.net.nz/~nickrob



2006-03-21  Nick Roberts  <nickrob@snap.net.nz>

	* fringe.c (short hollow_right_triangle_bits) New bitmap.
	(standard_bitmaps): Add it to the list.


2006-03-21  Nick Roberts  <nickrob@snap.net.nz>

	* fringe.el: Add hollow-right-triangle to the list of standard
	 bitmaps.

2006-03-21  Nick Roberts  <nickrob@snap.net.nz>

	* display.texi (Fringe Indicators): Add hollow-right-triangle to
	 the list of standard bitmaps. Correct typos.


*** fringe.c	16 Mar 2006 09:42:25 +1300	1.40
--- fringe.c	21 Mar 2006 15:43:44 +1200	
*************** static unsigned short left_triangle_bits
*** 242,247 ****
--- 242,261 ----
  static unsigned short right_triangle_bits[] = {
     0xc0, 0xf0, 0xf8, 0xfc, 0xfc, 0xf8, 0xf0, 0xc0};
  
+ /* Hollow triangular arrow.  */
+ /*
+   xxx.....
+   x..x....
+   x...x...
+   x....x..
+   x....x..
+   x...x...
+   x..x....
+   xxx.....
+ */
+ static unsigned short hollow_right_triangle_bits[] = {
+    0xe0, 0x90, 0x88, 0x84, 0x84, 0x88, 0x90, 0xe0};
+ 
  /* First line bitmap.  An top-left angle.  */
  /*
    xxxxxx..
*************** static unsigned short empty_line_bits[] 
*** 451,478 ****
  struct fringe_bitmap standard_bitmaps[] =
  {
    { NULL, 0, 0, 0, 0, 0 }, /* NO_FRINGE_BITMAP */
!   { FRBITS (question_mark_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (left_arrow_bits),         8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_arrow_bits),        8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (up_arrow_bits),           8, 0, ALIGN_BITMAP_TOP,    0 },
!   { FRBITS (down_arrow_bits),         8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (left_curly_arrow_bits),   8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_curly_arrow_bits),  8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (left_triangle_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_triangle_bits),     8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (top_left_angle_bits),     8, 0, ALIGN_BITMAP_TOP,    0 },
!   { FRBITS (top_right_angle_bits),    8, 0, ALIGN_BITMAP_TOP,    0 },
!   { FRBITS (bottom_left_angle_bits),  8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (bottom_right_angle_bits), 8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (left_bracket_bits),       8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_bracket_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (filled_rectangle_bits),   8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (hollow_rectangle_bits),   8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (filled_square_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (hollow_square_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (vertical_bar_bits),       8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (horizontal_bar_bits),     8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (empty_line_bits),         8, 3, ALIGN_BITMAP_TOP,    0 },
  };
  
  #define NO_FRINGE_BITMAP 0
--- 465,493 ----
  struct fringe_bitmap standard_bitmaps[] =
  {
    { NULL, 0, 0, 0, 0, 0 }, /* NO_FRINGE_BITMAP */
!   { FRBITS (question_mark_bits),         8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (left_arrow_bits),            8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_arrow_bits),           8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (up_arrow_bits),              8, 0, ALIGN_BITMAP_TOP,    0 },
!   { FRBITS (down_arrow_bits),            8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (left_curly_arrow_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_curly_arrow_bits),     8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (left_triangle_bits),         8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_triangle_bits),        8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (hollow_right_triangle_bits), 8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (top_left_angle_bits),        8, 0, ALIGN_BITMAP_TOP,    0 },
!   { FRBITS (top_right_angle_bits),       8, 0, ALIGN_BITMAP_TOP,    0 },
!   { FRBITS (bottom_left_angle_bits),     8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (bottom_right_angle_bits),    8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (left_bracket_bits),          8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (right_bracket_bits),         8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (filled_rectangle_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (hollow_rectangle_bits),      8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (filled_square_bits),         8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (hollow_square_bits),         8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (vertical_bar_bits),          8, 0, ALIGN_BITMAP_CENTER, 0 },
!   { FRBITS (horizontal_bar_bits),        8, 0, ALIGN_BITMAP_BOTTOM, 0 },
!   { FRBITS (empty_line_bits),            8, 3, ALIGN_BITMAP_TOP,    0 },
  };
  
  #define NO_FRINGE_BITMAP 0


*** fringe.el	22 Feb 2006 14:42:39 +1300	1.27
--- fringe.el	21 Mar 2006 15:34:07 +1200	
***************
*** 47,53 ****
    (let ((bitmaps '(question-mark
  		   left-arrow right-arrow up-arrow down-arrow
  		   left-curly-arrow right-curly-arrow
! 		   left-triangle right-triangle
  		   top-left-angle top-right-angle
  		   bottom-left-angle bottom-right-angle
  		   left-bracket right-bracket
--- 47,53 ----
    (let ((bitmaps '(question-mark
  		   left-arrow right-arrow up-arrow down-arrow
  		   left-curly-arrow right-curly-arrow
! 		   left-triangle right-triangle hollow-right-triangle
  		   top-left-angle top-right-angle
  		   bottom-left-angle bottom-right-angle
  		   left-bracket right-bracket


*** display.texi	17 Mar 2006 11:37:48 +1300	1.211
--- display.texi	21 Mar 2006 15:27:53 +1200	
*************** used in both left and right fringes.
*** 2876,2887 ****
  When @code{fringe-indicator-alist} has a buffer-local value, and there
  is no bitmap defined for a logical indicator, or the bitmap is
  @code{t}, the corresponding value from the (non-local)
! @code{default-fringes-indicator-alist} is used.
  
  To completely hide a specific indicator, set the bitmap to @code{nil}.
  @end defvar
  
! @defvar default-fringes-indicator-alist
  The value of this variable is the default value for
  @code{fringe-indicator-alist} in buffers that do not override it.
  @end defvar
--- 2876,2887 ----
  When @code{fringe-indicator-alist} has a buffer-local value, and there
  is no bitmap defined for a logical indicator, or the bitmap is
  @code{t}, the corresponding value from the (non-local)
! @code{default-fringe-indicator-alist} is used.
  
  To completely hide a specific indicator, set the bitmap to @code{nil}.
  @end defvar
  
! @defvar default-fringe-indicator-alist
  The value of this variable is the default value for
  @code{fringe-indicator-alist} in buffers that do not override it.
  @end defvar
*************** The value of this variable is the defaul
*** 2890,2897 ****
  @item Standard fringe bitmaps for indicators:
  @code{left-arrow}, @code{right-arrow}, @code{up-arrow}, @code{down-arrow},
  @code{left-curly-arrow}, @code{right-curly-arrow},
! @code{left-triangle}, @code{right-triangle},
! @code{top-left-angle}, @code{ top-right-angle},
  @code{bottom-left-angle}, @code{bottom-right-angle},
  @code{left-bracket}, @code{right-bracket},
  @code{filled-rectangle}, @code{hollow-rectangle},
--- 2890,2897 ----
  @item Standard fringe bitmaps for indicators:
  @code{left-arrow}, @code{right-arrow}, @code{up-arrow}, @code{down-arrow},
  @code{left-curly-arrow}, @code{right-curly-arrow},
! @code{left-triangle}, @code{right-triangle}, @code{hollow-right-triangle},
! @code{top-left-angle}, @code{top-right-angle},
  @code{bottom-left-angle}, @code{bottom-right-angle},
  @code{left-bracket}, @code{right-bracket},
  @code{filled-rectangle}, @code{hollow-rectangle},

Re: Display feature request: gud-overlay-arrow

[Kim F. Storm]

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

> No, the variable fringe-indicator-alist works fine (for my purpose anyway),

Good.

> Is it OK to commit the patch below?  

IMHO, no.   

There is no reason to define the new bitmap as "built-in".

Just use define-fringe-bitmap to define the new bitmap in your
own Lisp code.

As an alternative to the hollow triangle, you could use a filled
triangle (identical to the current bitmap), but give it is less
prominent color, e.g. medium gray.

You could call the bitmap something like "gud-inactive-arrow", and
put a face named "gud-inactive-arrow" (inherit from "fringe") on
it -- then people could customize it to their own liking.



>                                      It includes some minor corrections
> to the doco.

Please install that part of the patch.


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

Re: Display feature request: gud-overlay-arrow

[Nick Roberts]

 > There is no reason to define the new bitmap as "built-in".
 >
 > Just use define-fringe-bitmap to define the new bitmap in your
 > own Lisp code.

Yes, of course.  That's much simpler.

 > As an alternative to the hollow triangle, you could use a filled
 > triangle (identical to the current bitmap), but give it is less
 > prominent color, e.g. medium gray.
 > 
 > You could call the bitmap something like "gud-inactive-arrow", and
 > put a face named "gud-inactive-arrow" (inherit from "fringe") on
 > it -- then people could customize it to their own liking.

I don't really know how to put a face on a bitmap but I don't mind if
someone more familiar with faces wants to play around with it.

I'm more concerned that it doesn't update properly (perhaps thats what you
alluded to with "post-switch-buffer-hook", but I don't think so):

 If you have a program that calls a procedure and you set a breakpoint on that
 procedure and then enter "run", the source buffer should display correctly
 with the solid arrow.

 If you now do "up", the main routine displays, again with a solid arrow, but
 this time it should be hollow.  Dragging the mode line corrects this.

 If you now do "down", the called procedure displays, but with a hollow arrow.
 Again dragging the mode line corrects this.

It seems to me that the buffer is not being re-displayed even though I have
deleted (set to nil) and re-computed the marker gud-overlay-arrow-position.  I
think this is a display bug, and that Emacs should realise that the appearance
of this buffer has changed.  Although this might be hard to do, in practice.

I've committed my changes to gdb-ui.el so you can see what I mean.  If the
re-display in Emacs can't be changed, I will back my changes out.

 > >                                      It includes some minor corrections
 > > to the doco.
 > 
 > Please install that part of the patch.

Done.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Display feature request: gud-overlay-arrow

[Kim F. Storm]

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

> I don't really know how to put a face on a bitmap but I don't mind if
> someone more familiar with faces wants to play around with it.

set-fringe-bitmap-face

But the hollow triangle is ok for me.

> I'm more concerned that it doesn't update properly (perhaps thats what you
> alluded to with "post-switch-buffer-hook", but I don't think so):

It is a bug in fringe redisplay.  I've installed a fix.

I also fixed you use of fringe-indicator-alist to set the buffer local
value only, rather than patching the global list.  You should notice
that the buffer local value only need to contain the things which are
different from the global value.

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

Re: Display feature request: gud-overlay-arrow

[Nick Roberts]

 > > I'm more concerned that it doesn't update properly (perhaps thats what you
 > > alluded to with "post-switch-buffer-hook", but I don't think so):
 > 
 > It is a bug in fringe redisplay.  I've installed a fix.

Thanks.

 > I also fixed you use of fringe-indicator-alist to set the buffer local
 > value only, rather than patching the global list.  You should notice
 > that the buffer local value only need to contain the things which are
 > different from the global value.

OK, I see now.

It hard to see the breakpoint icon when its under the overlay arrow or the
hollow overlay arrow over the breakpoint icon because of their small size.

Does the default overlay arrow shape/breakpoint icon have to be only eight
pixels wide?  The default left fringe width is 10 for me, but perhaps that
is due to the font size I'm using (-misc-fixed-medium-r-normal--13-120...).

Its slightly easier to see both breakpoint icon and overlay arrow when the
the breakpoint icon is square.  Is there any reason for not having a square
breakpoint icon?

I also think it helps to use grey60 for the disabled face all the time.

Are there any other tricks to make the icons easier to see when they are
coincident?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Display feature request: gud-overlay-arrow

[Kim F. Storm]

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

> It hard to see the breakpoint icon when its under the overlay arrow or the
> hollow overlay arrow over the breakpoint icon because of their small size.

I don't find it hard to see (my fringes are 9 pixels wide).

> Does the default overlay arrow shape/breakpoint icon have to be only eight
> pixels wide?  

The default minimum fringe width is 8 pixels, so the default icons should not
be wider than that.

>               The default left fringe width is 10 for me, but perhaps that
> is due to the font size I'm using (-misc-fixed-medium-r-normal--13-120...).

Yes, combined fringe width (left+rigth) must be a whole multiple of
the font's nominal character width.

> Its slightly easier to see both breakpoint icon and overlay arrow when the
> the breakpoint icon is square.  Is there any reason for not having a square
> breakpoint icon?

I like a round breakpoint icon -- I think that's what people are used to.

> I also think it helps to use grey60 for the disabled face all the time.
>
> Are there any other tricks to make the icons easier to see when they are
> coincident?

I think this is a personal preference -- anybody can redefine the overlay arrow
and breakpoint icons.

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

Re: Display feature request: gud-overlay-arrow

[John S. Yates, Jr.]

On Wed, 22 Mar 2006 21:43:28 +0100, you wrote:

>I like a round breakpoint icon -- I think that's what people are used to.

Let us look beyond program debuggers to more universal icons.  Just think of every cassette player, cd player, vcr, etc for the past 2 decades.  A
pair of vertical bar is universally recognized as "pause" and a solid square as "stop".  Thus I would have no trouble adapting to a square signifying
the presence of a breakpoint, especially if it remained visually prominent when overlaid by an arrow.  And I suspect that I would not be alone.

Further, in my experience, many of the open/free software "round" breakpoint icons I have seen have been ugly blotches, leaving me with the impression
of a rather amateurish effort.  I suspect that it might be easier to create an attractive, polished, professional-looking square than a circle/bullet.

/john

Re: Display feature request: gud-overlay-arrow

[Miles Bader]

"John S. Yates, Jr." <john@yates-sheets.org> writes:
> Let us look beyond program debuggers to more universal icons.  Just
> think of every cassette player, cd player, vcr, etc for the past 2
> decades.  A pair of vertical bar is universally recognized as "pause"
> and a solid square as "stop".  Thus I would have no trouble adapting to
> a square signifying the presence of a breakpoint,

A square is obviously pretty generic; it has meaning in the above cases
because of _context_ (the presence of other more recogizable icons
around it), but would be fairly meaningless alone.

The commercial graphical debuggers I've used have all used either a red
circle or a red octagon (== stop sign).

-Miles
-- 
I'd rather be consing.

Re: Display feature request: gud-overlay-arrow

[Nick Roberts]

 > The commercial graphical debuggers I've used have all used either a red
 > circle or a red octagon (== stop sign).

ISTR Insight uses a square icon for breakpoints.  Incidentally the icon
currently used is an octagon which at 8x8 pixels looks like a circle.
I don't find it ugly, my only reservation is its appearance when the
arrow (=triangle) overlays its.  When the breakpoint is disabled (perhaps
an infrequent combination) I find the two partularly hard to resolve.

For this case of co-incidence, I've thought about changing the colour of the
arrow to that of the underlying breakpoint and omitting the breakpoint icon
altogether, but I'm sure this would be hard to do.

The only other possibility is to make the fringe (temporarily) larger.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Display feature request: gud-overlay-arrow

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> For this case of co-incidence, I've thought about changing the colour of the
> arrow to that of the underlying breakpoint and omitting the breakpoint icon
> altogether, but I'm sure this would be hard to do.

BTW, the aforemention commercial debuggers used multicolor icons so that
a mostly invisible arrow behind a octagon is much more obvious if it's
white and the octagon is red ... i guess we can't do that with fringe
icons though.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Display feature request: gud-overlay-arrow

[Nick Roberts]

 > Let us look beyond program debuggers to more universal icons.  Just think
 > of every cassette player, cd player, vcr, etc for the past 2 decades.  A
 > pair of vertical bar is universally recognized as "pause" and a solid
 > square as "stop".  Thus I would have no trouble adapting to a square
 > signifying the presence of a breakpoint, especially if it remained visually
 > prominent when overlaid by an arrow.  And I suspect that I would not be
 > alone.

On a related note, Cygnus produced two sets of toolbar icons for Insight, one
of which were based on those of a cassette player.  Maybe this is why they
used a square icon for breakpoints in the margin (although the pause icon
might equally be appropriate.

COMMAND   SYMBOL
step      play
run       skip
continue  fast forward

next      solid down arrow
nexti     hollow down arrow
stepi     hollow play arrow
finish    solid back arrow      

We decided to use some of the other set for Emacs because the cassette player
analogy didn't seem to really work and they weren't that intuitive.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Display feature request: gud-overlay-arrow

[Nick Roberts]

 > > I don't really know how to put a face on a bitmap but I don't mind if
 > > someone more familiar with faces wants to play around with it.
 > 
 > set-fringe-bitmap-face

I can't get this to work e.g

(set-fringe-bitmap-face 'breakpoint 'shadow)

returns nil and does nothing to existing or further breakpoint icons.

Can it be made to work for standard bitmaps? e.g to make the overlay arrow
(right-triangle) white (as Miles described).


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Display feature request: gud-overlay-arrow

[Kim F. Storm]

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

>  > > I don't really know how to put a face on a bitmap but I don't mind if
>  > > someone more familiar with faces wants to play around with it.
>  > 
>  > set-fringe-bitmap-face
>
> I can't get this to work e.g
>
> (set-fringe-bitmap-face 'breakpoint 'shadow)
>
> returns nil and does nothing to existing or further breakpoint icons.

That's because the code which puts the breakpoint bitmap in the
left fringe explicitly specifies the face (breakpoint-enabled
or breakpoint-disabled) for the bitmap:

	    (gdb-put-string
	     nil (1+ start)
	     `(left-fringe breakpoint
			   ,(if enabled
				'breakpoint-enabled
			      'breakpoint-disabled))

>
> Can it be made to work for standard bitmaps? e.g to make the overlay arrow
> (right-triangle) white (as Miles described).

Did you try it?

However, if you really want to do this, you should define a new
white-overlay-arrow bitmap and give it a white face -- then, when you
know overlay is above a breakpoint bitmap, you could explicitly map
overlay-arrow to white-overlay-arrow in fringe-indicator-alist.

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

Re: Display feature request: gud-overlay-arrow

[Nick Roberts]

 > That's because the code which puts the breakpoint bitmap in the
 > left fringe explicitly specifies the face (breakpoint-enabled
 > or breakpoint-disabled) for the bitmap:

OK

 > > Can it be made to work for standard bitmaps? e.g to make the overlay arrow
 > > (right-triangle) white (as Miles described).
 > 
 > Did you try it?

Well I thought I did but perhaps I had re-defined right-triangle or something
at the time.

 > However, if you really want to do this, you should define a new
 > white-overlay-arrow bitmap and give it a white face -- then, when you
 > know overlay is above a breakpoint bitmap, you could explicitly map
 > overlay-arrow to white-overlay-arrow in fringe-indicator-alist.

It seems to work better than a black arrow provided the fringes are a bit
darker (grey85 or less).  Could we make this change or are people too attached
to the status quo? (grey85 is lighter than mode-line but darker than
mode-line-inactive).


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Display feature request: gud-overlay-arrow

[Richard Stallman]

    I guess it would be easier to do if we had a "post-switch-buffer-hook" that
    is called (after post-command-hook) whenever a new buffer is selected
    in the command loop.

I really don't like the idea that Emacs could run hooks when switching
buffers.  It would make things rather uncontrollable.

Re: Display feature request: gud-overlay-arrow

[Masatake YAMATO]

>     I guess it would be easier to do if we had a "post-switch-buffer-hook" that
>     is called (after post-command-hook) whenever a new buffer is selected
>     in the command loop.
> 
> I really don't like the idea that Emacs could run hooks when switching
> buffers.  It would make things rather uncontrollable.

Why it would do? 
I think `post-switch-buffer-hook' may be quite useful.
e.g. we can give different colors for different buffers.

Masatake YAMATO

Re: Display feature request: gud-overlay-arrow

[Stefan Monnier]

>> I guess it would be easier to do if we had a "post-switch-buffer-hook" that
>> is called (after post-command-hook) whenever a new buffer is selected
>> in the command loop.
>> 
>> I really don't like the idea that Emacs could run hooks when switching
>> buffers.  It would make things rather uncontrollable.
> 
> Why it would do?
> I think `post-switch-buffer-hook' may be quite useful.
> e.g. we can give different colors for different buffers.

I don't understand how those three points of view relate to each other.
I strongly suspect that you all three talk about something very different.
Here is my guess at what's happening:

- Yamamoto wants a set-display-buffer-hook.
- Richard is afraid of the idea of set-buffer-hook.
- Kim suggested yet some other kind of hook.  I'm not sure what it's
  supposed to do and how/when/why someone would use it, based on
  his description.  All I understand is that it would be called at most
  once per command and only if "a new buffer is selected", tho it's no clear
  what might have caused this change (the command, presumably?) and whether
  he's talking about a change in (current-buffer) or in (window-buffer
  (selected-window)).


-- Stefan

Re: Display feature request: gud-overlay-arrow

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I guess it would be easier to do if we had a "post-switch-buffer-hook" that
>     is called (after post-command-hook) whenever a new buffer is selected
>     in the command loop.
>
> I really don't like the idea that Emacs could run hooks when switching
> buffers.  It would make things rather uncontrollable.

Quite the opposite, IMHO.

It cannot possibly be worse than the current abuse of the post-command-hook
to do all sorts of things that would be better done by specific hooks like:


post-switch-buffer-hook  (when last command switched buffers)
post-switch-window-hook  (when last command switched windows)
post-modify-buffer-hook  (when last command modified selected buffer)


I'm pretty sure there are modes which uses various post-command-hook 
tricks to accomplish the equivalent of these hooks.

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

Re: Display feature request: gud-overlay-arrow

[Richard Stallman]

    It cannot possibly be worse than the current abuse of the post-command-hook
    to do all sorts of things that would be better done by specific hooks like:


    post-switch-buffer-hook  (when last command switched buffers)
    post-switch-window-hook  (when last command switched windows)
    post-modify-buffer-hook  (when last command modified selected buffer)

Yes it can be worse.  With post-command-hook, things may happen while
a certain buffer is current, but switching away and back has no effect
on them.

Please consider the issue closed.

Re: Display feature request: gud-overlay-arrow

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     It cannot possibly be worse than the current abuse of the post-command-hook
>     to do all sorts of things that would be better done by specific hooks like:
>
>
>     post-switch-buffer-hook  (when last command switched buffers)
>     post-switch-window-hook  (when last command switched windows)
>     post-modify-buffer-hook  (when last command modified selected buffer)
>
> Yes it can be worse.  With post-command-hook, things may happen while
> a certain buffer is current, but switching away and back has no effect
> on them.

I think I have expressed myself unclearly.  

The above hooks should not be called on-the-fly, but be executed just
ONCE (if applicable) _after_ running post-command-hook.

It would provide a safe way for code to do special things when the _user_
switches buffers or windows or modifies a buffer.

>
> Please consider the issue closed.

Ok.

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

Re: Display feature request: gud-overlay-arrow

[Richard Stallman]

    It would provide a safe way for code to do special things when the _user_
    switches buffers or windows or modifies a buffer.

I switch buffers often while debugging, and I don't want this to cause
anything to happen which would not otherwise have happened.