[Date Prev][Date Next][Thread Prev][Thread Next][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)))
Vladimir