Emacs mode for GDB - 2 questions

Emacs mode for GDB - 2 questions

[Nick Roberts]

I have updated the mode for Emacs, gdb.el, that I am writing. It acts as a
GUI for gdb and I have reported it previously on this mailing list. Changes 
include :

Two features adapted from gdb.el in XEmacs-21.4 :

1) A buffer to display expressions which is similar to the other buffers
(locals, breakpoints etc) i.e based on gdba.el (`gud-frame-display-buffer'
which can be found on the menu-bar under GDB-Frames)

2) A hypertext help buffer which uses the interactive help within gdb. This
feature has never been part of gdba.el, as far as I know.

and

3) Completion of gdb commands now works.

4) Numerous minor changes

It can be downloaded from http://www.nick.uklinux.net and the current version
will always be at gdbel.tgz.



In relation to this work, I have two questions :

1) I wish to use the same icon for enabled and disabled breakpoints (like
buttons on the toolbar that can be `greyed out' to show that they have been
disabled). However :

(insert-image '(image :file "/home/nick/circle.xpm" :type xpm) "breakpoint symbol")
(insert-image '(image :file "/home/nick/circle.xpm" :type xpm :algorithm "laplace") "breakpoint symbol")
(insert-image '(image :file "/home/nick/circle.xpm" :type xpm :algorithm 'laplace) "breakpoint symbol")

all give the same result. Can someone please tell me what I am doing wrong ?

2) I want to format the displayed expressions more tidily. In particular
I would like to show array slices and the header line would be a good
place to do this e.g.

------------main::a [start:end:step]---------------

Where start, end and step are in editable fields. Could emacs be given this
feature easily ? I guess a related question is does any body else see a need
for this feature ?

Nick

Re: Emacs mode for GDB - 2 questions

[Richard Stallman]

    Two features adapted from gdb.el in XEmacs-21.4 :

To "adapt a feature" could mean various things.  Did you get the code
from XEmacs, or just the idea?  Using code from XEmacs (or from
anywhere else) requires first finding out who the authors are and
second seeing if they have or will sign legal papers.  This is not
necessarily impossible but is often difficult.  If it was code that
you used, did you find out who the authors are?

Re: Emacs mode for GDB - 2 questions

[Richard Stallman]

    1) I wish to use the same icon for enabled and disabled breakpoints (like
    buttons on the toolbar that can be `greyed out' to show that they have been
    disabled). However :

For inactive menu items, we recently switched from graying them out
to using different colors, on displays which support color.

Maybe we should do this in GDB mode (and maybe also in the toolbar).
What do people think?

Re: Emacs mode for GDB - 2 questions

[Richard Stallman]

    2) I want to format the displayed expressions more tidily. In particular
    I would like to show array slices and the header line would be a good
    place to do this e.g.

    ------------main::a [start:end:step]---------------

    Where start, end and step are in editable fields. Could emacs be given this
    feature easily ?

Precisely what feature?  If you mean editing in the header line,
that would rather hard.  I can think of two possible methods:

* Allow a buffer to be used instead of a string, in a mode line element.

* Define a kind of mode line element that refers to a part of the
current buffer.

This would make it possible to have text in the header line (or the
mode line) which is part of a buffer.  If point were in that buffer,
you would edit that text.  To have point appear in the header line
instead of in the body of a window would require additional changes
which are probably harder in detail.

Re: Emacs mode for GDB - 2 questions

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> For inactive menu items, we recently switched from graying them out
> to using different colors, on displays which support color.
> 
> Maybe we should do this in GDB mode (and maybe also in the toolbar).
> What do people think?

Actually, the tool-bar/image greying-out already uses real `greyed
colors' instead of a stipple like the menu-code used to (I'm not sure
the exact algorithm it uses, but it basically seems to reduce the
brightness/saturation of all the colors in a disabled icon).

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Emacs mode for GDB - 2 questions

[Nick Roberts]

