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

Re: jde + emacs-w3m problem



Hi,

>>>>> In [emacs-w3m : No.05886]
>>>>>	Paul Kinnucan <paulk@mathworks.com> wrote:

> Hi Katsumi,

> I have succeeded in patching vm to work with emacs-w3m. It works
> very well.

Wonderful!  We are glad to hear that emacs-w3m can be used for
VM.

> I did have one problem, however, with emacs-w3m.  The function
> w3m-rendering-extract-title kept failing with an argument out of
> range error when attempting to delete the region containing the
> title. I believe the reason it fails is that the match data for the
> title string is invalidated by the subsequent call to
> w3m-decode-entities-string. This should not happen because
> w3m-decode-entities-string uses save-match-data to save and restore
> match data. However, it does happen.

That's weird.  The match-data function returns a copy of the
search result:

(with-temp-buffer
  (insert "a b")
  (goto-char (point-min))
  (search-forward "b" nil t)
  (eq (match-data) (match-data)))

It means two match-data are not identical Lisp objects even if
they are the same values.  And the save-match-data macro saves
and restores the return value of the match-data function, so I
think it is hard to destroy the saved value by performing setcar
or any other functions.  However, I found Kyle's comment in the
vm-save.el file:

  ;; It appears that get-buffer-create clobbers the match-data.

Although I may misread what Kyle really meant, we may have to
use save-match-data as follows if it generally occurs literally,
since the with-temp-buffer macro uses get-buffer-create:

(defun w3m-decode-entities-string (str)
  "Decode entities in the string STR."
  (save-match-data
    (with-temp-buffer
      (insert str)
      (w3m-decode-entities)
      (buffer-string))))

However, I have not seen such a problem.  Does anyone know what
is happening?
-- 
Katsumi Yamaoka <yamaoka@jpl.org>