GNU bug report logs - #51753
ERC switches to channel buffer on reconnect

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51753 in the body.
You can then email your comments to 51753 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: bug-gnu-emacs <at> gnu.org
Subject: ERC switches to channel buffer on reconnect
Date: Wed, 10 Nov 2021 07:09:24 -0800

Severity: important

When ERC reconnects, it switches buffer to the channel buffers.  This is
*very* dangerous.

Consider the situation when the user is about to paste a password and
hit enter with a quick "C-y RET", when all of a sudden the ERC buffer
pops up a fraction of a second before you hit those keys.  Now your
password is on IRC.

At the very least, this behavior should be disabled by default, and
preferably also come with a big warning sign for anyone that intends to
enable it.

Message #8 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org, Amin Bandali <bandali <at> gnu.org>
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Wed, 10 Nov 2021 19:14:29 -0800

Stefan Kangas <stefan <at> marxist.se> writes:

> Severity: important
>
> When ERC reconnects, it switches buffer to the channel buffers.  This is
> *very* dangerous.

Hi Stefan. Any idea if this is a recent phenomenon or more along the
lines of traditional behavior, perhaps involving `erc-join-buffer', for
example? I ask this mostly out of self interest re

  commit 17e7cab1507a185d2c493548494abcad6a55d159
  Normalize usage of variable erc-server-reconnecting

and its followup

  commit ec9ddd6eaf3f1b118d3ce95a69e1d046166362d3
  Deprecate instead of redefine erc-server-reconnecting

(both recent and both mine).

Regardless, there's a solid chance what you're experiencing is
`erc-setup-buffer' related, which comes into play whenever `erc-open'
runs. For reconnects, this happens both during `erc-server-reconnect'
and again whenever `erc-server-JOIN' runs (for channels you join).

It'd also be nice to know how these JOIN replies are being triggered
(server-initiated, erc-join.el, manual /join, etc.). With the join
module, they'd likely be the result of a JOIN command (request) sent by
`erc-autojoin-channels', which runs on 376/422. This matters when trying
to pinpoint problematic interplay with the reconnect logic, if such a
thing exists.

> Consider the situation when the user is about to paste a password and
> hit enter with a quick "C-y RET", when all of a sudden the ERC buffer
> pops up a fraction of a second before you hit those keys.  Now your
> password is on IRC.
>
> At the very least, this behavior should be disabled by default, and
> preferably also come with a big warning sign for anyone that intends to
> enable it.

I don't think many would argue that this behavior isn't at least
annoying. While specific scenarios (like accidentally broadcasting creds
to a channel) are important to confront, we should also remember to take
in the long view whenever possible (IMO). And in doing so, I think we'll
find that the many downsides of interfacing with a services bot have
over time compelled the IRC world to embrace SASL (part of the IRCv3
initiative) as the preferred means of authentication. Thanks.

Message #11 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: Amin Bandali <bandali <at> gnu.org>, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Thu, 11 Nov 2021 04:29:43 +0100

"J.P." <jp <at> neverwas.me> writes:

> Hi Stefan. Any idea if this is a recent phenomenon or more along the
> lines of traditional behavior, perhaps involving `erc-join-buffer', for
> example?

erc has behaved this way as long as I can remember, and it's really
annoying (especially when a server bounces and erc reconnects, popping
up windows everywhere while I'm trying to get some work done).

So I'm all for making erc stopping doing this.

erc does not pop up windows when somebody messages you (but just
displays something in the mode line), and I think that's what erc should
do for all buffers (by default; there could be a user option to allow it
to pop up windows, of course).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #14 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Wed, 10 Nov 2021 21:13:07 -0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> erc does not pop up windows when somebody messages you (but just
> displays something in the mode line), and I think that's what erc should
> do for all buffers (by default; there could be a user option to allow it
> to pop up windows, of course).

