Cargocult

    < x2600> weird question, do I have to put type = "IRC" *under* the
             SASL stuff?

So the irssi configuration block in question had been copied from who knows where, in turn copied from who knows where. The easy solution is to continue to cargocult the configuration, as if you haven't broken it then there's nothing to fix. This saves time, but is weaker on the understanding front, and you may need understanding when something Doesn't Work™.

The configuration might be stored as a hash or struct, a bag of key and value pairs, in which case the order in the configuration file should not matter. Even here there can be complications as to whether the first or last matching entry wins, in the event there are duplicate keys. This causes some amount of incompatibility between unix programs where some pick the first environment variable when duplicates are present, and other programs pick the last of the duplicates. Yes, environment variables can be duplicated. The variables are in a list, so an arbitrary program could put both "key=foo" and "key=bar" into the array of strings that is the extern char **environ.

The configuration could instead be a rules system, in which case the order of the statements may very much matter. Think firewall rules, or the arguments to find(1). Hopefully the rules system is documented somewhere, e.g. here's what gmid.conf(5) has to say about location blocks:

    location path {...}
      Specify server configuration rules for a specific location. path
      argument will be matched against the request path with shell
      globbing rules. In case of multiple location statements in the
      same context, the first matching location will be put into effect
      and the later ones ignored. Therefore is advisable to match for
      more specific paths first and for generic ones later on. A
      location section may include most of the server configuration
      rules except alias, cert, key, listen, location and proxy.

Sometimes "bag of keys" configuration parameters and rules systems are mixed together in the same file.

The documentation or code would be ideal to study, but another method is to try different configuration orderings and then see what if anything breaks. These methods however take time, which is probably why the easy path of the cargocult is so often taken. Often but not always this works out for copying configuration around.

Configuration also communicates to the reader, so the following (while probably valid) may look funny to a human: the username is typically listed before the password. With an interactive login(1) the username must be supplied first, so there is an ordering, but in a configuration file where the username and password get stuck into a struct or hash by the "read the config" code the order does not matter, to the code. It may matter to humans trying to understand the configuration, so probably the password should conventionally be listed after the username, even if alphabetic also makes sense. An alphabetic sort is consistent and gives the reader a good clue as to where a hypothetical "zooty_zoot_zoot" parameter will be or should go in the list, and if maintained should help make duplicate entries easier to spot.

    ...
    tilde = {
      sasl_mechanism = "PLAIN";
      sasl_password = "Hunter2";
      sasl_username = "gandalf";
      type = "IRC";
    ...