Provide per-host aliases

[kurahaupo]

I would like to be able to change the available aliases on a per-host basis.

Mostly this is so that I can use the same alias names with different implementations on different IRC servers. But also I could also have custom commands that are only usable on certain servers.

There would still be a default set, but I would be able to override an alias with a separate definition for a particular host.

Adjustments

Add a 4th alias type "comment" (after "message", "client command" and "raw") that effectively suppresses that alias, for the case where it cannot be implemented for a given host. If there's text, it's shown greyed-out in any menu, otherwise it's simply hidden.

Add "aliases" to the per-host settings. The layout is the same, except add a heading line showing "aliases for host" or "default aliases". The list of aliases always includes the default and built-in aliases

Wherever there's an "edit" or "delete" button or menu item, and it's not clear from context that a particular set is implied, split it into multiple items targetting the same alias name in each set that contains it.

Additional options such as "move" or "copy" may be needed, however exactly which are useful will depend on the model chosen (see below).

When editing:

• have banner say "for host" / "default" / "copy of built-in" / "new".
• have buttons for
  • Reset to built-in (depending on model)
  • Reset to default
  • Reset to this host's version
  • Save (when original specified)
  • Save as default (when new or original was not default)
  • Save for this host (when new or original was not host)
  • Abandon (highlight the "save" that will overwrite the source)

Models

There are, broadly speaking, two models which might work: prototypes, and inheritance.

Prototypes

(An object in Javascript acquires all its methods by copying them from a prototype at construction time. There's a single namespace for members and methods, so you don't need to know a-priori which whether a name is a member or a method before looking it up.)

The built-in alias set would be copied to the default alias set upon installation, and optionally upon upgrades.

The default alias set would be coped to per-host alias sets, upon creation of each host, or upon request.

In this case removing an alias from the default set won't have any immediately visible effect; rather, it will have effect when the next host is created, or if you explicitly request an alias be copied to all hosts.

New/Edit/Save/Delete would seem to work pretty much as now. It would need new menu items for "copy from default to host", "copy from host to default", and "copy to all hosts".

Inheritance

(Perl and Python implement classes with inheritance, using a mechanism that involves run-time searches to find methods. Adding a method to a class at run-time makes it available to all instance objects immediately.)

Rather than copying, whenever looking up an alias, always check all three sets - the host sets, the default set, and the built-in set, in that order - first wins.

It therefore matters to distinguish between "remove override from host", when it will fall back to the default or built-in, "remove override from default", when it will fall back to the built-in, and just "remove", when there's no default or built-in to fall back to.

Hybrid

Copy the built-in alias set to the default alias set upon installation, but don't copy defaults into per-host alias sets. When looking for an alias, just look in the per-host set, and failing that look in the default set (and not in the built-in set).

I think this is the option I would prefer, but I don't feel like I've thought it through yet.

With the following few tweaks, the built-ins could be hidden most of the time:

1. Offer "reset to built-in" when editing
2. Don't allow defaults that shadow built-ins to be deleted; allow them to be disabled instead. This means that you can always get the built-in back simply by going edit -> reset to built-in. (Since they're editable, it's not likely anyone will really care anyway).
3. When the app starts up, any built-in aliases that are missing from the default set should be "initialized" - copied from the built-in set to the default set - which means that upgrades are seamless, and you can't permanently "lose" an alias even if the code to block deletion somehow goes wrong.