Re: [Erc-help] Re: a couple of issues (services-module; doc string; buffer creation; encoding)

[Tobias C. R. <tc...@fr...>]

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

> The nickserv module performs a function orthogonal to the
> `erc-password' and `erc-prompt-for-password' variables.
> `erc-password' is used to authenticate to /servers/ that require
> it upon connection (this is sometimes the case with private
> servers).  The nickserv module installs hooks to automatically
> authenticate you to the NICKSERV service once you have logged in
> to the server---to do this it uses the passwords in
> `erc-nickserv-passwords'.

Oh, I just see that the reason for my confusion was the server I came
across which happened to (or, at least, seems to) be able to use a
supplied PASS for nickserv authentification. [I assume this is the way
it works, because when using `erc-select' to connect to that server, I
type in my password at a prompt showing "Password: "---I'm successfully
identified to nickserv later, however. No I didn't set any
erc-nickserv-* variables.] Well, I thought there must be some connection
between `erc-password' and the `erc-nickserv' module, but I couldn't
find one in the code, that's the way I came to be puzzled.

Howsoever, I wouldn't mind some additional comments about the different
purpose and maybe a note on the issue I encountered, though.


> I'd probably write:
>
> |     A list of modules which ERC is to load and activate
> |     automatically. Loading and activation are performed by
> |     `erc-update-modules' so modifying this variable outside of
> |     `customize' will take no effect unless you call
> |     \(erc-update-modules).

Fine with me. Will you take care creating patches for this and the
above one?


[Me wrote:]
> > * I intend to change the format of `erc-encoding-coding-alist' to
> >   introduce an additional server level, so that the encoding is
> >   determined not only by matching a channel, but also by matching an
> >   irc-server (analogously to `erc-autojoin-channels-alist'.) I think
> >   this can be done backwards-compatibly by testing if the CDR of an
> >   entry in the encoding alist is a symbol or not. (I think, this is easy
> >   enough that I'll do that myself when I have some spare time.
>
> Sounds good.

What's about the issue on copyright assignment?


--tcr.