[Erc-help] Re: byte-compilation breakage

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

Adrian Aichner wrote:

> Lawrence Mitchell <we...@gm...> writes:

>> Edward O'Connor wrote:

>> [...]

>>> This isn't just a help-Lawrence-out thing; the new code breaks quite
>>> thoroughly when byte-compiled. FYI. It seems to be an issue with using
>>> `erc-with-buffer' in `define-erc-response-handler' forms.
>>> `erc-with-buffer' is defined as a macro in erc.el, which is not
>>> `require'd by erc-backend.el (in fact, it's quite the opposite). So this
>>> `erc-with-buffer' is being byte-compiled as a function call.

>> Ah, well, spotted Ted.  Suggestions for clean fixes people?  I
>> can move the various macros in erc.el into erc-backend, but
>> that's probably a bad idea, since it then dilutes the purpose of
>> it.  Possibly, moving the (provide 'erc-backend) to the top of

> Please don't do that!

> Keeping the (provide ...) at the end will give an immediate clue that
> something went wrong during eval of erc-backend.el.

I've now committed a (temporary) fix for this by autoloading
erc-with-buffer as a macro from erc.el at the top of
erc-backend.  I still think the best thing to do is to move
macros into a separate file, which one can require without
having recursive-require nightmares and bootstrapping problems.

I've further committed a fix for erc-parse-server-response which
actually makes it /work/ in XEmacs, this was due to a "feature"
in XEmacs' `replace-match', which only replaces subexpressions
when operating on buffers, not strings.

Hopefully there aren't any more nasty bugs like this lurking
around (yeah right).

[...]

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