[Erc-help] Display ponderings

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

Hi people,

(long time no anything, well yes, life has intervened)

Over the christmas period, I thought I'd try and do something I've
been vaguely pondering for a while, namely trying to make ERC's
display slightly cleaner.  Before, however, I jump in at the deep end
(it always seems to end in disaster), I thought I run some ideas past
people.  The way I see things working is as follows.  Comments,
suggestions, flames?  They're all welcome to greater or lesser
degrees :).

Anyway, here goes:

How to do display in ERC --- A modest proposal.

Currently, ERC works on callbacks of some kind.  We send a command to
a server, and sit around waiting for a reply.  When a rpely arrives,
we parse it and hand it off to some handler to deal with.  Display is
always carried out through ERC-DISPLAY-MESSAGE, which is rather
opaque.  Now, stuff we send is not passed through this whole
mechanism, note the way if we send some text using erc-cmd-SAY, we do
not see it displayed in the same way that others see it.  Equally,
sending NOTICEs to the channel works in a different way.

Proposal:

All display should be carried out through the same function, if we get
information from a server, we construct a message in the same way we
do now, and display it as usual.  If we /send/ a message, we construct
what it /would/ look like had it been sent remotely, and send it
through the exact same lots of handlers.  This is easily done, see
ERC-CALL-HOOKS.

Protocol (something like this anyway):

erc-message                                                [structure]

All displayed messages are an erc-message structure.  This structure
contains:

  string --- the string that should be displayed to the screen
  buffers --- a list of buffers in which the message should be
              displayed
  process --- the process associated with this message
  type --- what type of message this is (e.g. CTCP), this will affect
           how the message will be formatted.
  displayp --- flag indicating whether we should actually display this
               message anywhere

erc-parse-server-response (string)                          [function]
  => erc-message

This function parses a raw server string and creates an ERC-MESSAGE

structure from it.

erc-display-message (erc-message)                           [function]

This function takes an ERC-MESSAGE (most probably from
ERC-PARSE-SERVER-RESPONSE) and displays it to the screen.

erc-construct-local-message (string)                        [function]
  => erc-message

This function parses an input that we send and constructs an
ERC-MESSAGE structure from it.  This can't be the same as
ERC-PARSE-SERVER-RESPONSE, because the format of commands that we send
to the server is different from that we receive.  The best option
would probably be to construct a valid server response (locally) and
pass it off to ERC-PARSE-SERVER-RESPONSE.

How display works:

There are two reasons ERC can display something to the screen,
firstly, we receive external input, secondly, we send some input from
the user.

The way we handle display is as follows:

1) Is the input external, if yes, go to 3), else go to 2)

2) Construct a correct IRC command from the input, send it to the
   server, pretend the input is external and go to 1)

3) Parse the input into an ERC-MESSAGE, this may involve setting the
   DISPLAYP flag, or any amount of massaging to make the displayable
   STRING what we want.  Go to 4).

4) If the DISPLAYP flag is non-nil, insert STRING into BUFFERS.

This should hopefully simplify display significantly from the slightly
spaghetti-like affair we have at the moment.

Lawrence

--
Lawrence Mitchell <s01...@sm...>