[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for bug in w3m-generate-new-buffer
In [emacs-w3m:12903]
On Wed, 14 Feb 2018 12:38:13 -0800, Vladimir Sedach wrote:
>> Er, does this one line patch do the trick?
>> I'm half in doubt, though.
> No, that does not work: when I have 4 tabs open and follow a link with
> W3M-VIEW-THIS-URL-NEW-SESSION from tab 2, the new tab opens at
> position 4 (so this change exposes an off-by-one error later in the
> current version of W3M-GENERATE-NEW-BUFFER), but receives a duplicate
> tab number 3: (mapcar #'w3m-buffer-number (w3m-list-buffers)) returns
> '(1 2 3 3 4)
> Please consider using the patch I originally provided, it does not
> have these issues.
Sorry for that. I tried your patch, and verified the bug is fixed.
> * w3m.el (w3m-view-this-url-1): Fix LAST parameter to w3m-copy-buffer
> to make new buffer go after the current buffer, as intended in revision
> 1.1691 on 2017-10-13
The new behavior (new buffer goes after the current buffer)
looks nice at first glance, though I'm not sure I originally
intended it (I think I made only `w3m-copy-buffer', that is
called interactively, do so). However, when deleting a *w3m*
buffer by using `C-c C-w', the buffer to be selected after
deleting will become that of a tab other than the left neighbor
tab as the case may be.
For instance, let's say launch w3m and visit the page 1, visit
the page 2 from 1 in a new buffer, go back to 1, and visit 3
from 1 in a new buffer. At that time there should be three
buffers 1 2 3, and 3 is selected. And then, if I delete 3,
the buffer to be selected after deleting 3 will be 1, not 2
(because of the `w3m-parent-session-buffer' variable). I think
it will perhaps confuse users when, e.g., deleting all buffers
but the first one from the rightmost buffer in turn. Actually I
experienced it (deleted the first buffer). So, I'm not positive
to install the change.
> * w3m-util.el (w3m-generate-new-buffer): Fix bug introduced in revision
> 1.3628 on 2017-10-13 where new buffers were always assigned number 1.
Well, couldn't it become more simple? The following is my change
slightly modified from the last one. There seems to be no defect
so far.
--- w3m-util.el~ 2018-02-05 01:24:42.346587300 +0000
+++ w3m-util.el 2018-02-15 07:49:52.626357200 +0000
@@ -450,11 +450,12 @@
(setq name (substring name 0 (match-beginning 0))))
(let* ((w3m-fb-mode nil)
(buffers (w3m-list-buffers))
- (regexp (concat "\\`" (regexp-quote name) "\\(?:<[0-9]+>\\)?\\'"))
(siblings (delq nil
(mapcar
(lambda (buffer)
- (when (string-match regexp (buffer-name buffer))
+ (when (string-match
+ "\\*w3m\\*\\(?:<[0-9]+>\\)?\\'"
+ (buffer-name buffer))
buffer))
buffers)))
youngers cur number num)