[Erc-help] post-commit synopsis (was: erc-backend.el --- pre-commit warnings :))

[Lawrence M. <we...@gm...>]

Lawrence Mitchell wrote:

Right, I've now committed, should you not wish to run around
with a buggy ERC, you can get the pre-changes tree by checking
out files with the PRE_NEW_BACKEND symbolic tag (only those that
I had to change have this tag, some files are unchanged).

> well, I think I've just about ported all of ERC to a new backend
> interface (I've been running without error for a few hours now).
> erc-members.el has /not/ been ported, I think this is obsolete
> anyway, with the advent of jbms' hashtable channel-members stuff.

Anyone have any comments on this?

[...]

>   All server response handlers should be defined with
>   `deferc-response-handler'.  This defines functions and
>   corresponding hook variables.

This is now define-erc-response-handler, it works exactly the
same way though.

[...]

>     (gethash (format (if (numberp command) "%03i" "%s") command)
>              erc-server-responses)

>   This will get a wrapper function, it doesn't have one yet.

It has one, it's called `erc-get-hook', and takes as an
argument, a server command, e.g. "MOTD", or a numeric response,
e.g. 001.

[...]

This warning still applies :)

> WARNING WARNING!!

> I have not tested the new code with all bits of ERC, I've put
> FIXMEs in a bunch of places where I'm not sure I correctly
> interpreted the previous implementation's magic numbers (I
> haven't waded through the IRC spec in great detail, lots of it
> has been a trial-and-error thing).  Please run with uncompiled
> code and with debug-on-error set to t.  The backtrace will
> generally contain a complete `erc-response' struct, a copy of
> this, and which ERC function caused the error are the two bits
> of information most needed to fix things.  I just compare what
> the old code did with what the new code does with that test
> case.

-- 
Lawrence Mitchell <we...@gm...>