[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for bug in w3m-generate-new-buffer
> 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).
Ok. My reading of the Changelog was that copying the Firefox behavior
was the intention. I think this is a desirable feature -
W3M-VIEW-THIS-URL-NEW-SESSION should open new links in the adjacent tab.
> 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.
This is the broken behavior from revision 1.184 that my patch fixes.
W3M-DELETE-BUFFER does the wrong thing because W3M-NEXT-BUFFER was not
working properly. It looks like you were not running my patch, or you
had opened tabs before applying my patch and those tabs had the wrong
number/order. How did you make those buffers when you observed the
behavior (did you make some of them before applying my or your
patch?), and what was the value of (mapcar #'w3m-buffer-number
> 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
> (lambda (buffer)
> - (when (string-match regexp (buffer-name buffer))
> + (when (string-match
> + "\\*w3m\\*\\(?:<[0-9]+>\\)?\\'"
> + (buffer-name buffer))
> youngers cur number num)
This change does not fix anything, it just seems to make it never
execute the PROGN clause in lines 464-473. All new tabs go to the end.
The buggy code in lines 464-473 just sits there and does nothing.
Can you please apply my patch?