emacs-pretest-bug
[Top][All Lists]
Advanced

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

Debugging with match data


From: Stephen Berman
Subject: Debugging with match data
Date: Fri, 11 Mar 2005 23:22:08 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Evalling the code

(with-current-buffer (get-buffer-create "*test*")
    (switch-to-buffer "*test*")
    (insert  "My test string")
    (re-search-backward (concat "My " "\\(.+\\)" " string"))
    (insert "This is a " (match-string 1) "\.\n"))

executes it without error and as a result switches to buffer *test*
which consists of the lines

This is a test.
My test string

But stepping through the code with Edebug returns `nil' upon evalling
`(match-string 1)', which in turn raises an error at the insert (Wrong
type argument: char-or-string-p, nil).

If instead of using Edebug an explicit `(debug)' is put before the
insert sexp, then stepping through the backtrace correctly shows
"test" as the value of `(match-string 1)' and you can step through
until the execution is complete and the correct buffer output is
shown.  But if the explicit `(debug)' is put directly before
`(match-string 1)', then, while the backtrace correctly shows "test"
as the value of `(match-string 1)', the next step hits the
wrong-type-argument error and shows the value of the insert as `"This
is a " nil "test" ".\n"'.

So it looks like Edebug changes the match data, which can raise a
spurious error, and the ordinary Lisp debugger behaves differently
depending on where in the code it is called.

I don't know if this is really a bug in the Edebug and Lisp debugger
code (but if not, why not?), but it's at least something that should
be mentioned in the documentation.  I find nothing in the Elisp manual
in the discussions of searching, match data, and debugging that would
lead me to expect the above described behavior when debugging code
involving match data.  In (elisp)Edebug Recursive Edit, it says Edebug
saves and restores the current match data; if this is meant to imply
the behavior I described, it failed to get the message across to me.

I should mention that I posted a question about this to gnu.emacs.help
and Pascal Bourguignon <address@hidden>
replied as follows:

"My guess is that either:

- Edebug matches regexp itself, and therefore erases the match-data, 
  (a save-match-data would be in order in Edebug), or

- Edebug changes the current buffer, and therefore when it executes 
  (match-string 1), this functions refers the match-data of the Edebug 
  buffer instead of that of the original buffer
  (a save-excursion would be in order in Edebug).

I'd bet for the former, since save-excursion is more commonly used
than save-match-data... (save-excursion calls save-buffer)."


In GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.4.9)
 of 2005-03-03 on nolde
Distributor `The X.Org Foundation', version 11.0.60801903
configured using `configure '--with-x-toolkit=gtk''

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: de_DE.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  eldoc-mode: t
  tabbar-mode: t
  recentf-mode: t
  auto-compression-mode: t
  show-paren-mode: t
  display-time-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
k <return> C-e C-j C-x k <return> C-_ <M-left> <M-left> 
<M-left> <M-left> <left> ( d e b u g ) C-e C-j d d 
d d q C-x k <return> <left> C-j <tab> <up> <up> d d 
d q C-x k <return> <down-mouse-1> <mouse-movement> 
<mouse-movement> <drag-mouse-1> <down-mouse-3> <mouse-3> 
q <down-mouse-1> <mouse-movement> <mouse-movement> 
<drag-mouse-1> C-w <down-mouse-2> <mouse-2> C-e C-j 
<tab> <up> d d d d d d d d d d d d d d d d d d d d 
d d d d d d d C-x k <return> M-x r e p o r <tab> b 
<tab> <return>

Recent messages:
Proceeding, will debug on next eval or call.
Entering debugger...
Proceeding, will debug on next eval or call.
Entering debugger...
Proceeding, will debug on next eval or call.
Entering debugger...
Proceeding, will debug on next eval or call.
Entering debugger...
Back to top level.
Loading emacsbug...done




reply via email to

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