Re: Patch to emacs-w3m

[Paul Kinnucan <paulk@xxxxxxxxxxxxx>]

Katsumi Yamaoka writes:
 > >>>>> 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. 

Hi Katsumi

I've discovered the cause of the problem. The JDEE installs a
kill-buffer-hook function that performs a string-match operation
without saving and restoring existing match data.  This hook function
is called every time w3m-decode-entities-string is called because
w3m-decode-entities-string creates and kills a temporary buffer. This
in turn resets the match data used by emacs-w3m to search for HTML
elements through a rendered buffer, causing an infinite loop. I think
this is the cause of the infinite loop problem that Jose
Ruiz encountered and that started this thread.

I have updated the JDEE's kill-buffer-hook function to save and
restore existing match data and this solves the infinite loop problem
with emacs-w3m. Nevertheless, I include a version of
w3m-decode-entities-string that decodes entities in a string without
creating a temporary buffer. The replacement should be faster than the
existing version because it does not create and destroy buffers and
should avoid similar problems in the future with kill-buffer-hook
functions inadvertently destroying match data used by emacs-w3m.

Paul

*** c:/WINDOWS/TEMP/w3m.el	Sun Oct 12 23:39:22 2003
--- c:/WINDOWS/TEMP/w3m.el-499965o5h	Sun Oct 12 23:39:22 2003
***************
*** 2672,2683 ****
  
  (defun w3m-decode-entities-string (str)
    "Decode entities in the string STR."
!   (save-match-data
!     (if (string-match w3m-entity-regexp str)
! 	(w3m-entity-value 
! 	 (match-string 1 str)
! 	 (match-beginning 2))
!       str)))
  
  (defun w3m-encode-specials-string (str)
    "Encode special characters in the string STR."
--- 2672,2681 ----
  
  (defun w3m-decode-entities-string (str)
    "Decode entities in the string STR."
!   (with-temp-buffer
!     (insert str)
!     (save-match-data (w3m-decode-entities))
!     (buffer-string)))
  
  (defun w3m-encode-specials-string (str)
    "Encode special characters in the string STR."