The simplest approach might be to just change the default values of
`erc-join-buffer' and `erc-auto-query' to 'bury. However, if people want
something different to happen when automatically reconnecting, we'd
probably have to remember whether `erc-server-reconnect-count' was ever
positive before crossing the logical connection threshold for the
current session.

This may come down to having `erc-connection-established' record the
count prior to resetting it (perhaps in a new, internal variable). And
then, during re-JOINs, `erc-setup-buffer' could weigh that recorded
value against some new option, like an `erc-display-reconnect' (or
whatever), and proceed accordingly.

Message #17 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: Stefan Kangas <stefan <at> marxist.se>, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Thu, 11 Nov 2021 06:22:06 +0100

"J.P." <jp <at> neverwas.me> writes:

> The simplest approach might be to just change the default values of
> `erc-join-buffer' and `erc-auto-query' to 'bury.

Yup.

> However, if people want something different to happen when
> automatically reconnecting, we'd probably have to remember whether
> `erc-server-reconnect-count' was ever positive before crossing the
> logical connection threshold for the current session.
>
> This may come down to having `erc-connection-established' record the
> count prior to resetting it (perhaps in a new, internal variable). And
> then, during re-JOINs, `erc-setup-buffer' could weigh that recorded
> value against some new option, like an `erc-display-reconnect' (or
> whatever), and proceed accordingly.

Sounds good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Fri, 19 Nov 2021 02:36:40 -0800

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> However, if people want something different to happen when
>> automatically reconnecting, we'd probably have to remember whether
>> `erc-server-reconnect-count' was ever positive before crossing the
>> logical connection threshold for the current session.
>>
>> This may come down to having `erc-connection-established' record the
>> count prior to resetting it (perhaps in a new, internal variable). And
>> then, during re-JOINs, `erc-setup-buffer' could weigh that recorded
>> value against some new option, like an `erc-display-reconnect' (or
>> whatever), and proceed accordingly.
>
> Sounds good to me.

I wasn't sure if that meant I was supposed to work on this. If not,
please disregard.

Otherwise, the tests are in #48598 [1]. As for the name of the option
itself, I basically punted by going with `erc-reconnect-buffer' to try
and stay close to `erc-join-buffer'. If that doesn't matter, perhaps
`erc-reconnect-display' would be a better fit since we already have an
`erc-query-display' (even though that one's not as closely related).
Anyone with an opinion, please advise. Thanks.


[1] Around line 4736:

    https://gitlab.com/jpneverwas/erc-tools/-/raw/master/bugs/48598/patches/wip/0013-Update-ERC-scenarios-with-session-centric-naming.patch

    Or browsable (JS):

    https://gitlab.com/jpneverwas/erc-v3/-/blob/1333bda3c0d11ff06b1b2acbb27864c90d5ba303/test/erc-scenarios.el#L1668

[0001-Customize-displaying-of-ERC-buffers-on-reconnect.patch (text/x-patch, attachment)]

Message #23 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: "J.P." <jp <at> neverwas.me>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org, Amin Bandali <bandali <at> gnu.org>
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Fri, 19 Nov 2021 12:45:14 +0100

tags 51753 + patch
thanks

"J.P." <jp <at> neverwas.me> writes:

> I wasn't sure if that meant I was supposed to work on this. If not,
> please disregard.

You did exactly the right thing here.  Thank you for working on this!

> Otherwise, the tests are in #48598 [1]. As for the name of the option
> itself, I basically punted by going with `erc-reconnect-buffer' to try
> and stay close to `erc-join-buffer'. If that doesn't matter, perhaps
> `erc-reconnect-display' would be a better fit since we already have an
> `erc-query-display' (even though that one's not as closely related).
> Anyone with an opinion, please advise. Thanks.

