[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to emacs-w3m
- From: Katsumi Yamaoka <yamaoka@xxxxxxx>
- Date: Mon, 13 Oct 2003 15:56:52 +0900
- X-ml-name: emacs-w3m
- X-mail-count: 05905
- References: <16260.65445.650000.941492@gargle.gargle.HOWL><16262.39042.951551.144968@jpl.org><16266.13548.810000.67568@gargle.gargle.HOWL>
Hi,
Please send such messages not only to me but to the emacs-w3m
list, since I think they should be caught by all the emacs-w3m
developers' eyes.
>>>>> In <16266.13548.810000.67568@gargle.gargle.HOWL>
>>>>> Paul Kinnucan <paulk@mathworks.com> wrote:
> Hi Katsumi,
> I've encountered additional cases in which emacs-w3m goes into an
> infinite loop trying to fontify HTML mail files. (Most of the
> cases that cause problem are spam messages. Perhaps the reason
> you haven't encountered problems is that you don't get as much
> spam as I do.)
I use Gnus + emacs-w3m and receive many spam mails every day.
However, I've never experienced the error caused by the
w3m-rendering-extract-title function.
> The cases all appear to be caused by the function
> w3m-decode-entities-string. In order to reuse w3m-decode-entities,
> which operates on buffers, this function creates a temporary buffer,
> which in turn clobbers global match data on which the calling function
> relies to parse the buffer. Because the match data is clobbered, the
> calling function keeps reparsing the same section of the buffer being
> rendered.
I couldn't reproduce it so far. It must be a vital problem that
generation or switch of a buffer breaks match-data. If it
always arises in your environment, you can write a simple test
program so that Emacs maintainers can reproduce the problem
easily, can't you? For example:
(save-excursion
(set-buffer (get-buffer-create "*testing*"))
(erase-buffer)
(insert "foo\nbar\n")
(goto-char (point-min))
(re-search-forward "\\(bar\\)" nil t)
(with-temp-buffer
(insert "bar\nfoo\n")
(save-match-data
(re-search-forward "\\(bar\\)" nil t)))
(match-string 1))
=> "foo"
> Anyway, I've rewritten w3m-decode-entities-string to be
> self-contained. This results in a function that is not only faster
> but also does not clobber match data. Anyway, this change has enabled
> emacs-w3m to render emails that formerly caused infinite loops.
I'm sorry that I may be pigheaded. I don't want to make that
change until I can be convinced by myself.
> Attached is a patch to w3m.el containing the rewritten function and a
> test case.
> Paul
> [ATTACHMENT ~/emacs/site-lisp/emacs-w3m/patch, text]
> [ATTACHMENT ~/emacs/site-lisp/emacs-w3m/test2.txt, text]
There are only tag lines. Could you please send them again?
--
Katsumi Yamaoka <yamaoka@jpl.org>