Re: [Gnushogi-devel] gnushogi xboard support

[h . g . muller]

> Shell completion (programable or otherwise) only happens when the user
> explicitely requests it, usually by hitting TAB, and the shell answers by
> completing the word being typed (in the case of bash) as much chars do
> until there is are several possiblities.  Depending on the context (eg.
> previous options), different sets of words may be available - that can be
> pretty complex.
>
> In the case of xboard, the set of words for completion would include
> all the options, and @ would have to be special, triggering expansion of
> .xop filenames in the defined search path.  Ideally they should
> even be displayed as first choices so they get noticed.  That way, @shogi
> and such will be visible to users, but that wouldn't get too much in their
> way.
>
The problem I see with that is how to know whether to complete with
@shogi, @chu or @xq. If it does this based on prior history, it is a great
tool for people that use XBoard always for the same purpose. If the choice
could only be made after typing the @c, @x or @s for users that use them
all, it hardly saves anything, because the filenames were chosen to be
short.

But it seems a poor vehicle for advertizing what the possibilities are. If
by default the completion would propose 'xboard @xq' to first-time users,
how could they ever know there was also @shogi and @chu?

I guess a more effective way to make the user aware of the existence of
such options (and even of the features they enable) would be to
pre-configure XBoard with engines that use them. E.g. in the engine list
we could put maxqi, gnushogi, gnuminishogi and hachu in both western and
oriental version (the latter by including @xq, @shogi and @chu on their
engine line), so they would appear as choices in the Load Engine dialog.
Knowing that it can be done might inspire interested people to figure out
how it should be done, e.g. by peeking in the manual.

Problem is that in the current XBoard settings mechanism there is no way
to add engines for old users that already have created a user settings
file. The engine list in their settings file would overrule the one that
was specified in the master settings file that was installed with the new
XBoard version. (Which is intended behavior: people would not be amused to
see an engine list that took them years to build be overwritten by a
default one on an upgrade...)

So perhaps it would be a good thing to create a novel option '-addEngine
STRING', where the string would be added as a new line to the existing
engine list IF it did not already occur there. Then we could incorporate
such a line in the master settings file we distribute (behind the
-settingsFile option that causes reading of the old user settings file) to
add GNU Shogi. Such an option could also be used in an install script for
GNU Shogi, where it would call

xboard -addEngine '"GNU Shogi (oriental)" @shogi -fcp "gnushogi
-xboardMode"' -autoClose

(Where -autoClose is a new volatile option I just imagined, which would
make XBoard spontaneously terminate before bringing up its GUI, but after
processing its settings files and command line, and saving the settings.)
This would then automatically add GNU Shogi to the XBoard engine list when
people installed it.

I am afraid, though, that putting this in the distributed master settings
file, so that an engine people might not have would automatically be
re-appended to the list every time after they delete it, would highly
annoy people. So perhaps obeyance to the -addEngine option from a settings
file should be made subject to the value of yet another new persistent
option, -versionNumber, which by default would be set to the built-in
version of the binary. So that when people first run a new version after
install, that version would be aware that it is running with settings
inherited from a previous XBoard version, enabling the -addEngine command,
before stepping up the stored version number with a -versionNumber option
in the master settings file. That would preclude the above command to work
from a GNU Shogi install script, however, as under those conditions the
stored and build-in version number would have remained the same.

I guess this could be solved by having two different options,
-addEngineSoft and -addEngineHard, where only the former would be
conditional based on version-number changes, so that engine install
scripts could use the latter.