On balance, I don't have a strong opinion either way.  (I do like
`erc-reconnect-display' slightly better, because many variables that end
with `-buffer' have to do with the _name_ of some buffer.  But it is
true that it is also nice to have a name similar to `erc-join-buffer'.)

I just have some minor nits below:

> +(defvar-local erc--server-last-reconnect-count 0
> +  "Snapshot of reconnect count when connection established.")

"when the connection was established", perhaps?

> +(defcustom erc-reconnect-buffer nil
> +  "How (and whether) to display a channel buffer upon reconnecting.
> +
> +This only affects automatic reconnections and is ignored when issuing a
> +/reconnect command or reinvoking `erc-tls' with the same args (assuming
> +success, of course).  See `erc-join-buffer' for a description of
> +possible values."
> +  :group 'erc-buffers
> +  :type '(choice (const :tag "Use value of `erc-join-buffer'" nil)
> +                 (const :tag "Split window and select" window)
> +                 (const :tag "Split window, don't select" window-noselect)
> +                 (const :tag "New frame" frame)
> +                 (const :tag "Bury in new buffer" bury)
> +                 (const :tag "Use current buffer" buffer)
> +                 (const :tag "Use current buffer" t)))

What is the difference between `buffer' and t?  Should they really have
the same :tag?

If they are just two names for the same thing, I suggest we drop one of
them.

Other than that, LGTM (but I didn't test it).

Message #28 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>, 51753 <at> debbugs.gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Fri, 19 Nov 2021 05:13:58 -0800

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefan <at> marxist.se> writes:

> On balance, I don't have a strong opinion either way.  (I do like
> `erc-reconnect-display' slightly better, because many variables that end
> with `-buffer' have to do with the _name_ of some buffer.  But it is
> true that it is also nice to have a name similar to `erc-join-buffer'.)

Screw it. Let's go with `erc-reconnect-display'.

> I just have some minor nits below:
>
>> +(defvar-local erc--server-last-reconnect-count 0
>> +  "Snapshot of reconnect count when connection established.")
>
> "when the connection was established", perhaps?

Now reads as ^.

> What is the difference between `buffer' and t?  Should they really have
> the same :tag?

No idea to both, unfortunately. But since the option is only used in
that one function (`erc-setup-buffer'), and since we don't claim
like-for-like compatibility with `erc-join-buffer' (which we've already
deviated from anyway by offering a choice of nil) ...

> I suggest we drop one of them.

Agreed. Thanks.

[0000-v1-v2.diff (text/x-patch, attachment)]

[0001-Customize-displaying-of-ERC-buffers-on-reconnect.patch (text/x-patch, attachment)]

Message #31 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>, 51753 <at> debbugs.gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Fri, 19 Nov 2021 23:21:59 -0800

It just occurred to me that we may also want to reset
`erc--server-last-reconnect-count' at some point after all (re)JOINing
is done with (both client- and server-initiated) so that the option
`erc-join-buffer' regains precedence over `erc-reconnect-display' for
the remainder of the connection. Doing so in `erc-cmd-JOIN' would cover
manually issued /JOINs as well as invocations of `erc-join-channel'.

Message #34 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: "J.P." <jp <at> neverwas.me>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>, 51753 <at> debbugs.gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Sat, 20 Nov 2021 10:09:08 +0100

"J.P." <jp <at> neverwas.me> writes:

> It just occurred to me that we may also want to reset
> `erc--server-last-reconnect-count' at some point after all (re)JOINing
> is done with (both client- and server-initiated) so that the option
> `erc-join-buffer' regains precedence over `erc-reconnect-display' for
> the remainder of the connection. Doing so in `erc-cmd-JOIN' would cover
> manually issued /JOINs as well as invocations of `erc-join-channel'.

Sounds good to me.

Message #37 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>, 51753 <at> debbugs.gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Sun, 21 Nov 2021 14:54:14 -0800

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefan <at> marxist.se> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>> It just occurred to me that we may also want to reset
>> `erc--server-last-reconnect-count' at some point after all (re)JOINing
>> is done with (both client- and server-initiated) so that the option
>> `erc-join-buffer' regains precedence over `erc-reconnect-display' for
>> the remainder of the connection. Doing so in `erc-cmd-JOIN' would cover
>> manually issued /JOINs as well as invocations of `erc-join-channel'.
>
> Sounds good to me.

Great. Added. Thanks.


