Re: zsh_error_db --- hash-based database of error messages

[Oliver Kiddle <opk@xxxxxxx>]

Peter Stephenson wrote:
> Following on from the retread of the discussion on error messages,
> here's a very simply proof of concept for a hash-based database of
> error messages.  Even if it's adopted I don't intend the C code
> to get much larger as the point is to allow it to be able to do
> everything in shell code.
>
> Apart from more user-friendly messages which someone with no
> access to the C code can dedicate their life to tweaking,
> this is obviously a boon for internationalization (which

If we want to address internationalisation, we might come to regret not
just using the normal POSIX catgets(3) interface and catalogue files.
What they do looks simple on the surface but there's probably hidden
areas of complexity that we'd end up duplicating. I can see the value of
allowing things to be done in shell code but the two are not mutually
exclusive.

While error messages encompass the majority of strings that zsh ever
needs to print there are some strings that aren't error messages.

> Apart from updating the error message to examine the hash, the
> only change is to prefix the error message format string with
> the code such as "E3" and a colon.  This would obviously
> be done universally.

E and a number sounds fine. I'm not keen on trying to encode file names
such as ZW for zle_word.c because we may want to move code from one file
to another in the future. If there's a need to divide things up, perhaps
do something like 1000s for history, 2000s for zle, etc like we have for
test cases. Parsing the E-number out of the string may be less flexible
than adding an extra parameter and/or having a macro to wrap it. If
duplicates are a concern scripts can be written to do checking or maybe
some clever use of X macros.

The best example for easy error messages I've come across is the Rust
compiler. This quotes your code with highlighting and colours and
finishes with a message like:
  For more information about this error, try `rustc --explain E0463`.
So there are two levels of detail about an error available.

If the only way to get friendly error explanations is to autoload
functions and enable plugins, the type of users that will benefit from
them will likely not find out about them until they're knowledgeable
enough not to want them. Perhaps prompting with the explain invocation
needs to be enabled by default with a setopt to turn that off. For
people that do turn it off, a special parameter could store the number
of the last error that was printed so that explanations can still be
accessed.

> The signatures of the format strings, i.e. where the % escapes
> live, is checked for, though if there are cases where
> we have more than a single letter code it'll fall over.
> There's no provision for reordering escapes, either, but I
> wouldn't expect to do that in an initial implementation anyway.

Reordering is quite common for internationalisation. Our printf builtin
does handle that with things like %2$s so we already have an
implementation of parsing printf formats but directed at a rather
aifferent purpose.

Oliver