"edit.properties" changes

[Elliott Hughes]

(if you don't know what "edit.properties" is, you can stop reading
now.)

tomorrow's build will look in "evergreen.properties" rather than
"edit.properties". most users won't notice or care, but if you've made
deliberate manual modifications to that file, you'll need to manually
carry across any changes you want to preserve.

why won't Evergreen do that for you? because although all long-term
users have"edit.properties", most of them don't know they do, and the
content was forced upon them by a poor design choice years ago (mixing
user-editable configuration with configuration necessary to
Evergreen's functioning, in the same file).

if you added your own "external tools", the other change that will
affect you is that they're no longer read from the properties file.
there's now a "tools" directory next to the properties file (or will
be if you create one), and each file in their is a tool in its own
right. the format of those files is the same as the old properties;
just strip off the "tools.0." or whatever from the start of each line.

also, all the old EDIT_ environment variables now start EVERGREEN_
instead.

the on-line documentation has already been updated.

what's the benefit of these changes? i've been improving the code that
deals with configuration. properties file changes (which used to only
take effect on restart) are now noticed immediately. there's a new
button in the Preferences dialog to open the properties file, and
there are more changes to come. keep an eye on the change log if these
things interest you.

actually, while i'm here, it'll be easier for you to make comments or
suggestions if you know what's on my to-do list:

jobs, not necessarily in the right order:

[done] switch from system properties to a private map.
[done] UI to edit the user's properties file.
[done] implement reloading.
[done] add a FileAlterationMonitor for the properties file to
automatically reload.
[done] make sure the FAM picks up changes to included files.
[done] add a defaults file under lib/ and load that ahead of the
user's properties file (making sure the FAM picks up changes to the
"inherited" file).
[done] change hard-coded defaults to use that file.
(CheckForLintAction, OpenImportAction. search for HashMap<FileType.)
[done] change "edit.properties" to "evergreen.properties".
* add a /usr/local/software.jessies.org/evergreen/
evergreen.properties and load that ahead of the user's properties
file (making sure the FAM picks up changes to the "inherited" file).
* automatically create "evergreen.properties" if it doesn't exist.
(only when asked to edit it?)
* document supported parameters.
* add support to ETextWindow for system-wide spelling exceptions
(search for HashMap<FileType).
* implement some form of += in addition to the existing =, prepending
';' if the current value is non-empty (';' is the only list separator
we support).

orthogonally, for external tools:

[done] pull the external tools out of the properties file, breaking
them into one-file-per-tool in a directory structure.
[done] change the EDIT_ environment variables to EVERGREEN_.
* implement reloading.
* add a FAM for the directories in the structure to automatically
reload.
* add a GUI, preferably a proper Add/Edit/Remove dialog. (something i
keep wanting in various projects.)

additionally, if necessary:

* i think our removal of properties has been pretty successful for
those things that should have been in the GUI, but we should keep an
eye out for configuration that's of the wrong kind.
* decide whether GUI settings need to be in the same hierarchy. if
they do, work out how to do that.

non goals that, if done, are separate projects:

* providing the ability to override system preferences.
* providing new preferences (of whatever kind) for things that aren't
currently configurable.
* providing a mechanism to set environment variables. (we could have
special syntax, but it's incompatible with the desire to be able to
reload, unless we don't actually apply the changes to Evergreen's
environment but supply children with an appropriately-modified
environment.)
* providing a general mechanism to backquote in properties files. (we
could do this, but i don't think it would help anyone. i might be
wrong, though, if someone needed to compute what most people consider
hard-coded. it would be awkward to do well [because you're hiding
changes from the FAM] so i'd want to hear someone have a specific use
case.)

--elliott