Updated tests: https://gitlab.com/jpneverwas/erc-v3/-/blob/454ef4674af3d784bb47a81db5e7d526fb30a705/test/erc-scenarios.el#L1642

[0000-v2-v3.diff (text/x-patch, attachment)]

[0001-Customize-displaying-of-ERC-buffers-on-reconnect.patch (text/x-patch, attachment)]

Message #40 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: "J.P." <jp <at> neverwas.me>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>, 51753 <at> debbugs.gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Thu, 2 Dec 2021 11:43:03 -0800

"J.P." <jp <at> neverwas.me> writes:

> Great. Added. Thanks.

Amin, what do you think of this patch?

Message #43 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 Amin Bandali <bandali <at> gnu.org>, 51753 <at> debbugs.gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Thu, 02 Dec 2021 21:31:24 -0800

These are just some related notes, mostly intended for posterity. Feel
free to ignore. Thanks.


I think at some point it'll be worth exploring the best time and place
for forgetting the current connection's origins with respect to whether
it sprang from an automated reconnect. The latest iteration of this
patch does this via `erc-cmd-JOIN'. But that's a bit of a compromise and
one that will hopefully be replaced with something smarter down the
road.

Ideally, resetting would occur immediately after all reconnect-related
JOINs have happened. As might be obvious, doing this ultimately involves
tracking more state, including but not limited to "JOINedness". In the
case of server-initiated joins, that implies doing so across sessions
[1]. For client-initiated ones, it means tracking request context. While
IRCv3 features like "label responses" were designed specifically to
assist with the latter [2], that doesn't mean we can't do so manually,
given sufficient motivation.

Indeed, when armed with a reliable way to uniquely identify a "logical"
channel subscription across connections [3], it becomes possible to do
this manually by stashing callbacks or continuation instructions. (Some
people may know this as the "command" pattern.) The real question then
becomes whether it's worth the added complexity.

BTW, if anyone has alternative ideas for a temporary solution (other
than `erc-cmd-JOIN'), please speak up. I originally thought about doing
the resetting in a subset of /CMDs originating from typed user input,
but that seemed more prone to inconveniencing users who may have long
incorporated the underlying functions into custom code (firing on
connection) [4]. One way around this would be to only do the resetting
when a user actually enters something at the prompt, but unless you want
that to happen on *any* /CMD, we'd need special handling [5] for the
handful desired (possibly chosen via configurable option).


~~~

