Re: [PATCH] Fixes to allow erc-dcc-get-filter to work properly

[Victor Orlikowski <vjo@duke.edu>]

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 (xxx@xxxx.xxx)
    (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