bug#60191: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers

bug#60191: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers

[Thuna]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

Currently `rcirc-buffer-process' with no BUFFER argument defaults to
current buffer's `rcirc-server-buffer' instead of the current buffer
itself which leads to `rcirc-buffer-process' not working with channel
buffers.

This patch should hopefully fix that.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: The patch --]
[-- Type: text/x-patch, Size: 1330 bytes --]

From d17e7cbb34cf83098561c57b383f90d6a7bde50e Mon Sep 17 00:00:00 2001
From: Thuna <thuna.cing@gmail.com>
Date: Mon, 19 Dec 2022 09:33:29 +0100
Subject: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers

* lisp/net/rcirc.el (rcirc-buffer-process): Look at BUFFER's
`rcirc-server-buffer's `rcirc-process' instead.  Signal an error if it
has none.
---
 lisp/net/rcirc.el | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 96109dcd5c9..7afb625407e 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -1179,11 +1179,11 @@ rcirc-send-ctcp
 (defun rcirc-buffer-process (&optional buffer)
   "Return the process associated with channel BUFFER.
 With no argument or nil as argument, use the current buffer."
-  (let ((buffer (or buffer (and (buffer-live-p rcirc-server-buffer)
-                                rcirc-server-buffer))))
-    (if buffer
-        (buffer-local-value 'rcirc-process buffer)
-      rcirc-process)))
+  (let ((buffer (or buffer (current-buffer))))
+    (buffer-local-value
+     'rcirc-process
+     (or (buffer-local-value 'rcirc-server-buffer buffer)
+         (error "Not an rcirc buffer: %S" buffer)))))
 
 (defun rcirc-server-name (process)
   "Return PROCESS server name, given by the 001 response."
-- 
2.37.4

bug#60191: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers

[Philip Kaludercic]

Thuna <thuna.cing@gmail.com> writes:

> Currently `rcirc-buffer-process' with no BUFFER argument defaults to
> current buffer's `rcirc-server-buffer' instead of the current buffer
> itself which leads to `rcirc-buffer-process' not working with channel
> buffers.

I do not understand what you mean by "not working" here, the code
appears to do the same thing pre- and post-patch, in the process and the
channel buffers.

> This patch should hopefully fix that.
>
>>From d17e7cbb34cf83098561c57b383f90d6a7bde50e Mon Sep 17 00:00:00 2001
> From: Thuna <thuna.cing@gmail.com>
> Date: Mon, 19 Dec 2022 09:33:29 +0100
> Subject: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers
>
> * lisp/net/rcirc.el (rcirc-buffer-process): Look at BUFFER's
> `rcirc-server-buffer's `rcirc-process' instead.  Signal an error if it
> has none.
> ---
>  lisp/net/rcirc.el | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
> index 96109dcd5c9..7afb625407e 100644
> --- a/lisp/net/rcirc.el
> +++ b/lisp/net/rcirc.el
> @@ -1179,11 +1179,11 @@ rcirc-send-ctcp
>  (defun rcirc-buffer-process (&optional buffer)
>    "Return the process associated with channel BUFFER.
>  With no argument or nil as argument, use the current buffer."
> -  (let ((buffer (or buffer (and (buffer-live-p rcirc-server-buffer)
> -                                rcirc-server-buffer))))
> -    (if buffer
> -        (buffer-local-value 'rcirc-process buffer)
> -      rcirc-process)))
> +  (let ((buffer (or buffer (current-buffer))))
> +    (buffer-local-value
> +     'rcirc-process
> +     (or (buffer-local-value 'rcirc-server-buffer buffer)
> +         (error "Not an rcirc buffer: %S" buffer)))))
>  
>  (defun rcirc-server-name (process)
>    "Return PROCESS server name, given by the 001 response."

bug#60191: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers

[Thuna]

> I do not understand what you mean by "not working" here, the code
> appears to do the same thing pre- and post-patch, in the process and the
> channel buffers.

The problem is that when `rcirc-buffer-process' is explicitly called
with a channel buffer it returns nil, as the local variable
`rcirc-process' is set only in server buffers and the function checks
the server buffer only if the BUFFER argument is nil.

This leads to a situation where `(rcirc-buffer-process)' and
`(rcirc-buffer-process (current-buffer))' do not behave in the same way
when called from channel buffers.

bug#60191: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers

[Philip Kaludercic]

Thuna <thuna.cing@gmail.com> writes:

>> I do not understand what you mean by "not working" here, the code
>> appears to do the same thing pre- and post-patch, in the process and the
>> channel buffers.
>
> The problem is that when `rcirc-buffer-process' is explicitly called
> with a channel buffer it returns nil, as the local variable
> `rcirc-process' is set only in server buffers and the function checks
> the server buffer only if the BUFFER argument is nil.
>
> This leads to a situation where `(rcirc-buffer-process)' and
> `(rcirc-buffer-process (current-buffer))' do not behave in the same way
> when called from channel buffers.

OK, I get what you mean and the patch should be applied.  But IIUC you
haven't signed the FSF CA, right?  If that is so, I am afraid I am not
allowed to apply /your/ change myself...

bug#60191: [PATCH] Fix `rcirc-buffer-process' not working on channel buffers

[Thuna]

> OK, I get what you mean and the patch should be applied.  But IIUC you
> haven't signed the FSF CA, right?  If that is so, I am afraid I am not
> allowed to apply /your/ change myself...

It will have to be on hold until the CA can be finalized, I'm afraid.
My other patches are in a similar situation.

I have applied for the CA quite a long time ago but unfortunately, my
school is not being very receptive when it comes to the copyright
disclaimer.  

I have mostly entrusted the matter with Craig Topham at
<craigt@fsf.org>, so you will have to contact them for any updates.