yasq: unable to edebug-defun

yasq: unable to edebug-defun

[Mirko]

hello,

This could be due to my incompetence, senility or just lack of emacs
knowledge: I cannot compile my defun's.  If I try to do either M-C-x or
C-u M-C-x, emacs tries to evaluate the defun in which my cursor
resides, instead of compiling it.

(This is emacs 22.0.90.1 for windows and by the key sequences, I mean
Esc key, followed by pressing ctrl and x keys -- I am becoming unsure
if I remember the key notation.).

I tried also M-x edebug-defun, but then the debugger immediately tries
to step through the function instead of instrumenting it.

I may have some variable set wrong, but I don't recall changing any of
the emacs variables.

Thanks,

Mirko

Re: yasq: unable to edebug-defun

[Robert Thorpe]

Mirko wrote:
> hello,
>
> This could be due to my incompetence, senility or just lack of emacs
> knowledge: I cannot compile my defun's.  If I try to do either M-C-x or
> C-u M-C-x, emacs tries to evaluate the defun in which my cursor
> resides, instead of compiling it.

That's the normal behaviour M-C-x evals a defun, which means it stores
the code for the function inside emacs.
C-u M-C-x evaluates it also instrumenting it for edebug.

> I tried also M-x edebug-defun, but then the debugger immediately tries
> to step through the function instead of instrumenting it.

The debugger should not be triggered immediately.
Maybe you have the wrong number of parenthesis in the buffer you're
using, try turning on show-paren-mode to check.

You have to have point at the end of some function Like
(defun foo () (print "bar"))POINT then hit M-C-x.

Bytecode compilation is only used through byte-compile-file normally.

Re: yasq: unable to edebug-defun

[Mirko]

Robert Thorpe wrote:
> Mirko wrote:
> > hello,
> >
> > This could be due to my incompetence, senility or just lack of emacs
> > knowledge: I cannot compile my defun's.  If I try to do either M-C-x or
> > C-u M-C-x, emacs tries to evaluate the defun in which my cursor
> > resides, instead of compiling it.
>
> That's the normal behaviour M-C-x evals a defun, which means it stores
> the code for the function inside emacs.
> C-u M-C-x evaluates it also instrumenting it for edebug.
>
> > I tried also M-x edebug-defun, but then the debugger immediately tries
> > to step through the function instead of instrumenting it.
>
> The debugger should not be triggered immediately.
> Maybe you have the wrong number of parenthesis in the buffer you're
> using, try turning on show-paren-mode to check.
>
> You have to have point at the end of some function Like
> (defun foo () (print "bar"))POINT then hit M-C-x.
>
> Bytecode compilation is only used through byte-compile-file normally.

Robert,

I tried your suggestions, and (other than learning about the
show-paren-mode) no luck.

Here is my example defun (this is for example only, I get similar
behavior with other defuns)

(defun map-to-buffer (map buffer)
(interactive)
(switch-to-buffer buffer)
(save-excursion
  (save-window-excursion
    (save-match-data
      (widen)
      (goto-char (point-min))
      (insert "\\begin{document}\n"
      (dump-map map)
      (goto-char (point-max))
      (insert "\n\\end{document")
      (indent-region (point-min) (point-max) nil)
      )))))

If I put it into *scratch* to avoid interference with other dangling
parenthesis (which I did not find) and put the point after the last
parenthesis and do M-C-x, I get:
Debugger entered--Lisp error: (void-variable map)
  (dump-map map)
  (insert "\\begin{document}\n" (dump-map map) (goto-char (point-max))
(insert "\n\\end{document") (indent-region (point-min) (point-max)
nil))
  (progn (widen) (goto-char (point-min)) (insert "\\begin{document}\n"
(dump-map map) (goto-char ...) (insert "\n\\end{document")
(indent-region ... ... nil)))
  (unwind-protect (progn (widen) (goto-char ...) (insert
"\\begin{document}\n" ... ... ... ...)) (set-match-data
save-match-data-internal (quote evaporate)))
  (let ((save-match-data-internal ...)) (unwind-protect (progn ... ...
...) (set-match-data save-match-data-internal ...)))
  (save-match-data (widen) (goto-char (point-min)) (insert
"\\begin{document}\n" (dump-map map) (goto-char ...) (insert
"\n\\end{document") (indent-region ... ... nil)))
  (save-window-excursion (save-match-data (widen) (goto-char ...)
(insert "\\begin{document}\n" ... ... ... ...)))
  (save-excursion (save-window-excursion (save-match-data ... ...
...)))
  eval((save-excursion (save-window-excursion (save-match-data ... ...
...))))
  eval-defun(nil)
  call-interactively(eval-defun)

