Re: Non-ASCII characters in @include search path

[Gavin Smith]

On Mon, Feb 21, 2022 at 11:34:00PM +0100, Patrice Dumas wrote:
> On Mon, Feb 21, 2022 at 09:29:06PM +0000, Gavin Smith wrote:
> > 
> > Done in commit 73e922d68b.
> 
> I would prefer to have the line numbers in tests, I'll have a look at
> it, but this should be doable without changing the spirit of the commit.
> 
> > There will be a few other places where filenames
> > can find their way into error messages (e.g. include file not found) which
> > will have to be fixed separately.
> 
> You were too fast, but please have a look at my mail, also about using
> an encoding to decode filenames from documents to.  I can do the code if
> you agree on the principle.

I've done more tonight but I still have more to do.  There will have to
be some decoding of filenames when they are being put into
an error message (e.g. "@include: could not find..." and possibly others).
It would make sense to use the document encoding for this.

That's for the error messages.  As for actually finding the files, that's
a different question.  I'll read through what you wrote again and reply
another time.

With the current code, non-ASCII bytes are output incorrectly in the
filename parts of errors from the XS parser.  I intend to fix this
by replacing the code in tp/Texinfo/XS/parsetexi/errors.c that outputs
errors as a dump of Perl code that Perl part of the module has to 'eval'.
Instead, I intend to create the error message data structures more
directly.  This has long been a desideratum for this module.