Re: [Gnushogi-devel] gnushogi xboard support

[ydirson]

> 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.

The default behaviour of bash is different from what I recall to have seen in
windows cmd: completions are only done when there is a unique completion 
matching
the prefix chars that have been already entered.  This contrasts with providing
one of the choices, and having another TAB hit rotate the completion to another
possible one (something I recall having seen done with zsh)

When asked to complete a new arg, all of them will be proposed, those starting 
with
"@" alongside those that start with "-".  If the user types "@" and then TAB 
again,
the choices will be restricted to that prefix, and only when the user adds a "s"
will "@shogi" be completed on next TAB.

Here advertising occurs when the user first hits TAB (usually twice to get the 
list,
as the first TAB only expands the prefix as much as it can without listing).
If we arrange to list "@" options betore "-" ones, that should be efficient.

> 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...)

Maybe it's time to improve the mechanism, but sure that should be done without
nuking people's conf.  Some random thoughts:

* just saving the old user's conf before creating a new one, so those who
  do have valuable stuff can dig them back.  Not that friendly, could be
  mitigated with a new "get back from old conf" menu action, but that adds
  cruft in menus that are already quite filled.

* keeping their conf, display system engines alongside user ones with a visual
  cue about which is what, so the user can cleanup his old redundant entries
 
> 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

Indeed, doing so prevents the use of "xboard -ncp" without an engine installed,
which sounds a bit awkward.  In Omaha, I just install all engine definitions,
and just disable the entries for unavailable ones, so users know those engines
are supported and they just need to install them to activate them.

> 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.

This starts to sound awfully complicated :)