Miles Bader writes:
 > 
 > Actually, the tool-bar/image greying-out already uses real `greyed
 > colors' instead of a stipple like the menu-code used to (I'm not sure
 > the exact algorithm it uses, but it basically seems to reduce the
 > brightness/saturation of all the colors in a disabled icon).

Yes, but can I use this for images in the buffer and, in particular, in the
display margin?

The elisp manual says :

   Here is a list of other properties that are meaningful for all image
types:...

:algorithm ALGORITHM'
     The `:algorithm' property, if non-`nil', specifies a conversion
     algorithm that should be applied to the image before it is
     displayed; the value, ALGORITHM, specifies which algorithm.

     Currently, the only meaningful value for ALGORITHM (aside from
     `nil') is `laplace'; this applies the Laplace edge detection
     algorithm, which blurs out small differences in color while
     highlighting larger differences.  People sometimes consider this
     useful for displaying the image for a "disabled" button.

but I can't get this descriptor to do anything. (The images on the
toolbar buttons work through the descriptor `:enable')

Nick

(Miles - sorry about extra copies, I'm still learning to cc to mailing list!)

Re: Emacs mode for GDB - 2 questions

[Nick Roberts]

Richard Stallman writes:

 >     Two features adapted from gdb.el in XEmacs-21.4 :
 > 
 > To "adapt a feature" could mean various things.  Did you get the code
 > from XEmacs, or just the idea?  

I've `translated' it e.g. replaced `set-extent-property' with
`put-text-property' etc so, in your parlance, I guess its the former. The
first feature (display of expressions), however, is largely a special case of
a more general feature of gdba.el and won't have much new from XEmacs left
when I have re-formatted the output. The second feature (hypertext help
buffer) is stand alone, so it could be left out, although this would be a
shame as its quite nice.

 >  If it was code that  you used, did you find out who the authors are?

I think we've been here before. gdb.el has got the line :

;; Cygnus Support added support for gdb's --annotate=2

and Eli inferred from GDB's ChangeLog that 
Jim Kingdon <kingdon@lioth.cygnus.com> and Tom Lord <lord@x1.cygnus.com> 
were the last to work on gdba.el.

I think it is best if you contact Cygnus/XEmacs on this matter.

Nick

Re: Emacs mode for GDB - 2 questions

[Nick Roberts]

Richard Stallman writes:

 >     2) I want to format the displayed expressions more tidily. In particular
 >     I would like to show array slices and the header line would be a good
 >     place to do this e.g.
 > 
 >     ------------main::a [start:end:step]---------------
 > 
 >     Where start, end and step are in editable fields. Could emacs be given this
 >     feature easily ?
 > 
 > Precisely what feature?

Sorry, I should be clearer. I want a default format for arrays like :

---main::a [::]---- (line generated on creation of frame/window)

a[0] = 1.0
a[1] = 2.0
a[2] = 3.0
a[3] = 4.0
a[4] = 4.0
a[5] = 4.0
a[6] = 4.0
etc

and to be able to specify slices e.g every other element of the first six :

---main::a [0:5:2]----

a[0] = 1.0
a[2] = 3.0
a[4] = 4.0

With a large array, if the top line was in the buffer it would scroll out of 
view. I would like to be able to enter the three digits (0,5,2 in this case)
into the header line.

If the effort cannot be justified, I'll think of something else.

Nick

Re: Emacs mode for GDB - 2 questions

[Kim F. Storm]

Nick Roberts <nick@nick.uklinux.net> writes:

> 
> and to be able to specify slices e.g every other element of the first six :
> 
> ---main::a [0:5:2]----
> 
> a[0] = 1.0
> a[2] = 3.0
> a[4] = 4.0
> 
> With a large array, if the top line was in the buffer it would scroll out of 
> view. I would like to be able to enter the three digits (0,5,2 in this case)
> into the header line.
> 
> If the effort cannot be justified, I'll think of something else.

Couldn't you get the input from the mini-buffer (using some command)
and just show the entered values in the header line?  

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

Re: Emacs mode for GDB - 2 questions

[Eli Zaretskii]

> From: storm@cua.dk
> Date: 31 May 2002 01:16:37 +0200
> 
> > ---main::a [0:5:2]----
> > 
> > a[0] = 1.0
> > a[2] = 3.0
> > a[4] = 4.0
> > 
> > With a large array, if the top line was in the buffer it would scroll out of 
> > view. I would like to be able to enter the three digits (0,5,2 in this case)
> > into the header line.
> > 
> > If the effort cannot be justified, I'll think of something else.
> 
> Couldn't you get the input from the mini-buffer (using some command)
> and just show the entered values in the header line?  

Indeed.  For example, clicking on one of the numbers could prompt for
input.

Re: Emacs mode for GDB - 2 questions

[Richard Stallman]

    I think it is best if you contact Cygnus/XEmacs on this matter.

I will try to do that; in the mean time, would you please take out
that code?  To include it now is taking a risk.

    The
    first feature (display of expressions), however, is largely a special case of
    a more general feature of gdba.el and won't have much new from XEmacs left
    when I have re-formatted the output.

Would you please start from scratch then?

Re: Emacs mode for GDB - 2 questions

[Richard Stallman]

    With a large array, if the top line was in the buffer it would scroll out of 
    view. I would like to be able to enter the three digits (0,5,2 in this case)
    into the header line.

That feature makes sense well enough, but as I said, it would
be difficult to implement.

But I have another idea for implementing it.  Suppose that line were
actually a separate window, with its mode line disabled, showing just
one line of some buffer.  That way you could indeed select it and edit
it as usual.  You could make the parts that should not really be edited
read-only.

This would require a new feature in the C code, but since it would
only affect the setting up of window structure, not redisplay,
it would be far easier.  It might actually be feasible.

We would need to decide on the UI for selection of these special
windows.

This leads to a further idea.  Suppose that every mode line (and every
header line) were actually a separate window, and formatting of mode
line elements was done by converting them into text in a buffer.  That
would be elegant in some ways.  The usage of memory for this would
be acceptable nowadays.

This would make it possible to copy text from a mode line or header
line by dragging the mouse across it, for example.

What do people think?

Re: Emacs mode for GDB - 2 questions

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Suppose that every mode line (and every header line) were actually a
> separate window, and formatting of mode line elements was done by
> converting them into text in a buffer.  That would be elegant in some
> ways.  The usage of memory for this would be acceptable nowadays.
...
> What do people think?

I think it would be very cool, although the mode-line/header-line are
special cased to such an extent in the display engine that it makes me
wonder how many unseen gotchas there are.  Another cool think is that
this might make it easier to have multiple header-lines (or
mode-lines!), which I've sometimes wanted.

A related issue:  I've always thought it would be nice if emacs had some
way of `binding' windows together, so that, they could be treated as a
unit in some respects (i.e., other windows couldn't pop up between them,
and perhaps switching buffers using C-x C-b would switch the _whole_
group of bound windows instead of just the current leaf window).  I
would like it if the Gnus summary/article buffers were bound in this
way, for instance.  Promoting mode-lines and header-lines to real
windows might fit well with this sort of mechanism.

My vague thought was that since windows area already arranged in a tree,
that somehow non-leaf windows could be marked as the `root' of a set of
bound windows, and certain operations (switch-to-buffer?) would walk up
the tree and use such `bound roots' instead of the leaf window if it
found one.

Anyway, just a thought.

-Miles
-- 
Run away!  Run away!

Re: Emacs mode for GDB - 2 questions

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Such modeline-less windows may be useful for other purposes, so
> we should try adding them to see what use people can find for them.

They already exist -- just do (setq mode-line-format nil).
Works like a charm.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Emacs mode for GDB - 2 questions

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     With a large array, if the top line was in the buffer it would scroll out of 
>     view. I would like to be able to enter the three digits (0,5,2 in this case)
>     into the header line.
> 
> That feature makes sense well enough, but as I said, it would
> be difficult to implement.

There are obvious alternative ways to accomplish the same effect
(e.g. click on the header-line and use the mini-buffer to enter the
numbers).  To me that seems like a more logical approach than editing
the numbers directly in the header line -- when and how do you then
determine what numbers to actually use -- and how do you change,
e.g. the 5 to 10? do you delete the 5 first and then enter 1 and 0
(giving 2 interrim data values in the middle field).

I'd definitely prefer to use the minibuffer for this kind of input.

> 
> But I have another idea for implementing it.  Suppose that line were
> actually a separate window, with its mode line disabled, showing just
> one line of some buffer.  That way you could indeed select it and edit
> it as usual.  You could make the parts that should not really be edited
> read-only.
> 
Such modeline-less windows may be useful for other purposes, so
we should try adding them to see what use people can find for them.

> This would require a new feature in the C code, but since it would
> only affect the setting up of window structure, not redisplay,
> it would be far easier.  It might actually be feasible.
> 
Yes, I think this would be a fairly trivial change.

> We would need to decide on the UI for selection of these special
> windows.

For the UI, just set mode-line-format to nil to remove the modeline.

> 
> This leads to a further idea.  Suppose that every mode line (and every
> header line) were actually a separate window, and formatting of mode
> line elements was done by converting them into text in a buffer.  That
> would be elegant in some ways.  The usage of memory for this would
> be acceptable nowadays.

Sounds complicated -- and of limited use.  I don't think it is worth
the efforts.

> 
> This would make it possible to copy text from a mode line or header
> line by dragging the mouse across it, for example.

We already has other uses for clicking in and dragging of the modeline.
Adding cut and paste to that list makes it more complicated to use.

Someone suggested to add a function to get the current mode line
contents as a string.  With that function, we could make a "hot-spot"
in the modeline (e.g. click mouse-3 on the buffer name) to copy it to
the kill-ring.  For the rare cases where you need to get the mode line
contents, I think that would be an acceptable solution.

> 
> What do people think?
> 
I like the idea of modeline-less windows, but the idea of using buffers
to format the mode line seems like overkill to me.

Re: Emacs mode for GDB - 2 questions

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>> Such modeline-less windows may be useful for other purposes, so
>> we should try adding them to see what use people can find for them.
>
> They already exist -- just do (setq mode-line-format nil).
> Works like a charm.

Too bad I cannot make it frame-local...  I'm trying to create new
frames without any extra stuff in them.  But the mode line is
buffer-local...

(set (make-variable-frame-local 'mode-line-format) nil)

Debugger entered--Lisp error: (error "Symbol mode-line-format may not be frame-local")
  make-variable-frame-local(mode-line-format)
  (set (make-variable-frame-local (quote mode-line-format)) nil)
  eval((set (make-variable-frame-local (quote mode-line-format)) nil))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)

Alex.

Re: Emacs mode for GDB - 2 questions

[Nick Roberts]

Eli Zaretskii writes:

 > From: storm@cua.dk
 ...
 > > Couldn't you get the input from the mini-buffer (using some command)
 > > and just show the entered values in the header line?  
 > 
 > Indeed.  For example, clicking on one of the numbers could prompt for
 > input.

I like this idea. I'll try to implement it.

Nick

Re: Emacs mode for GDB - 2 questions

[Richard Stallman]

    Such modeline-less windows may be useful for other purposes, so
    we should try adding them to see what use people can find for them.

I believe we already support windows without mode-lines.

    > We would need to decide on the UI for selection of these special
    > windows.

    For the UI, just set mode-line-format to nil to remove the modeline.

That is already the way to remove the modeline.
I'm talking about a different issue: how to handle these windows
for window selection, change of window size, etc.
If we don't get that right, the feature will be inconvenient for users.

    A related issue:  I've always thought it would be nice if emacs had some
    way of `binding' windows together, so that, they could be treated as a
    unit in some respects (i.e., other windows couldn't pop up between them,
    and perhaps switching buffers using C-x C-b would switch the _whole_
    group of bound windows instead of just the current leaf window).

This is another thing we need to work out in order for this
mode-line-less-window approach to work well.

    My vague thought was that since windows area already arranged in a tree,
    that somehow non-leaf windows could be marked as the `root' of a set of
    bound windows, and certain operations (switch-to-buffer?) would walk up
    the tree and use such `bound roots' instead of the leaf window if it
    found one.

Would you like to try to flesh out this design?  Rather than jumping
straight to the writing of code, try to write pseudo-code to make the
meaning of these intermediate roots more clear.  That way we can see
if it really is a usable solution.

Re: Emacs mode for GDB - 2 questions

[Richard Stallman]

    Too bad I cannot make it frame-local...  I'm trying to create new
    frames without any extra stuff in them.

Perhaps what you would really want is to make it a window-local
characteristic in this case.  Is that so?

I suspect that for window-local characteristics to really work
properly the window needs other special treatment, such as that
user-level commands such as C-x 1 won't kill it.

Re: Emacs mode for GDB - 2 questions

[Juanma Barranquero]

On Fri, 31 May 2002 15:27:39 -0600 (MDT), Richard Stallman <rms@gnu.org> wrote:

> This leads to a further idea.  Suppose that every mode line (and every
> header line) were actually a separate window, and formatting of mode
> line elements was done by converting them into text in a buffer.

That would be really useful. On one hand, because it'd be easier to do
some things with the modeline, in the sense that now to do fancy things
you have to resort to :exec and do fancy tricks, etc., while with your
proposed method all full power of elisp buffer/string manipulation would
be at user's (or module's writer's) hands. On the other, because that
would make mode-line information (like current line / column) far easier
to use from a module.


                                                           /L/e/k/t/u

Re: Emacs mode for GDB - 2 questions

[Stefan Monnier]

>     My vague thought was that since windows area already arranged in a tree,
>     that somehow non-leaf windows could be marked as the `root' of a set of
>     bound windows, and certain operations (switch-to-buffer?) would walk up
>     the tree and use such `bound roots' instead of the leaf window if it
>     found one.
> 
> Would you like to try to flesh out this design?  Rather than jumping
> straight to the writing of code, try to write pseudo-code to make the
> meaning of these intermediate roots more clear.  That way we can see
> if it really is a usable solution.

It would be good to think about how such a thing could also
be used for things like ECB where they need to be able to
impose some structure on the window layout and make sure that
the user does not mess it up accidentally (i.e. there is
one main window which the user can use whichever way she wants,
and it is surrounded by several other windows (like a gdb window,
a speedbar window, ...)).


	Stefan