[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: w3m-popup-buffer problem
TLDR; Although the bug had been reproducable, since performing `make
install' and killing all emacs processes, the bug hasn't been
reproducable. The remainder of this response is to record the issue in
case it does happen again reproducably.
On 2017-09-26 13:23, Katsumi Yamaoka wrote:
> In [emacs-w3m:12809]
> On Mon, 25 Sep 2017 23:04:03 -0400, Boruch Baum wrote:
> > Getting technical, when looking at function `w3m-popup-buffer' in file
> > w3m-util.el, I found that local variable `pop-up-frames' was being set
> > (line 583),
> Funny. It's set to nil in my case, and I couldn't found a way
> to set it to non-nil. So, the line 617 should never be executed
> and a hidden w3m buffer simply appears by M-x w3m RET.
Here are some possibly relevant variable settings:
+ w3m-use-tab is a variable defined in ‘w3m.el’. Its value is t
+ w3m-pop-up-frames is a variable defined in ‘w3m.el’. Its value is nil
+ w3m-pop-up-windows is a variable defined in ‘w3m.el’. Its value is t
+ w3m-new-session-in-background nil
> > What has fixed the situation for me was to change line 617:
> > - (pop-to-buffer buffer))
> > + (pop-to-buffer-same-window buffer))
Now, no longer necessary.
> > Values of some
> > of the other possibly relevant local variable were:
> > `window'=#<window 1 on *w3m*<3>>;
> > `frame'=#<frame F1 0xc3c680; and `oframe'=#<frame F46 0x152011e8>
> What a lot of frames you have in a -nw Emacs. Or is it a child
> that emacsclient launches? I couldn't reproduce the problem in
> such a condition either, though.
My guess is that the abundance of frames were probably created when an
outside script repeatedly ran `emacsclient --eval "(browse-url
\"$1\")"'. However, now even that is no longer reproducible - ie.
repeatedly invoking the script doesn't increase the number of frames to
more than two, per evaluating (frame-list) and (visible-frame-list).
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0