[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#51753: ERC switches to channel buffer on reconnect
From: |
Pankaj Jangid |
Subject: |
Re: bug#51753: ERC switches to channel buffer on reconnect |
Date: |
Mon, 23 May 2022 08:20:32 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
"J.P." <jp@neverwas.me> writes:
> Are you saying ERC ought to remember the frame in which an entry-point
> command, like `erc-tls', was originally invoked? Or might it be enough
> to make a best effort attempt at finding such a "dedicated" frame?
I have tried the #2 as specified below. I kind of agree that #1 will
result in the desired behaviour.
> If it's door #2, what if we used the first frame found containing a
> buffer belonging to the same connection (and if no such frame exists,
> just leave it up to the display-buffer gods)? This way, we could rely
> more fully on window.el facilities and avoid having to wrangle yet more
> state. Or, if really necessary, we could maybe fall back on a strategy
> that uses `window-prev-buffers' (or whatever) to find the most recently
> used frame for that connection (overkill, IMO). Either way, any solution
> would need to address not just autojoined channels but also
> server-initiated JOINs, PMs, etc.
>
> The attached patch claims to do something like I've described. If you're
> able to try it, please set these options beforehand:
>
> (setq erc-join-buffer 'frame
> erc-auto-query 'frame
> erc-query-display 'frame
> erc-reuse-frames 'displayed)
>
> If you're unable to try it, please let me know, and I can maybe add it
> temporarily to one of ERC's installable bug packages.
I tried this and here is what is happening.
I launched emacs then I launched another frame and M-x erc-tls and come
back to the 1st frame for other work. "erc-tls" running fine in the
other frame but when it starts to join autojoin channels after
connecting, it creates one more frame for each channel instead of
reusing the 2nd frame.