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

Re: Patch for bug in w3m-generate-new-buffer

To make this patch, I started from the last known good definition of
W3M-GENERATE-NEW-BUFFER, revision 1.183*, and added the functionality
for the NEXT parameter with the least number of changes. The nested LET
is to emphasize that W3M-FB-MODE is being dynamically bound for the
scope of the call to W3M-LIST-BUFFERS. I do not know what W3M-FB-MODE
does; since it is in the original code I assume it affects the output of
W3M-LIST-BUFFERS in an important way and should be left there.

* - I got the revision number for w3m-util.el wrong in my Changelog
entry, I think I was looking at the log for a different file.

Below is the definition of W3M-GENERATE-NEW-BUFFER from revision 1.183
for comparison to the version in the patch I submitted. I do not believe
the version you provided has the correct behavior because of the way
W3M-FB-MODE is set.

(defun w3m-generate-new-buffer (name)
  (if w3m-use-title-buffer-name
      (let* ((maxbuf (let ((w3m-fb-mode nil))
		       (car (nreverse (w3m-list-buffers)))))
	     (number (w3m-buffer-number maxbuf)))
	(when (string-match "\\*w3m\\*\\(<\\([0-9]+\\)>\\)?\\'" name)
	  (setq name "*w3m*"))
	(if (and maxbuf number)
	    (generate-new-buffer (format "%s<%d>" name (1+ number)))
	  (generate-new-buffer name)))
    (generate-new-buffer name)))