fb-mode [BUG REPORT]

[Boruch Baum <boruch_baum@xxxxxxx>]

I've just now been testing fb-mode, and the way it seems to be working
for me is different from what I understood would be the case from the
documentation, and there are clearly some bugs in it, so I thought it
would be useful to share my understanding and get feedback from others,
with the goal of getting a clear idea of exactly what its doing, and
what it is suposed to be doing - and maybe modify the documentation.

My test environment is emacs-nox v25.2, so my frame management is
performed using `C-x 5' commands: `0' to delete a frame, `2' to create
one, `,' to rename one (very useful), and `b' to switch between them.
The current frame name appears on the left side of my mode line.

I know of two methods of switching between emacs-w3m buffers: Using the
function `w3m-select-buffer' bound I think by default to `C-c C-s', but
I have it bound to `M-t', and using emacs' native switch buffer command
`C-x b'.

When I enable `w3m-fb-mode', I get a confirmation message that the mode
is enabled, and can create isolated sessions in separate frames.


POSSIBLE BUG #1
===============
However, that isolation can be easily broken by switching to an
emacs-w3m buffer using `C-x b'.


DEFINITE BUG #2
===============
w3m-fb-mode breaks when deleting all buffers of one session.

M-x w3m-fb-mode  ; get message that it's enabled
M-x w3m          ; get home page
C-x 5 b          ; other frame
M-x w3m          ; get home page in isolated session
g <some url#1    ; still only one buffert
C-c C-s          ; verify still only one buffer
C-g   t          ; back to w3m
C-x 5 b          ; back to original frame
G <some url#2>   ; second tab
C-c C-s          ; verify only two tabs
d                ; twice, to delete both tabs

At this point, I am prompted "kill emacs-w3m on other frames" and answer
no.

2.1 The result should be some other emacs buffer, but what happens is
    that emacs displays tthe w3m instance from the other frame - even
    though fb mode is enabled. To verify, perform M-: w3m-fb-mode (not
    in parentheses) and get result `t', or toggle the mode using M-x
    w3m-fb-mode.

2.2 Further, perform `C-x 5 b', and see that the session is
    visible on BOTH frames!

2.3 Now, press `Q' and receive a prompt asking whether to kill sessions
    on other frames. But there should only be a single session active at
    this point! Answer no, and switch to the other frame, and see that
    either the session still exists there, or that it was somehow
    duplicated.

BUG #3
======
Saving a session seems to only save buffers associated with the current
frame.

At first glance, this kind of makes sense, since the buffers are
supposed to be isolated, but if you look at the session list (M-s),
you'll notice that there is only a single "crash recovery session" and
it does not contain all the buffers from all the current sessions, so in
the event of a crash, recovery information for only one frame session
would be available.

Also, the automatically saved sessions seem to be incomplete.

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