Re: Encoding customization variable names

[Gavin Smith]

On Sun, May 29, 2022 at 02:08:42PM +0100, Gavin Smith wrote:
> On Fri, Mar 4, 2022 at 7:22 AM Patrice Dumas <pertusus@free.fr> wrote:
> > Also do not hesitate to propose other names for those customization
> > variables.
> 
> Still to review: LOCALE_INPUT_FILE_NAME_ENCODING,
> LOCALE_OUTPUT_FILE_NAME_ENCODING, DOC_ENCODING_FOR_INPUT_FILE_NAME and
> DOC_ENCODING_FOR_OUTPUT_FILE_NAME.

I'm coming back to these again.  I found the LOCALE_ prefix confusing
as the locale is what was used if the variables were *not* set.  The
variables seem to have been named from the point of view of the program
and not the point of view of the user.

I also found the interactions among the variables difficult to understand.
Here's what the current draft of the manual say (I have to look it up
because I have forgotten what the behaviour was supposed to be):

‘LOCALE_INPUT_FILE_NAME_ENCODING’
     Encoding used for input file names if
     ‘DOC_ENCODING_FOR_INPUT_FILE_NAME’ is unset.  Default is based on
     the locale encoding.

‘LOCALE_OUTPUT_FILE_NAME_ENCODING’
     Encoding for output file names if
     ‘DOC_ENCODING_FOR_INPUT_FILE_NAME’ is unsed.  Default is based on
     the locale encoding.

...

‘DOC_ENCODING_FOR_INPUT_FILE_NAME’
     If set, use the input Texinfo document encoding information for the
     encoding of input file names, such as file names specified as
     ‘@include’ or ‘@verbatiminclude’ arguments.  If unset, use
     ‘LOCALE_INPUT_FILE_NAME_ENCODING’ value instead.  Default is set.
     Note that this is for file names only, ‘@documentencoding’ is
     always used for the encoding of file content (*note
     @documentencoding::).

‘DOC_ENCODING_FOR_OUTPUT_FILE_NAME’
     If set, use the input Texinfo document encoding information for the
     encoding of output file names, such as files specified with
     ‘--output’.  If unset, use ‘LOCALE_OUTPUT_FILE_NAME_ENCODING’
     value.  Default is unset.  Note that this is for file names only,
     ‘OUTPUT_ENCODING_NAME’ is used for the encoding of file content.


(I assume it's a mistake in the documentation of
LOCALE_OUTPUT_FILE_NAME_ENCODING as it should refer to
‘DOC_ENCODING_FOR_OUTPUT_FILE_NAME’ instead.)

I think it's better if variables don't have to be set in combination.
I feel that we could design a better interface.  Here's my attempt...

Options to allow:
* Use document encoding
* Use locale encoding
* Specify encoding explicitly

It's difficult to do this with one or even two variables.  Variables
can be booleans (as in DOC_ENCODING_FOR_INPUT_FILE_NAME above) or strings.

If the user specifies the encoding explicitly, they should be able to
do this by setting a single string variable.

If we implemented this, using two string variables like
ENCODING_FOR_INPUT_FILE_NAME and ENCODING_FOR_OUTPUT_FILE_NAME which
took priority over everything else (locale or document settings), perhaps
this would be enough, as it would let the user do everything they wanted
to do by giving encoding names explicitly.

However, we'd need to keep something like DOC_ENCODING_FOR_INPUT_FILE_NAME
as this is needed on MS-Windows and possibly other systems too depending
on the user's setup.

I'm going to make a start by stripping out the LOCALE_ prefix and then
have a look to see if something else is needed to give these variables
priority (from the user's perspective).