Add easy way to change hterm preferences

[mjkelly]

It would be nice if there was a standard preferences page to make editing them easy, without doing term_.prefs_.set('foo').

This is largely selfishly motivated, and I volunteer to add it, but it might take a while to me to get to it. Secure Shell does something like this already.

[rpwoodbu]

Thanks, Michael, for volunteering for this. I hadn't seen Secure Shell's page for this. I wonder if we can just bring up the same page as they do, but showing Mosh assets. That'd be much easier from a maintenance standpoint, too.

[rpwoodbu]

I just looked at how Secure Shell works, and unfortunately, the preferences editor is under the nassh tree, not the hterm tree, so it would be awkward to use at the least, and would be a maintenance headache. So the options would be to fork/reimplement that in Mosh for Chrome, or refactor it upstream so that a properly generalized version would be available to all hterm clients.

[mjkelly]

I haven't looked closely enough at the code to really understand how tightly coupled it is to nassh. There are some dependencies to sort out (libdot, etc), which appear to also be in nassh. (Maybe that's easy to deal with, but I'm unfamiliar with it.)

I'll try to hack something up in the next week, if just to get a little more familiar with the chrome extension environment.

[vapier]

@rginda how do you feel about moving some of the hterm preference stuff out of nassh and into hterm itself ? that way people using hterm have an existing options page they can just drop in and run with.

[rginda]

I intentionally kept it out of hterm for a few reasons, but we could revisit it.

My concerns were:

1. Window opening could depend on the embedding environment. A Chrome v2 app we need to use chrome.window.create, and have to contend with strict CSP rules. It's also going to want to link to the page from manifest.json. A web page can get away with just window.open.
2. The hterm distributable is typically a single js file, two if you want to separate libdot. I'd prefer not to have to deliver a separate html and possibly css file.
3. Secure Shell's options page is rough, it displays raw preference ids and no help text. I always assumed we'd rewrite it to include more natural labels and some more description about the options. In that case we'd probably want to be able to translate those strings.

#1 and #2 could be addressed by showing the options in a div overlay on top of hterm itself. Or we could put some of the prefs in a context menu and avoid a prefs page completely.

For #3, I think we'd hard-code English strings but provide a way for the embedding app to override them with locale specific translations. This is basically what we have with hterm.zoomWarningMessage/notifyCopyMessage, except we'd probably want to switch to a dictionary of messages.

(edited for formatting/typos)

[purebred916]

Thank you for the advise

[rpwoodbu]

Fixed in SHA c25e02f.