Re: bugs related to tabs

[Katsumi Yamaoka <yamaoka@xxxxxxx>]

I realized those three bugs all started with the commit 1870402:
,----
| commit 1870402fd2c46ff47c115d3aa7cd455935ec96c8
| Author: Boruch Baum <boruch_baum@xxxxxxx>
| Date:   Mon Apr 15 10:15:58 2019 -0400
|
|     BUGFIX: allow new tabs to be loaded in background
`----

> 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.

> 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 found a certain recipe to reproduce this.  That is, launch
emacs-w3m with a single tab, create two copies of the tab by
typing `M-n' twice, delete the first tab, and do some mouse
operations on the tabs.

Where #<killed buffer> has to be the w3m-mode buffer with which
the tab is associated.  That buffer object should be embedded in
the mouse command definitions that `w3m-tab-make-keymap' creates
one by one for the w3m-mode buffers independently.
I guess the cause is that the `w3m-mode' function, that runs
`w3m-tab-make-keymap' by way of the `w3m-mode-setup-functions'
hook, is not made run in the copied buffers.

> 3.
>   `M-n' (`w3m-copy-buffer') creates a new tab that is a copy of
> the original.  However, the new tab is not selected.

I found out that this symptom happens in the condition where
`w3m-use-title-buffer-name' is non-nil.  To reproduce it, launch
emacs-w3m and visit two different web sites in two buffers (tabs),
and type `M-n' in the second buffer.

>   In addition, the place where the new tab appears does not get
> always the leftmost 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.

In [emacs-w3m:13419]
On Wed, 22 May 2019 07:59:45 -0400, Boruch Baum wrote:
>> 2.
[...]
> I can't reproduce this right now; I'm stuck on a non-gui system, and am
> running emacs-nw.

Since emacs-w3m goes on the rolling release policy, there would
be many people who are using the bleeding edge of the git repo.
So, whoever writes a code has to have an environment where it
is able to check the code in various ways as much as possible.

Although no one is perfect, and I'm not an exception either, I'd
say I'm now in the mood that I'd like to restart emacs-w3m from
the cvs2git tag that was labeled when the git repo started
(there, I'll exclude your all changes having been done after the
 tag except for the trivials including filters, etc., and won't
 merge your pull requests no more).

Regards,