[1] A related issue is the means of detecting whether we're joined to a
    channel. With traditional pub/sub services (IRC channels are really
    just "topics"), it's in the client's interest to stay abreast of its
    subscription status. And the service API also typically exposes a
    way for a client to query for this out of band. ERC *does* track a
    channel's JOIN'd state, but it's a bit hampered by legacy features
    related to how targets are currently handled (via
    `erc-default-recipients' and functions that access/mutate it).

[2] https://ircv3.net/irc/#labeled-responses

[3] "Logical" meaning including serially, i.e., spanning disconnects.

[4] In ERC's case, these commands aren't designated as being primarily
    intended for /interactive use (`erc-cmd-JOIN`, being one such
    function, naturally suffers from the same flaw).

[5] Hopefully something more flexible than adding/removing properties,
    like `process-not-needed', which creates problems when trying to
    override /CMDs.

Message #48 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Sun, 22 May 2022 18:56:07 -0700

[Message part 1 (text/plain, inline)]

Hi Pankaj,

Pankaj Jangid <pankaj <at> codeisgreat.org> writes:

> 5. While it is connecting to the server, switch to the other frame to
>    work on other stuff
>
> Result: After the ERC connects to the server, it opens the autojoin
> channels in the current frame. Ideally, it should open the channels in
> the (dedicated) original frame where ERC was launched.

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?

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.

Thanks,
J.P.

[0001-Allow-erc-reuse-frames-to-favor-connections.patch (text/x-patch, attachment)]

Message #51 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Mon, 23 May 2022 08:20:32 +0530

"J.P." <jp <at> 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.

Message #54 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 51753 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Mon, 23 May 2022 00:48:57 -0700

[Message part 1 (text/plain, inline)]

Pankaj Jangid <pankaj <at> codeisgreat.org> writes:

> "J.P." <jp <at> 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.

Thanks for trying out that patch. Basically, I bungled a few things that
prevented it from faithfully representing #2, even though I claimed
otherwise (sorry). IOW, I'm saying the approach may be salvageable and
only the implementation flawed.

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

Right, it seems I blindly fixated on the segregation aspect of your
description (again, apologies) and glossed over the obvious fact that
you don't want ERC creating frames, period. I've adapted the existing
patch with this in mind in hopes you're willing to try again.

One thing to be aware of is that even if we pivot to #1, the
connection-detection and buffer-association stuff will still be
unreliable in many cases. However, that should change after bug#48598
lands. That said, if you still feel strongly about #1, then please say
so (others following along as well). And likewise if you have
suggestions on the implementation or would like to try taking the wheel.
Thanks.

[0000-v1-v2.diff (text/x-patch, attachment)]

[0001-Allow-erc-reuse-frames-to-favor-connections.patch (text/x-patch, attachment)]

Message #57 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame
Date: Wed, 10 Aug 2022 06:15:52 -0700

[Message part 1 (text/plain, inline)]

Hi Pankaj,

"J.P." <jp <at> neverwas.me> writes:

> One thing to be aware of is that even if we pivot to #1, the
> connection-detection and buffer-association stuff will still be
> unreliable in many cases. However, that should change after bug#48598
> lands.

The changes I was referring to have been on HEAD for over a month now,
but I've been slow in getting back around to this bug (sorry). In case
you or anyone else is interested, I've reworked things a bit to leverage
the new buffer-association stuff, which should make finding a suitable
frame more reliable. You still have to set the options as initially
described up thread. Thanks.

[0000-v2-v3.diff (text/x-patch, attachment)]

[0001-Allow-erc-reuse-frames-to-favor-connections.patch (text/x-patch, attachment)]

Message #60 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame
Date: Thu, 11 Aug 2022 08:25:42 +0530

"J.P." <jp <at> neverwas.me> writes:

> The changes I was referring to have been on HEAD for over a month now,
> but I've been slow in getting back around to this bug (sorry). In case
> you or anyone else is interested, I've reworked things a bit to leverage
> the new buffer-association stuff, which should make finding a suitable
> frame more reliable. You still have to set the options as initially
> described up thread. Thanks.

I will try this change tomorrow, and report. Thanks for the
updated. Thanks for your work.

Message #63 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 55540 <at> debbugs.gnu.org, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 "J.P." <jp <at> neverwas.me>
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Tue, 06 Sep 2022 13:01:51 +0200

erc still pops up the buffer by default, I think?  I don't think it
should do that, because it's both pretty annoying and a security
issue -- you may suddenly be typing a password into an erc buffer.

Message #68 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55540 <at> debbugs.gnu.org, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Pankaj Jangid <pankaj <at> codeisgreat.org>
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Tue, 06 Sep 2022 06:53:34 -0700

Hi Lars,

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> erc still pops up the buffer by default, I think?  I don't think it
> should do that, because it's both pretty annoying and a security
> issue -- you may suddenly be typing a password into an erc buffer.

Are you concerned about the behavior during initial connections as well
as automatic reconnections? Regardless, as you say, the default value of
`buffer' for `erc-join-buffer' (and `erc-reconnect-display') causes the
buffer in the selected window to be replaced with the
just-(re)initialized ERC buffer.

Also, depending on various factors, values other than `buffer' can
exhibit similar behavior. For example, in a dual-window split, a value
of `window-noselect' can result in a newly (re)joined channel replacing
the buffer in the selected window when the connection's server buffer is
showing in the other window. Plain `window' is much the same, but at
least there's somewhat of an expectation that the selected window's
buffer may change.

Really, the only safe option is `bury' (well, maybe also the proposed
frame stuff in Pankaj's patch, but only when an extra, ERC-specific
frame already exists, which we can't count on). That said, there's no
reason we'd have to stick with existing options/behavior when choosing a
new default. I guess it just comes down to what users want to happen.

