debug-on-entry question

debug-on-entry question

[Yoni Rabkin Katzenell]

Is there an existing function which performs the following?

(defun debug-on-entry-at-point ()
  "Perform \\[debug-on-entry] on the function at point."
  (let ((fn (function-called-at-point)))
    (if fn
	(debug-on-entry fn)
      (message "No function at point"))))

-- 
"Cut your own wood and it will warm you twice"
	Regards, Yoni Rabkin Katzenell

Re: debug-on-entry question

[David Kastrup]

Yoni Rabkin Katzenell <yoni-r@actcom.com> writes:

> Is there an existing function which performs the following?
>
> (defun debug-on-entry-at-point ()
>   "Perform \\[debug-on-entry] on the function at point."
>   (let ((fn (function-called-at-point)))
>     (if fn
> 	(debug-on-entry fn)
>       (message "No function at point"))))

Usually
M-x edebug-defun RET

is much more useful.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: debug-on-entry question

[Yoni Rabkin Katzenell]

Excellent, thank you.

-- 
"Cut your own wood and it will warm you twice"
	Regards, Yoni Rabkin Katzenell

Re: debug-on-entry question

[Juri Linkov]

> Is there an existing function which performs the following?
>
> (defun debug-on-entry-at-point ()
>   "Perform \\[debug-on-entry] on the function at point."
>   (let ((fn (function-called-at-point)))
>     (if fn
> 	(debug-on-entry fn)
>       (message "No function at point"))))

A better way to do this is to change the interactive specification of
`debug-on-entry' to call `function-called-at-point'.

For post-release: it would be good to rewrite the function
`call-interactively' in Lisp which will allow easy modification of
reading arguments according to code letters (e.g. in this particular
case adding a call to `function-called-at-point' for the code letter `a').

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

RE: debug-on-entry question

[Drew Adams]

    change the interactive specification of
    `debug-on-entry' to call `function-called-at-point'.

Yes. I've suggested this previously. When debugging, you are often in an
Emacs-Lisp buffer, and this is useful.

    For post-release: it would be good to rewrite the function
    `call-interactively' in Lisp which will allow easy modification of
    reading arguments according to code letters (e.g. in this particular
    case adding a call to `function-called-at-point' for the code
    letter `a').

Not a bad idea.

---

However, that would only help with uses of `call-interactively', not uses of
`interactive' itself.

It's probably not feasible (and I foresee immediate dismissal of the idea,
regardless of feasibility), but what about also having a mechanism to let
users extend (redefine) the predefined `interactive' code letters?

For example, a user could define his own version of `b' in `(interactive
"b...")'. Instead of having to find all occurrences of `(interactive
"b...")' and replacing each of them with his own `(interactive (list
(my-read-buffer...)...)...)', he could just redefine what `(interactive
"b...")' means, in a single place. IOW, why not make the "bindings" between
the `interactive' code letters (e.g. `b') and their input-reading functions
available to users?

Re: debug-on-entry question

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>     change the interactive specification of
>     `debug-on-entry' to call `function-called-at-point'.
>
> Yes. I've suggested this previously. When debugging, you are often
> in an Emacs-Lisp buffer, and this is useful.

_If_ you are in an Emacs-Lisp buffer and consequently have the source
code of the function to be debugged available, edebug-defun is orders
of magnitude more useful for debugging a particular function.

debug-on-entry is much less convenient, but can be used without having
the source at hand.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: debug-on-entry question

[Drew Adams]

    >     change the interactive specification of
    >     `debug-on-entry' to call `function-called-at-point'.
    >
    > Yes. I've suggested this previously. When debugging, you are often
    > in an Emacs-Lisp buffer, and this is useful.

    _If_ you are in an Emacs-Lisp buffer and consequently have the source
    code of the function to be debugged available, edebug-defun is orders
    of magnitude more useful for debugging a particular function.

    debug-on-entry is much less convenient, but can be used without having
    the source at hand.

