mule-tests input method tests failing

[Aidan Kehoe]

 Ar an naoiú lá de mí Deireadh Fómhair, scríobh Stephen J. Turnbull: 

 > Aidan Kehoe writes:
 > 
 >  > No, here they should. Those tests are there because we had had one of
 >  > the language environments specify latin-5-prefix as its input method
 >  > in 1999;
 > 
 > You're allowed to reference things that are undefined in Lisp code.
 > Such references are not breakage.

In this case they are. If a language environment uses a feature that we
*cannot* provide, in the normal scheme of things, then it is broken.

 > Eg, by an obvious extension of your logic, we should have test failures
 > because ispell isn't installed, too!

We can influence whether the input methods are available a lot more
comprehensively than we can whether ispell is available.

 > In the core tests, features that depend on external support may warn that
 > the support is unavailable, but they should not fail.  Packages *are*
 > external support from the point of view of tests/automated.

I don’t disagree with you on this. I do think that this particular test is
more important than the conceptual cleanliness of the core/packages
distinction, given that *the bug it tests for was ignored for eight
years*. Most open source coders don’t care about internationalisation, which
is part of why Microsoft has won the OS wars, and this is important.

 > If you consider a language environment to be broken if the default
 > input method is unavailable, you have two choices: move the support
 > into the core (which I will veto), or move the language environment
 > into the packages so that consistency can be maintained.

I would love to have the latter as an option, but 21.4 doesn’t seriously
support UTF-8, and that’s necessary for the Darwin-specific file name stuff
to work; also, I am really not in a hurry to add
posix-charset-to-coding-system-hash to 21.4. Maybe it’ll work, maybe it
won’t.

 >  > If you have a suggestion for a way to check for this error
 > 
 > It's a problem for some users, maybe even a showstopper.  However, it
 > is not an error in the XEmacs binary which is being tested.

Yes it is. The language environments are dumped; they’re in the binary; if
they are incoherent, they are an error in the binary.

 >  > without a dependency on the packages being current, please to be
 >  > coming forward with it.
 > 
 > I already made it:
 > 
 >  >  > Fix the tests to be skipped, not failed, if the input methods are
 >  >  > missing, please. Skip-Test-Unless will make loud enough noises to
 >  >  > warn the user; it doesn't need to fail, too.

Skip-Test-Unless is what happens when the packages are not installed, and
the user is to interpret it then as meaning that all is well. That conflicts
strongly with people interpreting it in other contexts as meaning that it is
an error.

 > This could be improved by changing test-harness to add a final warning
 > if tests were skipped, something like "Tests were skipped because
 > external support for them such as system commands or Lisp packages
 > were not found.  These commands and packages are expected to be
 > installed on typical systems supporting XEmacs, and you may wish to
 > check what's missing and install it if appropriate for your use.
 > 
 > Here's another: improve the run-time error message to something like
 > "The %s input method was not found.  You may need to install the
 > `leim' package, or in some cases an external program."

Not any clearer than the current test suite failure.

 > Here's yet another: let's provide an check-emacs-environment package,
 > which tests for external support needed for full use of various
 > features.
 > 
 > Here's an idea.  Once we have that package, we could make Mike provide
 > tests for Dired support of the user's locale!
 > 
 > Here's one more: fix the runtime language environment code to examine
 > the LEIM registry for input methods that support that environment and
 > present that list to the user, rather than specify a default input
 > method.

The user doesn’t care that much about the input method. The user’s keyboard
generates the characters that the user uses already [except of course when
the user is using a TTY and the high bit is interpreted as meta!] because
the user uses other applications with those characters too. This check is
mainly about the quailty of *our* code.

And Christ, a test failure that is trivially resolved is not that fucking
important.

-- 
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)