Hi,
>>>>> In [emacs-w3m : No.05886]
>>>>> Paul Kinnucan <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
