[feature/rcirc-update] Reconnects don't seem to work anymore

[feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Hi Philip,

at 11:59 I was disconnected from libera.chat.  In the server buffer I
have

  10:59 *** tsdh QUIT Ping timeout: 264 seconds

and in channels, there is

  0:59 !!! irc.libera.chat: connection broken by remote peer (closed)

Usually, if that happened I'd just `M-x rcirc RET' again, and it would
re-connect to all servers in `rcirc-server-alist' which are not
connected anymore.

Well, it still does that, i.e., I'm connected to irc.libera.chat again
in *irc.libera.chat* but all channel buffers of that network show
"(rcirc:disconnected)" in the mode-line and don't seem to receive any
messages anymore.

That's a thing which used to work before your patches, I think.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

> Hi Philip,
>
> at 11:59 I was disconnected from libera.chat.  In the server buffer I
> have
>
>   10:59 *** tsdh QUIT Ping timeout: 264 seconds
>
> and in channels, there is
>
>   0:59 !!! irc.libera.chat: connection broken by remote peer (closed)
>
> Usually, if that happened I'd just `M-x rcirc RET' again, and it would
> re-connect to all servers in `rcirc-server-alist' which are not
> connected anymore.

If you were to use /reconnect would that change anything? That is what I
tested, and I hope worked. But your method should continue working.

> Well, it still does that, i.e., I'm connected to irc.libera.chat again
> in *irc.libera.chat* but all channel buffers of that network show
> "(rcirc:disconnected)" in the mode-line and don't seem to receive any
> messages anymore.

I did encounter something similar, the issue was that rcirc-buffer-alist
was nil'ed unintentionally. What is the value of rcirc-buffer-alist in
the server buffer before and after reconnecting?

> That's a thing which used to work before your patches, I think.
>
> Bye,
> Tassilo

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

>> at 11:59 I was disconnected from libera.chat.  In the server buffer I
>> have
>>
>>   10:59 *** tsdh QUIT Ping timeout: 264 seconds
>>
>> and in channels, there is
>>
>>   0:59 !!! irc.libera.chat: connection broken by remote peer (closed)
>>
>> Usually, if that happened I'd just `M-x rcirc RET' again, and it would
>> re-connect to all servers in `rcirc-server-alist' which are not
>> connected anymore.
>
> If you were to use /reconnect would that change anything? That is what I
> tested, and I hope worked. But your method should continue working.

Not sure.  In the current state it just says "Server buffer is alive"
which is true.

>> Well, it still does that, i.e., I'm connected to irc.libera.chat
>> again in *irc.libera.chat* but all channel buffers of that network
>> show "(rcirc:disconnected)" in the mode-line and don't seem to
>> receive any messages anymore.
>
> I did encounter something similar, the issue was that
> rcirc-buffer-alist was nil'ed unintentionally. What is the value of
> rcirc-buffer-alist in the server buffer before and after reconnecting?

It still knows about the buffers:

--8<---------------cut here---------------start------------->8---
(("##rust" . #<buffer ##rust@irc.libera.chat>)
 ("#git" . #<buffer #git@irc.libera.chat>)
 ("#archlinux" . #<buffer #archlinux@irc.libera.chat>)
 ("#fsf-members" . #<buffer #fsf-members@irc.libera.chat>)
 ("#fsf" . #<buffer #fsf@irc.libera.chat>)
 ("#gnu" . #<buffer #gnu@irc.libera.chat>)
 ("#gnus" . #<buffer #gnus@irc.libera.chat>)
 ("#rcirc" . #<buffer #rcirc@irc.libera.chat>)
 ("#emacs-beginners" . #<buffer #emacs-beginners@irc.libera.chat>)
 ("#emacs" . #<buffer #emacs@irc.libera.chat>)
 ("#sway" . #<buffer #sway@irc.libera.chat>)
 ("#sr.ht" . #<buffer #sr.ht@irc.libera.chat>))
Local in buffer *irc.libera.chat*; global value is nil
--8<---------------cut here---------------end--------------->8---

I'm now restarting emacs.  The next time I get a disconnect, I'll try
/reconnect instead.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> If you were to use /reconnect would that change anything? That is what I
>> tested, and I hope worked. But your method should continue working.
>
> Not sure.  In the current state it just says "Server buffer is alive"
> which is true.

Yes, because the server buffer is reconnected. The issue is that the
existing buffers are not reused.

Another issue I also intend so solve is reconnecting to buffers used for
direct chat. These usually break and then I have to manually /msg the
other person again to continue a conversation.

>> I did encounter something similar, the issue was that
>> rcirc-buffer-alist was nil'ed unintentionally. What is the value of
>> rcirc-buffer-alist in the server buffer before and after reconnecting?
>
> It still knows about the buffers:
>
> (("##rust" . #<buffer ##rust@irc.libera.chat>)
>  ("#git" . #<buffer #git@irc.libera.chat>)
>  ("#archlinux" . #<buffer #archlinux@irc.libera.chat>)
>  ("#fsf-members" . #<buffer #fsf-members@irc.libera.chat>)
>  ("#fsf" . #<buffer #fsf@irc.libera.chat>)
>  ("#gnu" . #<buffer #gnu@irc.libera.chat>)
>  ("#gnus" . #<buffer #gnus@irc.libera.chat>)
>  ("#rcirc" . #<buffer #rcirc@irc.libera.chat>)
>  ("#emacs-beginners" . #<buffer #emacs-beginners@irc.libera.chat>)
>  ("#emacs" . #<buffer #emacs@irc.libera.chat>)
>  ("#sway" . #<buffer #sway@irc.libera.chat>)
>  ("#sr.ht" . #<buffer #sr.ht@irc.libera.chat>))
> Local in buffer *irc.libera.chat*; global value is nil

This is most unusual... I'll try to look into this.

> I'm now restarting emacs.  The next time I get a disconnect, I'll try
> /reconnect instead.
>
> Bye,
> Tassilo
>

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> I'm now restarting emacs.  The next time I get a disconnect, I'll try
> /reconnect instead.

I got disconnected from freenode, and this time I've tried /reconnect
instead of `M-x rcirc RET'.  However, that reconnected to the server but
again all channel buffers still show rcirc:disconnected.  The
`rcirc-buffer-alist' in the server buffer for freenode is still
populated with the right buffers as previously.

Also, after /reconnect it seems I got an error during nickserv
authentication as configured by `rcirc-authinfo':

--8<---------------cut here---------------start------------->8---
  (setq rcirc-authinfo
        `(("freenode" nickserv ,rcirc-default-nick ,th/nickserv-password-freenode)
          ("libera"   nickserv ,rcirc-default-nick ,th/nickserv-password-liberachat)
          ("oftc"     nickserv ,rcirc-default-nick ,th/nickserv-password-oftc)
          ("gnome"    nickserv "tsdh80"            ,th/nickserv-password-gnome)))
--8<---------------cut here---------------end--------------->8---

The error was:

--8<---------------cut here---------------start------------->8---
06:58 -*.freenode.net- *** You are connected to chat.freenode.net using TLS
                       (SSL) cipher 'TLSv1.3-TLS_AES_256_GCM_SHA384'
06:58 !!! "@msgid=446~1623712485~22272;inspircd.org/service;inspircd.org/bot
          :NickServ!services@services.freenode.net NOTICE tsdh :Nick tsdh
          isn't registered." (wrong-type-argument arrayp nil)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Hi again,

> The error was:
>
> 06:58 -*.freenode.net- *** You are connected to chat.freenode.net using TLS
>                        (SSL) cipher 'TLSv1.3-TLS_AES_256_GCM_SHA384'
> 06:58 !!! "@msgid=446~1623712485~22272;inspircd.org/service;inspircd.org/bot
>           :NickServ!services@services.freenode.net NOTICE tsdh :Nick tsdh
>           isn't registered." (wrong-type-argument arrayp nil)

I've just restarted, and it seems now one always gets this error when
authenticating to NickServ on freenode.  I also couldn't do

  /msg NickServ IDENTIFY my-password

or rather, I could, but then a user with nick N wrote back that I've
sent him my nickserv password.

Well, I guess it's time to leave freenode.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> I'm now restarting emacs.  The next time I get a disconnect, I'll try
>> /reconnect instead.
>
> I got disconnected from freenode, and this time I've tried /reconnect
> instead of `M-x rcirc RET'.  However, that reconnected to the server but
> again all channel buffers still show rcirc:disconnected.  The
> `rcirc-buffer-alist' in the server buffer for freenode is still
> populated with the right buffers as previously.

I am still not able to consistently reproduce this issue. Just to be
sure, what commit are you on?

> Also, after /reconnect it seems I got an error during nickserv
> authentication as configured by `rcirc-authinfo':
>
>   (setq rcirc-authinfo
>         `(("freenode" nickserv ,rcirc-default-nick ,th/nickserv-password-freenode)
>           ("libera"   nickserv ,rcirc-default-nick ,th/nickserv-password-liberachat)
>           ("oftc"     nickserv ,rcirc-default-nick ,th/nickserv-password-oftc)
>           ("gnome"    nickserv "tsdh80"            ,th/nickserv-password-gnome)))
>
>
> The error was:
>
> 06:58 -*.freenode.net- *** You are connected to chat.freenode.net using TLS
>                        (SSL) cipher 'TLSv1.3-TLS_AES_256_GCM_SHA384'
> 06:58 !!! "@msgid=446~1623712485~22272;inspircd.org/service;inspircd.org/bot
>           :NickServ!services@services.freenode.net NOTICE tsdh :Nick tsdh
>           isn't registered." (wrong-type-argument arrayp nil)

From your other message, it seems like this is specificity related to
freenode, right?

> Bye,
> Tassilo
>

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

Hi Philip,

>> Tassilo Horn <tsdh@gnu.org> writes:
>>
>>> I'm now restarting emacs.  The next time I get a disconnect, I'll try
>>> /reconnect instead.
>>
>> I got disconnected from freenode, and this time I've tried /reconnect
>> instead of `M-x rcirc RET'.  However, that reconnected to the server but
>> again all channel buffers still show rcirc:disconnected.  The
>> `rcirc-buffer-alist' in the server buffer for freenode is still
>> populated with the right buffers as previously.
>
> I am still not able to consistently reproduce this issue. Just to be
> sure, what commit are you on?

I'm on fd96e3a0d9.  I've just pulled again and 8 new commits appeared,
the oldest being from 5 days ago.  I'm pretty confident I've pulled at
least every other day in order to see if there's something new.  Did you
forget to push?

Anyway, I've updated to the current branch HEAD and restarted my
rcirc-emacs.

>> 06:58 -*.freenode.net- *** You are connected to chat.freenode.net using TLS
>>                        (SSL) cipher 'TLSv1.3-TLS_AES_256_GCM_SHA384'
>> 06:58 !!! "@msgid=446~1623712485~22272;inspircd.org/service;inspircd.org/bot
>>           :NickServ!services@services.freenode.net NOTICE tsdh :Nick tsdh
>>           isn't registered." (wrong-type-argument arrayp nil)
>
> From your other message, it seems like this is specificity related to
> freenode, right?

Yes, only freenode and only since today with no changes on rcirc in the
meantime.  When I do

    /msg nickserv help

in the *chat.freenode.org* buffer, I get the response

    20:42 *** 401 n No such nick

and in the buffer N@chat.freenode.org there is

    20:42 <tsdh> ickserv help

So now that user N has my nickserv password and I can't change it
because freenode seems broken...

I've asked on #help and the answers are:

  1. I should use "/ns IDENTIFY password" instead of "/msg NickServ".
  2. I should look into using SASL for identificiation.
  3. "/quote nickserv identify password" also gives an
     (wrong-type-argument arrayp nil) error but finally told be that
     tsdh is not a registered nick.

And then I was told that the original freenode with its user database is
now on classic.freenode.org and irc.freenode.org is something set up
completely anew without the previous data...

I was also told that "/msg foobar text" only works if the user foobar is
online.  If not, it'll select the first online user whose nick is a
prefix of foobar and send the remainder as message.  (That's why the
user N received my NickServ IDENTIFY message.)

I've just tried "/msg totototoXXX this is a test" on libera.chat and
it's the same there.  The user t received a message "otototoXXX this is
a test". :-(

So it would make sense that rcirc checked if there is an online user
NickServ before sending the IDENTIFY message to prevent password leakage
to random users as has happended to me.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Hi,

Tassilo Horn <tsdh@gnu.org> writes:

> I'm on fd96e3a0d9.  I've just pulled again and 8 new commits appeared,
> the oldest being from 5 days ago.  I'm pretty confident I've pulled at
> least every other day in order to see if there's something new.  Did you
> forget to push?

No, that was not the issue, I just wanted to make sure

> Anyway, I've updated to the current branch HEAD and restarted my
> rcirc-emacs.
>
>>> 06:58 -*.freenode.net- *** You are connected to chat.freenode.net using TLS
>>>                        (SSL) cipher 'TLSv1.3-TLS_AES_256_GCM_SHA384'
>>> 06:58 !!! "@msgid=446~1623712485~22272;inspircd.org/service;inspircd.org/bot
>>>           :NickServ!services@services.freenode.net NOTICE tsdh :Nick tsdh
>>>           isn't registered." (wrong-type-argument arrayp nil)
>>
>> From your other message, it seems like this is specificity related to
>> freenode, right?
>
> Yes, only freenode and only since today with no changes on rcirc in the
> meantime.  When I do
>
>     /msg nickserv help
>
> in the *chat.freenode.org* buffer, I get the response
>
>     20:42 *** 401 n No such nick
>
> and in the buffer N@chat.freenode.org there is
>
>     20:42 <tsdh> ickserv help

This was an issue caused by the new rcirc-define-command macro. The
intention was to improve defun-rcirc-command by adding integrated
argument parsing, and in this case, the regular expression was nor
correctly generated, as it did not require at least one whitespace
between arguments. I hope the last commits have fixes those issues, but
I might have to rethink some more fundamental things about how that
macro works.

> So now that user N has my nickserv password and I can't change it
> because freenode seems broken...
>
> I've asked on #help and the answers are:
>
>   1. I should use "/ns IDENTIFY password" instead of "/msg NickServ".
>   2. I should look into using SASL for identificiation.

Part of the IRCv3 improvements should also include this.

>   3. "/quote nickserv identify password" also gives an
>      (wrong-type-argument arrayp nil) error but finally told be that
>      tsdh is not a registered nick.
>
> And then I was told that the original freenode with its user database is
> now on classic.freenode.org and irc.freenode.org is something set up
> completely anew without the previous data...
>
> I was also told that "/msg foobar text" only works if the user foobar is
> online.  If not, it'll select the first online user whose nick is a
> prefix of foobar and send the remainder as message.  (That's why the
> user N received my NickServ IDENTIFY message.)
>
> I've just tried "/msg totototoXXX this is a test" on libera.chat and
> it's the same there.  The user t received a message "otototoXXX this is
> a test". :-(
>
> So it would make sense that rcirc checked if there is an online user
> NickServ before sending the IDENTIFY message to prevent password leakage
> to random users as has happended to me.
>
> Bye,
> Tassilo

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

Hi Philip,

>> Yes, only freenode and only since today with no changes on rcirc in
>> the meantime.  When I do
>>
>>     /msg nickserv help
>>
>> in the *chat.freenode.org* buffer, I get the response
>>
>>     20:42 *** 401 n No such nick
>>
>> and in the buffer N@chat.freenode.org there is
>>
>>     20:42 <tsdh> ickserv help
>
> This was an issue caused by the new rcirc-define-command macro. The
> intention was to improve defun-rcirc-command by adding integrated
> argument parsing, and in this case, the regular expression was nor
> correctly generated, as it did not require at least one whitespace
> between arguments. I hope the last commits have fixes those issues,
> but I might have to rethink some more fundamental things about how
> that macro works.

I'm now on 1181c606b3 but still "/msg nickservx test" will message
"ickservx test" to the user N on libera.chat.  I'd much prefer if that
told me that there is no (online) user nickservx rather than messaging
some mostly random stranger.

>>   2. I should look into using SASL for identificiation.
>
> Part of the IRCv3 improvements should also include this.

Great.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

Hi Philip,

>> I'm on fd96e3a0d9.  I've just pulled again and 8 new commits appeared,
>> the oldest being from 5 days ago.  I'm pretty confident I've pulled at
>> least every other day in order to see if there's something new.  Did you
>> forget to push?
>
> No, that was not the issue, I just wanted to make sure
>
>> Anyway, I've updated to the current branch HEAD and restarted my
>> rcirc-emacs.

By the way, I can still reproduce the issue that
`rcirc-next-active-buffer' adapts the activity string which is then
displayed correctly in the current TTY window but not other TTY windows.

When we talked about that, I've mentioned that I had to add a
(force-mode-line-update t) to `rcirc-update-activity-string'.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>> Yes, only freenode and only since today with no changes on rcirc in
>>> the meantime.  When I do
>>>
>>>     /msg nickserv help
>>>
>>> in the *chat.freenode.org* buffer, I get the response
>>>
>>>     20:42 *** 401 n No such nick
>>>
>>> and in the buffer N@chat.freenode.org there is
>>>
>>>     20:42 <tsdh> ickserv help
>>
>> This was an issue caused by the new rcirc-define-command macro. The
>> intention was to improve defun-rcirc-command by adding integrated
>> argument parsing, and in this case, the regular expression was nor
>> correctly generated, as it did not require at least one whitespace
>> between arguments. I hope the last commits have fixes those issues,
>> but I might have to rethink some more fundamental things about how
>> that macro works.
>
> I'm now on 1181c606b3 but still "/msg nickservx test" will message
> "ickservx test" to the user N on libera.chat.  I'd much prefer if that
> told me that there is no (online) user nickservx rather than messaging
> some mostly random stranger.

I can imagine that both use-cases could be of interest, so it would
probably be best to add a flag to regulate this.

>>>   2. I should look into using SASL for identificiation.
>>
>> Part of the IRCv3 improvements should also include this.
>
> Great.
>
> Bye,
> Tassilo

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

Hi Philip,

>> I'm now on 1181c606b3 but still "/msg nickservx test" will message
>> "ickservx test" to the user N on libera.chat.  I'd much prefer if
>> that told me that there is no (online) user nickservx rather than
>> messaging some mostly random stranger.
>
> I can imagine that both use-cases could be of interest, so it would
> probably be best to add a flag to regulate this.

Fine with me but I'm keen to learn about the use-case where the current
behavior is wanted.  I guess there is a use-case because otherwise the
IRC server wouldn't have that implemented as-is.

And IMHO when messaging nickserv or other service bots receiving
confidential data, the current behavior is not acceptable.  I'm not sure
if the automatic authentication in terms of `rcirc-authinfo' checks if
nickserv (or whatever) is actually available and, if not, falls into
that trap just as I did by messaging the non-existent NickServ manually.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>> I'm on fd96e3a0d9.  I've just pulled again and 8 new commits appeared,
>>> the oldest being from 5 days ago.  I'm pretty confident I've pulled at
>>> least every other day in order to see if there's something new.  Did you
>>> forget to push?
>>
>> No, that was not the issue, I just wanted to make sure
>>
>>> Anyway, I've updated to the current branch HEAD and restarted my
>>> rcirc-emacs.
>
> By the way, I can still reproduce the issue that
> `rcirc-next-active-buffer' adapts the activity string which is then
> displayed correctly in the current TTY window but not other TTY windows.
>
> When we talked about that, I've mentioned that I had to add a
> (force-mode-line-update t) to `rcirc-update-activity-string'.

Pushed the fix, I forgot that force-mode-line-update appears to be
necessary in the TUI.

> Bye,
> Tassilo

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>> I'm now on 1181c606b3 but still "/msg nickservx test" will message
>>> "ickservx test" to the user N on libera.chat.  I'd much prefer if
>>> that told me that there is no (online) user nickservx rather than
>>> messaging some mostly random stranger.
>>
>> I can imagine that both use-cases could be of interest, so it would
>> probably be best to add a flag to regulate this.
>
> Fine with me but I'm keen to learn about the use-case where the current
> behavior is wanted.  I guess there is a use-case because otherwise the
> IRC server wouldn't have that implemented as-is.

I was thinking about when you want to message a friend who is currently
marked as away.

> And IMHO when messaging nickserv or other service bots receiving
> confidential data, the current behavior is not acceptable.  I'm not sure
> if the automatic authentication in terms of `rcirc-authinfo' checks if
> nickserv (or whatever) is actually available and, if not, falls into
> that trap just as I did by messaging the non-existent NickServ manually.

That is true.  It shouldn't be hard to add a check to ensure this.

> Bye,
> Tassilo

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

>> Fine with me but I'm keen to learn about the use-case where the
>> current behavior is wanted.  I guess there is a use-case because
>> otherwise the IRC server wouldn't have that implemented as-is.
>
> I was thinking about when you want to message a friend who is
> currently marked as away.

"Marked as being away" is different to offline/doesn't exist, right?  So
if I'd "/msg philipk Hello" I'd still want that only philipk receives
the message and not some other user p, ph, phi, or whoever.

>> And IMHO when messaging nickserv or other service bots receiving
>> confidential data, the current behavior is not acceptable.  I'm not sure
>> if the automatic authentication in terms of `rcirc-authinfo' checks if
>> nickserv (or whatever) is actually available and, if not, falls into
>> that trap just as I did by messaging the non-existent NickServ manually.
>
> That is true.  It shouldn't be hard to add a check to ensure this.

Great.

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

>> By the way, I can still reproduce the issue that
>> `rcirc-next-active-buffer' adapts the activity string which is then
>> displayed correctly in the current TTY window but not other TTY
>> windows.
>>
>> When we talked about that, I've mentioned that I had to add a
>> (force-mode-line-update t) to `rcirc-update-activity-string'.
>
> Pushed the fix, I forgot that force-mode-line-update appears to be
> necessary in the TUI.

Works as expected now.  Thanks!

Bye,
Tassilo

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

>>> Fine with me but I'm keen to learn about the use-case where the
>>> current behavior is wanted.  I guess there is a use-case because
>>> otherwise the IRC server wouldn't have that implemented as-is.
>>
>> I was thinking about when you want to message a friend who is
>> currently marked as away.
>
> "Marked as being away" is different to offline/doesn't exist, right?  So
> if I'd "/msg philipk Hello" I'd still want that only philipk receives
> the message and not some other user p, ph, phi, or whoever.

Yes, of course. If rcirc is parsing any substring of a token, something
else is broken. My hope is that the changes to rcirc-define-command
should have fixed it (for now).

>>> And IMHO when messaging nickserv or other service bots receiving
>>> confidential data, the current behavior is not acceptable.  I'm not sure
>>> if the automatic authentication in terms of `rcirc-authinfo' checks if
>>> nickserv (or whatever) is actually available and, if not, falls into
>>> that trap just as I did by messaging the non-existent NickServ manually.
>>
>> That is true.  It shouldn't be hard to add a check to ensure this.
>
> Great.
>
> Bye,
> Tassilo

-- 
	Philip K.

Re: [feature/rcirc-update] Reconnects don't seem to work anymore

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

>> "Marked as being away" is different to offline/doesn't exist, right?
>> So if I'd "/msg philipk Hello" I'd still want that only philipk
>> receives the message and not some other user p, ph, phi, or whoever.
>
> Yes, of course. If rcirc is parsing any substring of a token,
> something else is broken.  My hope is that the changes to
> rcirc-define-command should have fixed it (for now).

Ah, I think I've tested last time with commit 7e5360f322.  Now I've
tried with 21148f67f1

  /msg tsdh test

where tsdh is my own nick and also

  /msg tsdhxxxxxx test

where tsdhxxxxxx doesn't exist and in both cases a buffer for the
messaged nick was opened.  So apparently it works now, fixed by
b5d935bb7f.

I didn't know that this was a client/rcirc issue because that guy on
#help on freenode told me yesterday that what I've had observed (message
to random user whose nick is a prefix of the messaged one) is normal
behavior.  Or at least, it sounded like that.

Thanks!
Tassilo