OK. I take that as an FYI about the usefulness and appropriateness of edebug
in a source-code buffer, but not as an argument not to let `debug-on-entry'
grab the function-at-point in its interactive spec.

Re: debug-on-entry question

[Juri Linkov]

> However, that would only help with uses of `call-interactively', not
> uses of `interactive' itself.

I don't understand what you mean.  `interactive' is just a specification.
`call-interactively' interprets it.

> It's probably not feasible (and I foresee immediate dismissal of the idea,
> regardless of feasibility), but what about also having a mechanism to let
> users extend (redefine) the predefined `interactive' code letters?
>
> For example, a user could define his own version of `b' in `(interactive
> "b...")'. Instead of having to find all occurrences of `(interactive
> "b...")' and replacing each of them with his own `(interactive (list
> (my-read-buffer...)...)...)', he could just redefine what `(interactive
> "b...")' means, in a single place. IOW, why not make the "bindings" between
> the `interactive' code letters (e.g. `b') and their input-reading functions
> available to users?

Rewriting it in Lisp implies that you will be able to redefine default
code letters easily if you want.

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

RE: debug-on-entry question

[Drew Adams]

    > However, that would only help with uses of `call-interactively', not
    > uses of `interactive' itself.
    
    I don't understand what you mean.  `interactive' is just a 
    specification.
    `call-interactively' interprets it.

Sorry; I see that now. I didn't realize it when I wrote that.    

Re: debug-on-entry question

[Richard Stallman]

    > For example, a user could define his own version of `b' in `(interactive
    > "b...")'. Instead of having to find all occurrences of `(interactive
    > "b...")' and replacing each of them with his own `(interactive (list
    > (my-read-buffer...)...)...)', he could just redefine what `(interactive
    > "b...")' means, in a single place. IOW, why not make the "bindings" between
    > the `interactive' code letters (e.g. `b') and their input-reading functions
    > available to users?

    Rewriting it in Lisp implies that you will be able to redefine default
    code letters easily if you want.