If I do C-u M-C-x, then I get the pointer next to the (save-excursion
... statement.  That is not at the first executable statement
(switch-to-buffer buffer)

If I do a C-x C-e I get map-to-buffer in the message window (which is
what I would expect).

My key bindings are
M-C-x: eval-defun
C-x C-e: eval-last-sexp

The output of the emacs bug report (I still think it is some error in
my setup or actions) is:
In GNU Emacs 22.0.90.1 (i386-mingw-nt5.1.2600)
 of 2006-11-05 on NEUTRINO
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags
-Ic:/Programme/GnuWin32/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  desktop-save-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t


Thanks,

Mirko

Re: yasq: unable to edebug-defun

[Robert Thorpe]

Mirko wrote:
> Robert Thorpe wrote:
> > Mirko wrote:
<snip>
> (defun map-to-buffer (map buffer)
> (interactive)
> (switch-to-buffer buffer)
> (save-excursion
>   (save-window-excursion
>     (save-match-data
>       (widen)
>       (goto-char (point-min))
>       (insert "\\begin{document}\n"
>       (dump-map map)
>       (goto-char (point-max))
>       (insert "\n\\end{document")
>       (indent-region (point-min) (point-max) nil)
>       )))))

This sounds like a bug to me.  I'm using Emacs21 which doesn't have
dump-map, so I can't test your code, but the variable map certainly
doesn't look void.  Eval-defun(M-C-x) and Eval-last-sexp(C-xC-e)
shouldn't behave differently here.

Re: yasq: unable to edebug-defun

[Mirko]

Robert Thorpe wrote:
> Mirko wrote:
> > Robert Thorpe wrote:
> > > Mirko wrote:
> <snip>
> > (defun map-to-buffer (map buffer)
> > (interactive)
> > (switch-to-buffer buffer)
> > (save-excursion
> >   (save-window-excursion
> >     (save-match-data
> >       (widen)
> >       (goto-char (point-min))
> >       (insert "\\begin{document}\n"
> >       (dump-map map)
> >       (goto-char (point-max))
> >       (insert "\n\\end{document")
> >       (indent-region (point-min) (point-max) nil)
> >       )))))
>
> This sounds like a bug to me.  I'm using Emacs21 which doesn't have
> dump-map, so I can't test your code, but the variable map certainly
> doesn't look void.  Eval-defun(M-C-x) and Eval-last-sexp(C-xC-e)
> shouldn't behave differently here.

Well, with your authoritative opinion,I will send this bug to emacs
developers.  Next year.  Today is my last day before my vacation.

Thanks for your help and best wishes,

Mirko

Re: yasq: unable to edebug-defun

[Johan Bockgård]

"Mirko" <mvukovic@nycap.rr.com> writes:

> Here is my example defun (this is for example only, I get similar
> behavior with other defuns)
>
> (defun map-to-buffer (map buffer)
> (interactive)
> (switch-to-buffer buffer)
> (save-excursion
>   (save-window-excursion
>     (save-match-data
>       (widen)
>       (goto-char (point-min))
>       (insert "\\begin{document}\n"
>       (dump-map map)
>       (goto-char (point-max))
>       (insert "\n\\end{document")
>       (indent-region (point-min) (point-max) nil)
>       )))))
>
> If I put it into *scratch* to avoid interference with other dangling
> parenthesis (which I did not find) and put the point after the last
> parenthesis and do M-C-x, I get:
> Debugger entered--Lisp error: (void-variable map)

Indent your code correctly. To Emacs it looks like the defun begins
here:

(save-excursion
 ...



-- 
Johan Bockgård

Re: yasq: unable to edebug-defun

[Robert Thorpe]

Mirko wrote:
> Robert Thorpe wrote:
> > Mirko wrote:
> > > Robert Thorpe wrote:
> > > > Mirko wrote:
<snip>

Demonstrating how authoritative my opinion isn't I wrote:-

> > This sounds like a bug to me.  I'm using Emacs21 which doesn't have
> > dump-map, so I can't test your code, but the variable map certainly
> > doesn't look void.  Eval-defun(M-C-x) and Eval-last-sexp(C-xC-e)
> > shouldn't behave differently here.
>
> Well, with your authoritative opinion,I will send this bug to emacs
> developers.  Next year.  Today is my last day before my vacation.

I was wrong.  It seems that M-C-x requires that lisp code be properly
formatted, in particular that the defun is the only thing beginning in
column 1.  If you format the code:-

(defun map-to-buffer (map buffer)
  (interactive)
  (switch-to-buffer buffer)
  (save-excursion
	(save-window-excursion
	  (save-match-data
		(widen)
		(goto-char (point-min))
		(insert "\\begin{document}\n")
		(dump-map map)
		(goto-char (point-max))
		(insert "\n\\end{document")
		(indent-region (point-min) (point-max) nil))))))

Then it will work.

Re: yasq: unable to edebug-defun

[Kevin Rodgers]

Mirko wrote:
> Robert Thorpe wrote:
>> Mirko wrote:
>>> hello,
>>>
>>> This could be due to my incompetence, senility or just lack of emacs
>>> knowledge: I cannot compile my defun's.  If I try to do either M-C-x or
>>> C-u M-C-x, emacs tries to evaluate the defun in which my cursor
>>> resides, instead of compiling it.
>> That's the normal behaviour M-C-x evals a defun, which means it stores
>> the code for the function inside emacs.
>> C-u M-C-x evaluates it also instrumenting it for edebug.
>>
>>> I tried also M-x edebug-defun, but then the debugger immediately tries
>>> to step through the function instead of instrumenting it.
>> The debugger should not be triggered immediately.
>> Maybe you have the wrong number of parenthesis in the buffer you're
>> using, try turning on show-paren-mode to check.
>>
>> You have to have point at the end of some function Like
>> (defun foo () (print "bar"))POINT then hit M-C-x.
>>
>> Bytecode compilation is only used through byte-compile-file normally.
> 
> Robert,
> 
> I tried your suggestions, and (other than learning about the
> show-paren-mode) no luck.
> 
> Here is my example defun (this is for example only, I get similar
> behavior with other defuns)
> 
> (defun map-to-buffer (map buffer)
> (interactive)
> (switch-to-buffer buffer)
> (save-excursion
>   (save-window-excursion
>     (save-match-data
>       (widen)
>       (goto-char (point-min))
>       (insert "\\begin{document}\n"

You are missing a close parenthesis at the end of the `(insert ...'
form.

>       (dump-map map)
>       (goto-char (point-max))
>       (insert "\n\\end{document")

I think you want a right brace after `"{document'.

>       (indent-region (point-min) (point-max) nil)
>       )))))
> 
> If I put it into *scratch* to avoid interference with other dangling
> parenthesis (which I did not find) and put the point after the last
> parenthesis and do M-C-x, I get:
> Debugger entered--Lisp error: (void-variable map)
>   (dump-map map)
>   (insert "\\begin{document}\n" (dump-map map) (goto-char (point-max))
> (insert "\n\\end{document") (indent-region (point-min) (point-max)
> nil))
>   (progn (widen) (goto-char (point-min)) (insert "\\begin{document}\n"
> (dump-map map) (goto-char ...) (insert "\n\\end{document")
> (indent-region ... ... nil)))
>   (unwind-protect (progn (widen) (goto-char ...) (insert
> "\\begin{document}\n" ... ... ... ...)) (set-match-data
> save-match-data-internal (quote evaporate)))
>   (let ((save-match-data-internal ...)) (unwind-protect (progn ... ...
> ...) (set-match-data save-match-data-internal ...)))
>   (save-match-data (widen) (goto-char (point-min)) (insert
> "\\begin{document}\n" (dump-map map) (goto-char ...) (insert
> "\n\\end{document") (indent-region ... ... nil)))
>   (save-window-excursion (save-match-data (widen) (goto-char ...)
> (insert "\\begin{document}\n" ... ... ... ...)))
>   (save-excursion (save-window-excursion (save-match-data ... ...
> ...)))
>   eval((save-excursion (save-window-excursion (save-match-data ... ...
> ...))))
>   eval-defun(nil)
>   call-interactively(eval-defun)
> 
> If I do C-u M-C-x, then I get the pointer next to the (save-excursion
> ... statement.  That is not at the first executable statement
> (switch-to-buffer buffer)
> 
> If I do a C-x C-e I get map-to-buffer in the message window (which is
> what I would expect).
> 
> My key bindings are
> M-C-x: eval-defun
> C-x C-e: eval-last-sexp
> 
> The output of the emacs bug report (I still think it is some error in
> my setup or actions) is:
> In GNU Emacs 22.0.90.1 (i386-mingw-nt5.1.2600)
>  of 2006-11-05 on NEUTRINO
> X server distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags
> -Ic:/Programme/GnuWin32/include'
> 
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: ENU
>   locale-coding-system: cp1252
>   default-enable-multibyte-characters: t
> 
> Major mode: Lisp Interaction
> 
> Minor modes in effect:
>   shell-dirtrack-mode: t
>   desktop-save-mode: t
>   encoded-kbd-mode: t
>   tooltip-mode: t
>   tool-bar-mode: t
>   mouse-wheel-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   unify-8859-on-encoding-mode: t
>   utf-translate-cjk-mode: t
>   auto-compression-mode: t
>   line-number-mode: t
> 
> 
> Thanks,
> 
> Mirko

-- 
Kevin