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

Re: Patch to emacs-w3m



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>