[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Fixes to allow erc-dcc-get-filter to work properly
From: |
Victor Orlikowski |
Subject: |
Re: [PATCH] Fixes to allow erc-dcc-get-filter to work properly |
Date: |
Fri, 8 Feb 2019 22:00:31 +0000 |
On Fri, Feb 08, 2019, at 09:59 AM, Eli Zaretskii wrote:
> Thanks. Can you please elaborate on the problem, perhaps showing an
> example of the behavior before and after your patch? I don't think I
> understand the issue with buffer-file-name (but then I don't use ERC).
Certainly.
The error checking I added came as a result of debugging the
problem, and *may* not be strictly necessary (the nil check for str,
the nil check for erc-dcc-byte-count).
I run ERC with erc-dcc-verbose set to t.
I was getting the following error message, repeating several times:
error in process filter: erc-dcc-get-filter: Wrong type argument: stringp, nil
when trying to receive a file from a colleague using the DCC mechanism. I
run ERC to communicate with colleagues via XMPP, using bitlbee as a
gateway.
After putting in the error checks mentioned above, I managed to get
a different error (again repeating several times) from
erc-dcc-get-filter:
error in process filter: erc-display-message: Wrong type argument: stringp, nil
When I set erc-dcc-verbose to nil, the above errors went away.
I set erc-dcc-verbose to t once more, and added code to the function
to print each of:
buffer-file-name
received-bytes
I discovered that buffer-file-name was nil - which was what
had been causing these errors to occur.
I noted, earlier in the function:
(when (> (point-max) erc-dcc-receive-cache)
(erc-dcc-append-contents (current-buffer) erc-dcc-file-name))
and chose to replace "buffer-file-name" with "erc-dcc-file-name" -
which got behavior I expected to see.
To clarify further - the behavior I expected to see was, with
erc-dcc-verbose set to t, that output similar to the following
should be generated in the server buffer:
*** DCC: file IDidntBringEnoughToShare.png offered by RobCarter (address@hidden)
(size 491883) [17:03]
*** DCC: IDidntBringEnoughToShare.png: 3624 bytes received
*** DCC: IDidntBringEnoughToShare.png: 4096 bytes received
*** DCC: IDidntBringEnoughToShare.png: 8192 bytes received
*** DCC: IDidntBringEnoughToShare.png: 12288 bytes received
*** DCC: IDidntBringEnoughToShare.png: 16384 bytes received
*** DCC: IDidntBringEnoughToShare.png: 20480 bytes received
*** DCC: IDidntBringEnoughToShare.png: 24576 bytes received
*** DCC: IDidntBringEnoughToShare.png: 28672 bytes received
*** DCC: IDidntBringEnoughToShare.png: 32768 bytes received
*** DCC: IDidntBringEnoughToShare.png: 36864 bytes received
*** DCC: IDidntBringEnoughToShare.png: 40960 bytes received
*** DCC: IDidntBringEnoughToShare.png: 45056 bytes received
... additional lines elided ...
*** DCC: IDidntBringEnoughToShare.png: 479232 bytes received
*** DCC: IDidntBringEnoughToShare.png: 483328 bytes received
*** DCC: IDidntBringEnoughToShare.png: 487424 bytes received
*** DCC: IDidntBringEnoughToShare.png: 491520 bytes received
*** DCC: IDidntBringEnoughToShare.png: 491883 bytes received
*** DCC: file ~/IDidntBringEnoughToShare.png transfer complete (491883 bytes
in 8 seconds)
The errors I had been previously receiving (prior to patching the
function) occurred every erc-dcc-receive-cache bytes.
I am presently overriding this function in my ercrc.el via:
(eval-after-load "erc-dcc"
'(defun erc-dcc-get-filter (proc str)
(rest of function elided)))
Does that clarify the issue sufficiently?
Thanks,
Victor
--
Victor J. Orlikowski <> vjo@(ee.|cs.)?duke.edu
[PATCH] v2: Fixes to allow erc-dcc-get-filter to work properly, Victor Orlikowski, 2019/02/10