I think that allowing customization at that level is asking for
trouble.  Customizating details of how a specific letter `b' works is
not a problem, but letting programs simply redefine these codes is
asking for trouble.  What if two different packages both define Q but
define it in different ways?

It is much better if people keep on handling such cases by writing
Lisp code as they already have.  So aI will not entertain the idea
of adding a new feature of this kind.

Re: debug-on-entry question

[Richard Stallman]

    For post-release: it would be good to rewrite the function
    `call-interactively' in Lisp which will allow easy modification of
    reading arguments according to code letters (e.g. in this particular
    case adding a call to `function-called-at-point' for the code letter `a').

I think that would be messy and unnecessary.  I would rather keep the
present scheme: code letters for doing something standard, and pure
Lisp code for everything else.

Re: debug-on-entry question

[Lute Kamstra]

Juri Linkov <juri@jurta.org> writes:

> A better way to do this is to change the interactive specification of
> `debug-on-entry' to call `function-called-at-point'.

How about this?

Lute.


Index: lisp/emacs-lisp/debug.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/debug.el,v
retrieving revision 1.87
diff -c -r1.87 debug.el
*** lisp/emacs-lisp/debug.el	14 Jun 2005 12:00:50 -0000	1.87
--- lisp/emacs-lisp/debug.el	20 Jun 2005 17:40:29 -0000
***************
*** 653,658 ****
--- 653,664 ----
        nil
      (funcall debugger 'debug)))
  
+ (defun debugger-special-form-p (symbol)
+   "Return whether SYMBOL is a special form."
+   (and (fboundp symbol)
+        (subrp (symbol-function symbol))
+        (eq (cdr (subr-arity (symbol-function symbol))) 'unevalled)))
+ 
  ;;;###autoload
  (defun debug-on-entry (function)
    "Request FUNCTION to invoke debugger each time it is called.
***************
*** 668,676 ****
  
  Use \\[cancel-debug-on-entry] to cancel the effect of this command.
  Redefining FUNCTION also cancels it."
!   (interactive "aDebug on entry (to function): ")
!   (when (and (subrp (symbol-function function))
! 	     (eq (cdr (subr-arity (symbol-function function))) 'unevalled))
      (error "Function %s is a special form" function))
    (if (or (symbolp (symbol-function function))
  	  (subrp (symbol-function function)))
--- 674,694 ----
  
  Use \\[cancel-debug-on-entry] to cancel the effect of this command.
  Redefining FUNCTION also cancels it."
!   (interactive
!    (let ((fn (function-called-at-point)) val)
!      (when (debugger-special-form-p fn)
!        (setq fn nil))
!      (setq val (completing-read 
! 		(if fn
! 		    (format "Debug on entry to function (default %s): " fn)
! 		  "Debug on entry to function: ")
! 		obarray
! 		#'(lambda (symbol)
! 		    (and (fboundp symbol)
! 			 (not (debugger-special-form-p symbol))))
! 		t nil nil (symbol-name fn)))
!      (list (if (equal val "") fn (intern val)))))
!   (when (debugger-special-form-p function)
      (error "Function %s is a special form" function))
    (if (or (symbolp (symbol-function function))
  	  (subrp (symbol-function function)))

Re: debug-on-entry question

[Juri Linkov]

>> A better way to do this is to change the interactive specification of
>> `debug-on-entry' to call `function-called-at-point'.
>
> How about this?

There are other commands using `a' letter to read function names (like
`elp-instrument-function', etc.) where getting the default function name
from the current buffer would be useful too.  So maybe it's better to
implement this in `call-interactively' for all commands using `a'?

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

Re: debug-on-entry question

[Richard M. Stallman]

    There are other commands using `a' letter to read function names (like
    `elp-instrument-function', etc.) where getting the default function name
    from the current buffer would be useful too.  So maybe it's better to
    implement this in `call-interactively' for all commands using `a'?

That seems like a good idea.

Re: debug-on-entry question

[Lute Kamstra]

"Richard M. Stallman" <rms@gnu.org> writes:

>     There are other commands using `a' letter to read function names (like
>     `elp-instrument-function', etc.) where getting the default function name
>     from the current buffer would be useful too.  So maybe it's better to
>     implement this in `call-interactively' for all commands using `a'?
>
> That seems like a good idea.

Ok, I'll work on that.

But I still like to apply the patch for debug-on-entry as is.  Besides
using function-called-at-point, it also filters out special forms
(which can't be set to break on entry).  Is that Ok?

Lute.

Re: debug-on-entry question

[Richard M. Stallman]

    But I still like to apply the patch for debug-on-entry as is.  Besides
    using function-called-at-point, it also filters out special forms
    (which can't be set to break on entry).  Is that Ok?

Yes.

Re: debug-on-entry question

[Juri Linkov]

>     There are other commands using `a' letter to read function names (like
>     `elp-instrument-function', etc.) where getting the default function name
>     from the current buffer would be useful too.  So maybe it's better to
>     implement this in `call-interactively' for all commands using `a'?
>
> That seems like a good idea.

I have ideas for improving other code letters (for example, using ffap
for `f', `F', `D'), but they are much easier implementable in Lisp.

> I think that allowing customization at that level is asking for
> trouble.  Customizating details of how a specific letter `b' works is
> not a problem, but letting programs simply redefine these codes is
> asking for trouble.  What if two different packages both define Q but
> define it in different ways?
>
> It is much better if people keep on handling such cases by writing
> Lisp code as they already have.

The problem is in changing existing code letters.  Emacs allows
customization of almost everything down to redefining built-in core
functions, but disallows customization of default methods for reading
input arguments.  This is an artificial restriction contradicting the
principles of Emacs customization.

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

RE: debug-on-entry question

[Drew Adams]

    The problem is in changing  [the behavior of]  existing
    code letters. Emacs allows customization of almost
    everything down to redefining built-in core functions,
    but disallows customization of default methods for reading
    input arguments.  This is an artificial restriction
    contradicting the principles of Emacs customization.

I agree.