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

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2018-02-08 02:51, Vladimir Sedach wrote:
> Hello,
>
> There was a serious bug introduced on 2017-10-13 to
> w3m-generate-new-buffer: new buffers would always get number 1, there
> would be duplicate buffers with number 1. You can verify this by opening
> a new w3m buffer (via w3m-search-new-session, for example) when multiple
> w3m buffers are already open, and trying to use w3m-previous-buffer.
>
> This bug also masked a problem with the new LAST parameter to
> w3m-copy-buffer in w3m-view-this-url-1.
>
> A patch is attached.
>
> Thank you,
> Vladimir

I need to leave soon, but here's my attempt to simplify the patch by
removing the nested `let's and placing the simple `if' alternatives
first. I haven't tested it or the original to be sure either works and
whether they're  equivalent.


(if (not w3m-use-title-buffer-name)
  (generate-new-buffer name)
 (let* ((all-w3m-buffers (w3m-list-buffers))
        (tailbufs
          (progn
            (w3m-fb-mode nil)
            (if next
              (memq (current-buffer) all-w3m-buffers)
             (last all-w3m-buffers))))
        (new-buffer-number (w3m-buffer-number (car tailbufs))))
  (when (string-match "\\*w3m\\*\\(<\\([0-9]+\\)>\\)?\\'" name)
    (setq name "*w3m*"))
  (if (not (and tailbufs new-buffer-number))
    (generate-new-buffer name)
   (let ((n (1+ new-buffer-number)))
     (dolist (buf (cdr tailbufs))
       (w3m-buffer-set-number buf (setq n (1+ n))))
     (generate-new-buffer
      (format "%s<%d>" name (1+ new-buffer-number))))))))

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0