[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Edebug eval problem

From: Hannu Koivisto
Subject: Edebug eval problem
Date: 26 Oct 2001 13:59:47 +0300
User-agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/20.7


I'm debugging a quite large and complex package and I'm seeing the
following phenomenon.  Let's say I have code similar to this:

(defvar baz nil)
(make-variable-buffer-local 'baz)

(defun foo (bar)
    (cond ((and (stringp baz)
                (string= bar baz))
           (message "quux")))))

If I instrument foo for debugging, make my code call it and step
the expressions, I note that (stringp baz) evaluates to true
and so does (string= bar baz).  So there I am, stopped at the
beginning of (message "quux") form, and wondering what were the
values of bar and baz.  M-: bar RET gives me a string, M-: baz RET
gives me nil.  The latter result is obviously wrong; as far as I
can see from the documentation, M-: is supposed to evaluate an
expression in edebug's context.  Now, it seems that M-:
(current-buffer) RET returns the buffer of the source code, not the
buffer that is actually current when the code is evaluated when
stepping or running normally.  Since baz is a buffer local
variable, perhaps the core problem is why the current buffer
doesn't seem to be correct.

In my actual case, foo is called by a function that is called by a
function ... <here is a long chain of function calls and some of
the functions are actually constructed lambda expressions> ... that
is a process sentinel.  The buffer that should be current is set
current by one of the functions in that chain with

I'm getting ill right now so unfortunately I don't have energy to
try to nail this down into a simple test case and I may not be able
to answer inquiries soon.  Assuming I can get up from the bed, I'll
try to check my mail tomorrow or so just in case someone wants the
actual code (.tar.bz2 is ~160kB) I'm seeing this with and
instructions for reproducing the problem with it (should be doable
quite easily as long as one has Debian GNU/Linux unstable).

This happens with both Emacs 21.1 and Emacs 20.7, both running on
Debian GNU/Linux unstable x86.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]