If we're talking both `erc-join-buffer' and `erc-reconnect-display', one
idea would be to make `window-noselect' the default but change it to
mean the selected window is always left unmolested, no matter what. The
justification for the breaking change would be that the existing doc
string in

  (const :tag "Split window, don't select" window-noselect)

has always implied as much, namely that a window displaying the new
buffer will always be shown and never selected.

Although, if this only concerns `erc-reconnect-display', we could just
go with `bury' since (among the available options) that best minimizes
the disruption of a reestablished connection.

Hopefully folks have stronger opinions and/or better ideas. Thanks.

Message #71 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 55540 <at> debbugs.gnu.org, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Pankaj Jangid <pankaj <at> codeisgreat.org>
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Tue, 06 Sep 2022 16:02:32 +0200

"J.P." <jp <at> neverwas.me> writes:

> Are you concerned about the behavior during initial connections as well
> as automatic reconnections?

Yes.

> Really, the only safe option is `bury' (well, maybe also the proposed
> frame stuff in Pankaj's patch, but only when an extra, ERC-specific
> frame already exists, which we can't count on). That said, there's no
> reason we'd have to stick with existing options/behavior when choosing a
> new default. I guess it just comes down to what users want to happen.

I think the default action should be to do nothing to the window setup
at all, and just add the notification to the mode line.

Message #74 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55540 <at> debbugs.gnu.org, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Pankaj Jangid <pankaj <at> codeisgreat.org>
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Tue, 06 Sep 2022 20:10:23 -0700

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>> Really, the only safe option is `bury' (well, maybe also the proposed
>> frame stuff in Pankaj's patch, but only when an extra, ERC-specific
>> frame already exists, which we can't count on). That said, there's no
>> reason we'd have to stick with existing options/behavior when choosing a
>> new default. I guess it just comes down to what users want to happen.
>
> I think the default action should be to do nothing to the window setup
> at all, and just add the notification to the mode line.

I believe changing the default for `erc-join-buffer' (alone) to `bury'
is the easiest way to achieve that.

Thus, if no one objects within the next week or so, I will add the patch
below or similar to trunk (and what will become ERC 5.5), along with a
related NEWS entry. Thanks.

[0001-Bury-new-ERC-buffers-by-default.patch (text/x-patch, attachment)]

Message #77 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 55540 <at> debbugs.gnu.org, 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Pankaj Jangid <pankaj <at> codeisgreat.org>
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Wed, 07 Sep 2022 14:55:47 +0200

"J.P." <jp <at> neverwas.me> writes:

> I believe changing the default for `erc-join-buffer' (alone) to `bury'
> is the easiest way to achieve that.
>
> Thus, if no one objects within the next week or so, I will add the patch
> below or similar to trunk (and what will become ERC 5.5), along with a
> related NEWS entry. Thanks.

Thanks; makes sense to me.

Message #80 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 55540 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 emacs-erc <at> gnu.org, 51753 <at> debbugs.gnu.org
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Tue, 20 Sep 2022 06:11:11 -0700

>> Thus, if no one objects within the next week or so, I will add the patch
>> below or similar to trunk (and what will become ERC 5.5), along with a
>> related NEWS entry. Thanks.

This has been carried out.

Pankaj, all that remains is your frame stuff. If problems persist and/or
you've lost interest, please let us know, so I can act accordingly.
Thanks.

Message #83 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 55540 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 emacs-erc <at> gnu.org, 51753 <at> debbugs.gnu.org
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Thu, 22 Sep 2022 08:37:02 +0530

"J.P." <jp <at> neverwas.me> writes:

>>> Thus, if no one objects within the next week or so, I will add the patch
>>> below or similar to trunk (and what will become ERC 5.5), along with a
>>> related NEWS entry. Thanks.
>
> This has been carried out.
>
> Pankaj, all that remains is your frame stuff. If problems persist and/or
> you've lost interest, please let us know, so I can act accordingly.
> Thanks.

