Mode for files visited by GUD

Mode for files visited by GUD

[Juanma]

Hello all,

Is there any mode (and it's hook) run when GUD visits a source code file
during debugging?

I have found a gud-minor-mode variable, but it's not documented. Anyway,
quickly peeping into the source, it doesn't seem like that minor mode would
serve my purpose.

Actually, many functions and variables are not documented. I'm not helping,
so I'm not complaining. I'm just curious, because I find it odd for a mature
package (GUD has gone along with Emacs since a very long time ago, right?)
to have many things left undocumented.

BTW, is Emacs' CVS repository, under emacs/lisp/progmodes, the right place to
find the latest version?

Thanks.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: Mode for files visited by GUD

[Nick Roberts]

 > Is there any mode (and it's hook) run when GUD visits a source code file
 > during debugging?

gdb-find-file-hook is run when GUD visits a source code file.  You could
advise that function or create your own hook using find-file-hook
(see the Elisp manual).

 > I have found a gud-minor-mode variable, but it's not documented. Anyway,
 > quickly peeping into the source, it doesn't seem like that minor mode would
 > serve my purpose.

Not all variables are documented, particularly those for internal use.
gud-minor-mode is probably such a variable.

 > Actually, many functions and variables are not documented. I'm not helping,
 > so I'm not complaining. I'm just curious, because I find it odd for a mature
 > package (GUD has gone along with Emacs since a very long time ago, right?)
 > to have many things left undocumented.

Documentation is provided at the user level in the Emacs and Elisp manuals and
through the documentaion strings.  And there are comments in the source code to
help developers.  It's a question of balancing convenience with overhead.  Also
comment/doc strings can get out of date and sometimes it's better to let the
code speak for itself.

 > BTW, is Emacs' CVS repository, under emacs/lisp/progmodes, the right place to
 > find the latest version?

Yes, but to ensure it always works, you really need to check out all of Emacs
from the repository, and then you can update when fixes are made.

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

Re: Mode for files visited by GUD

[Juanma]

Hello, Nick.

Thanks for your help.

> = Nick Roberts
>  > = Juan Bellon

>  > Is there any mode (and it's hook) run when GUD visits a source code file
>  > during debugging?
> 
> gdb-find-file-hook is run when GUD visits a source code file.  You could
> advise that function

Great, it worked.

This is sort of peculiar way to do it. I mean, hooks are normally variables,
and one uses add-hook with them. But in this case it is a function,
documented on a user level, while the variable was not. Maybe the variable
was created by my mistake only, as I hooked my function on it?

So, yes, I can advice that function, but, anything against using a hook
variable instead?

Another question: is there an "exit hook", for the time when debugging goes
into a different file? I guess it doesn't make a lot of sense, but I'm curious.

> or create your own hook using find-file-hook (see the Elisp manual).

I'm also curious about this. What did you mean? Why should I create my own
hook instead of hooking my minor mode or function into that existing hook?
And how can I tell if the file is being found by GUD and not by user request?

Best regards,
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: Mode for files visited by GUD

[Juanma]

> > gdb-find-file-hook is run when GUD visits a source code file.  You could
> > advise that function
> 
> Great, it worked.

No, wait. Now find-file-hook contains gdb-find-file-hook, so Emacs is
running my gdb-specific minor mode for every file "found" into Emacs.

This is what I did:

----------------------------------------
  (defun activate-my-guding-mode ()
    (source-guding-mode 1)
    (message "*GUDing* mode activated"))
  
  (defadvice gdb-find-file-hook (after activate-guding activate)
    (activate-my-guding-mode))
----------------------------------------

Did I do something wrong?
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: Mode for files visited by GUD

[Nick Roberts]

 > >  > Is there any mode (and it's hook) run when GUD visits a source code file
 > >  > during debugging?
 > > 
 > > gdb-find-file-hook is run when GUD visits a source code file.  You could
 > > advise that function
 > 
 > Great, it worked.
 > 
 > This is sort of peculiar way to do it. I mean, hooks are normally variables,
 > and one uses add-hook with them. But in this case it is a function,

You're probably right but others do it too, e.g., vc-find-file-hook.  I find
it an easy way to remember what hook the function is associated with.

 > documented on a user level, while the variable was not. Maybe the variable
 > was created by my mistake only, as I hooked my function on it?

What variable?  There is no variable gdb-find-file-hook and the variable
find-file-hook is documented in the Elisp manual.

 > So, yes, I can advice that function, but, anything against using a hook
 > variable instead?

I'm not sure what you mean.  gdb-find-file-hook is added to find-file-hook
which _is_ a hook variable

 > Another question: is there an "exit hook", for the time when debugging goes
 > into a different file? I guess it doesn't make a lot of sense, but I'm curious.

You could possibly watch the value of gdb-source-window, or, at the right time,
compare gud-last-frame to gud-last-last-frame.

 > > or create your own hook using find-file-hook (see the Elisp manual).
 > 
 > I'm also curious about this. What did you mean? Why should I create my own
 > hook instead of hooking my minor mode or function into that existing hook?
 > And how can I tell if the file is being found by GUD and not by user request?

Advising functions has it's own problems as described in the Elisp manual.

What is it you are trying to do?  If your changes are of general interest,
maybe we could include them in Emacs.

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

Re: Mode for files visited by GUD

[Juanma]

>  > documented on a user level, while the variable was not. Maybe the variable
>  > was created by my mistake only, as I hooked my function on it?
> 
> What variable?  There is no variable gdb-find-file-hook and the variable
> find-file-hook is documented in the Elisp manual.

What I thought: there *was* no such variable, until I did
 (add-hook 'gdb-find-file-hook 'my-stuff)
Of course, it didn't help with anything  :-)
The thing is, I did it before realizing that it wasn't a hook variable, but
a function. I had overlooked that you said "You could advise that function".

>  > So, yes, I can advice that function, but, anything against using a hook
>  > variable instead?
> 
> I'm not sure what you mean.

Oh, never mind. I was curious as to why making 'gdb-find-file-hook' a
function instead of a hook variable, but you already explained that it was a
design decision.

> gdb-find-file-hook is added to find-file-hook which _is_ a hook variable

Yes, I noticed it. And I don't understand the whole procedure. With this
mechanism, is there any difference between advising 'gdb-find-file-hook',
and directly hooking my functions in 'find-file-hook'? The result seems to
be the same in the end, and it's not what I wanted. I did not want my
functions to be run for every file loaded into Emacs (at least, loaded in
any way that would cause the execution of 'find-file-hook').

> Advising functions has it's own problems as described in the Elisp manual.
> 
> What is it you are trying to do?  If your changes are of general interest,
> maybe we could include them in Emacs.

I want to turn on a minor mode for source code files visited during
debugging. I want to make them read-only and have many commands bound to
single keys (I use View mode in addition to my minor mode).

The minor mode is this:

----------------------------------------

(define-minor-mode source-guding-mode
  "Toggle source-GUDing minor mode.
With prefix ARG, turn source-GUDing mode on if ARG is positive,
off otherwise.

When source-GUDing mode is on for a buffer, View mode is
activated (so the buffer is turned read-only) and GUD commands
are assigned to very simple keystrokes (typically one key). Here
is the list of those:

\\{source-guding-mode-map}"

  ;; Initial value for the minor mode variable (off)
  nil
  ;; Indicator for the mode line
  " *GUDing*"
  ;; We can provide a keymap for the minor mode or we can better to
  ;; provide the key bindings in a list (better in this case)
  '(([return] . gud-go)          ; start or continue execution
    ("b" . gud-break)            ; set a breakpoint
    ("D" . gud-remove)           ; delete breakpoint in current line, if any
    ("n" . gud-next)             ; execute next expression, but don't enter any functions
    ("s" . gud-step)             ; execute next expression, stepping into functions
    ("c" . gud-cont)             ; continue execution
    ("u" . gud-until)            ; run until cursor
    ("J" . gud-jump)             ; move execution point to current line
    (">" . gud-down)             ; go down N stack frames (needs num. arg.)
    ("<" . gud-up)               ; go up N stack frames (needs num. arg.)
    ("t" . gud-tbreak)           ; set temporary breakpoint
    ("p" . gud-print)            ; print expression at point
    ("d" . gud-pstar)            ; print C-dereferenced expression at point
    ([f5] . gud-refresh)         ; show current execution point (and re-draw screen)
    ("q" . source-guding-mode))  ; quit this mode (also toggle View mode)
  ;; Customization group
  :group gud
  ;; Body of the mode
  (view-mode source-guding-mode)) ; the value of the minor mode var. will
                                  ; determine whether to turn on or off the
                                  ; associated View mode

----------------------------------------

Then I have this in my .emacs:

(autoload 'source-guding-mode "source-guding.el")
(defadvice gdb-find-file-hook (after activate-guding activate)
  (source-guding-mode 1))
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: Mode for files visited by GUD

[Nick Roberts]

 > > What is it you are trying to do?  If your changes are of general interest,
 > > maybe we could include them in Emacs.
 > 
 > I want to turn on a minor mode for source code files visited during
 > debugging. I want to make them read-only and have many commands bound to
 > single keys (I use View mode in addition to my minor mode).

A file called gdbsrc.el used to do something like this in XEmacs and I
considered it for a while.  I think it's the wrong approcah because generally
in a debug session you end up wanting to edit your code.


 >...
 > Then I have this in my .emacs:
 > 
 > (autoload 'source-guding-mode "source-guding.el")
 > (defadvice gdb-find-file-hook (after activate-guding activate)
 >   (source-guding-mode 1))

This way, as you say, source-guding-mode is evaluated for all files.
gdb-find-file-hook is also evaluated for all files but it doesn't do
anything if gud-minor-mode is not 'gdba or 'gdbmi.

Since you probably want to set source-guding-mode for existing buffers too
it may be best to advise gdb-init-buffer.  This function only gets called
for GDB related buffers.

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

Re: Mode for files visited by GUD

[Juanma]

On Friday 18 July 2008, Nick Roberts wrote:
> A file called gdbsrc.el used to do something like this in XEmacs and I
> considered it for a while.  I think it's the wrong approcah because generally
> in a debug session you end up wanting to edit your code.

But there is nothing wrong with it. Sure, you end up editing, but that
happens at the *end*, first you have to quit debugging to do anything useful
with the editing task. Besides, I make 'q' exit the read-only modes; it
can't get much easier than that; and while I'm just doing "next", "step" and
friends, I can do it with 'n', 's' and so on, and if I need to select a
piece of code (e.g., for evaluating), I don't have to switch to another
window, and back: I'm there.

> This way, as you say, source-guding-mode is evaluated for all files.
> gdb-find-file-hook is also evaluated for all files but it doesn't do
> anything if gud-minor-mode is not 'gdba or 'gdbmi.

IMHO, it breaks the principle of least astonishment. At least I was
astonished  :-)

So I could do this, right?:

(defadvice gdb-find-file-hook (after activate-guding activate)
  (and gud-minor-mode
       (memq gud-minor-mode '(gdba gdbmi))
       (source-guding-mode 1)))

> Since you probably want to set source-guding-mode for existing buffers too
> it may be best to advise gdb-init-buffer.  This function only gets called
> for GDB related buffers.

I haven't found such function with [C-h f]. In which version was it
introduced?

Thanks.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: Mode for files visited by GUD

[Nick Roberts]

 > > A file called gdbsrc.el used to do something like this in XEmacs and I
 > > considered it for a while.  I think it's the wrong approcah because
 > > generally in a debug session you end up wanting to edit your code.
 > 
 > But there is nothing wrong with it. Sure, you end up editing, but that
 > happens at the *end*, first you have to quit debugging to do anything useful
 > with the editing task. 

It's best not to quit debugging and just recompile.  That way you keep the
shell history as well as GDB's breakpoints, although some may have moved.

 >                        Besides, I make 'q' exit the read-only modes; it
 > can't get much easier than that; and while I'm just doing "next", "step" and
 > friends, I can do it with 'n', 's' and so on, and if I need to select a
 > piece of code (e.g., for evaluating), I don't have to switch to another
 > window, and back: I'm there.

Then presumably you need to remember to turn it on again when you debug.  I find
the tool bar useful for repetitive commands except that it doesn't work properly
with GTK.  In this case, <RET> in the GUD buffer works well.

 > > This way, as you say, source-guding-mode is evaluated for all files.
 > > gdb-find-file-hook is also evaluated for all files but it doesn't do
 > > anything if gud-minor-mode is not 'gdba or 'gdbmi.
 > 
 > IMHO, it breaks the principle of least astonishment. At least I was
 > astonished  :-)

gdb-find-file-hook is an internal function not intended for general use.
It's role is too specialised for it's own hook variable.

 > So I could do this, right?:
 > 
 > (defadvice gdb-find-file-hook (after activate-guding activate)
 >   (and gud-minor-mode
 >        (memq gud-minor-mode '(gdba gdbmi))
 >        (source-guding-mode 1)))

Something like that should work but not for existing buffers which hold
source files.

 > > Since you probably want to set source-guding-mode for existing buffers too
 > > it may be best to advise gdb-init-buffer.  This function only gets called
 > > for GDB related buffers.
 > 
 > I haven't found such function with [C-h f]. In which version was it
 > introduced?

Yes, it's only in the CVS repository.

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