[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bugs related to tabs
- From: Boruch Baum <boruch_baum@xxxxxxx>
- Date: Wed, 22 May 2019 07:59:45 -0400
- X-ml-name: emacs-w3m
- X-mail-count: 13419
- References: <b4mo93vhtd4.fsf@jpl.org>
On 2019-05-22 15:54, Katsumi Yamaoka wrote:
> ...
> 1.
> In the emacs-w3m home page <http://emacs-w3m.namazu.org/>,
> when I type <S-return> (`w3m-view-this-url-new-session') on
> the name link `Features', the new tab appears and it shows
> the Features section of the page. That's ok. However, if I
> switch the tab to the original one, I can see the Features
> section shown also there. But what the original tab displays
> should not be changed of course.
I can reproduce this bug by performing "M-x
w3m-view-this-url-new-session" and "C-u C-u M-x w3m-view-this-url", but
it does seem to function correctly when performing "M-x
w3m-goto-url-new-session".
> 2.
> Clicking mouse-1, mouse-2, or C-mouse-wheel, etc. on a tab
> causes this error (it happens regardless of the number of tabs):
>
> Debugger entered--Lisp error: (error "Attempt to display deleted buffer")
> set-window-buffer(nil #<killed buffer>)
> switch-to-buffer(#<killed buffer>)
> w3m-tab-click-mouse-function((mouse-1...) #<killed buffer>)
> [...]
I can't reproduce this right now; I'm stuck on a non-gui system, and am
running emacs-nw.
> 3.
> `M-n' (`w3m-copy-buffer') creates a new tab that is a copy of
> the original. However, the new tab is not selected.
That default behavior should be controlled by variable
`w3m-new-session-in-background', and you should be able to temporarily
change the default behavior by using the prefix argument `C-u'.
> In addition, the place where the new tab appears does not get always
> the (left)[right]most of the tabs as the case may be. This seems to
> happen after creating a copy of a tab and further creating a new tab
> by `G' (`w3m-goto-url-new-session'), etc. In that case `C-c C-p'
> (`w3m-previous-buffer') and `C-c C-n' (`w3m-next-buffer') do not work
> correctly either.
I'm not reproducing this.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0