Now the behaviour is acceptable when "erc-autojoin-channels-alist" is
set to nil. i.e. the frame in which I launched "erc-tls" opens the erc
window instead of occupying the current frame.

But when I have few channels in "erc-autojoin-channels-alist" then the
channels are still openning in the current frame instead of the
dedicated frame that I started for "erc-tls". Is there some setting that
I missed in the conversation for this? My current "erc" related
settings are:

--8<---------------cut here---------------start------------->8---
(setq erc-prompt-for-password nil
      erc-prompt (lambda () (concat "[" (buffer-name) "]")))
(eval-when-compile (require 'erc-services))
(setq erc-prompt-for-nickserv-password nil
      erc-use-auth-source-for-nickserv-password t)
(setq erc-server "irc.libera.chat")
(setq erc-port 6697)
(setq erc-nick "my-nick")
(setq erc-user-full-name "My Full Name")
(eval-when-compile (require 'erc-join))
(setq erc-autojoin-channels-alist
      '(("libera.chat" "#emacs" "#erc" "#gnus")))
--8<---------------cut here---------------end--------------->8---

Message #86 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 55540 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 emacs-erc <at> gnu.org, 51753 <at> debbugs.gnu.org
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Wed, 21 Sep 2022 23:22:50 -0700

Hi Pankaj,

Pankaj Jangid <pankaj <at> codeisgreat.org> writes:

> Now the behaviour is acceptable when "erc-autojoin-channels-alist" is
> set to nil. i.e. the frame in which I launched "erc-tls" opens the erc
> window instead of occupying the current frame.

Hm, right, but I think that was always the baseline behavior, no? If
not, I wonder if the recent change to the default for `erc-join-buffer'
somehow affected this.

> But when I have few channels in "erc-autojoin-channels-alist" then the
> channels are still openning in the current frame instead of the
> dedicated frame that I started for "erc-tls". Is there some setting
> that I missed in the conversation for this?

Looks like it, but I should have re-summarized either way. So that's my
bad.

> (setq erc-prompt-for-nickserv-password nil
>       erc-use-auth-source-for-nickserv-password t)

This is unrelated (so feel free to skip ahead), but are you sure
auth-source is even being consulted here? I ask because `services' isn't
a default module, and your snippet doesn't modify `erc-modules', AFAICT.
Regardless, adding services to the repro mix at this point would only
complicate matters, so please forget I said anything. I mean, if really
necessary, you can just use Libera's server-password kludge while
testing (everything will still be encrypted):

  (erc-tls :password "$myaccount:$mypass" ...)

> [...]
> (setq erc-autojoin-channels-alist
>       '(("libera.chat" "#emacs" "#erc" "#gnus")))

Ah, looks like we're missing

  (setq erc-join-buffer 'frame
        erc-auto-query 'frame
        erc-reuse-frames 'displayed)

Also, you *did* apply the patch and rerun make (or at least delete the
.elc), right?:

  https://lists.gnu.org/archive/html/emacs-erc/2022-08/txtAqY2ukHPun.txt

(Yeah, those changes aren't on trunk.) Anyway, please let me know if
something doesn't add up.

Thanks,
J.P.

P.S. If you want, you can use the symbol `Libera.Chat' instead of the
string "libera.chat" in `erc-autojoin-channels-alist'.

Message #89 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 55540-done <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 emacs-erc <at> gnu.org, 51753 <at> debbugs.gnu.org
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Sat, 08 Apr 2023 16:25:13 -0700

I've added a version of the frames patch as well as an option to control
buffer-display behavior for interactive entry-point invocations.

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e4c07dc
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3a012d1d

Thanks and closing.

Message #92 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 51753 <at> debbugs.gnu.org
Subject: Re: bug#55540: 29.0.50; ERC launches autojoin-channels in current
 frame instead of original frame
Date: Fri, 14 Apr 2023 07:11:49 -0700

Just a breadcrumb for posterity: I've opened a related bug that picks up
where this one left off:

  bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.