Re: Non-ASCII characters in @include search path

[Patrice Dumas]

On Tue, Feb 22, 2022 at 08:52:56PM +0000, Gavin Smith wrote:
> 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.

I don't think that the document encoding is the best bet here, the
locale encoding would be a better default, in my opinion.

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

I am building tests with accented characters everywhere to be sure that
we test and handle most if not all cases.

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

Indeed, that would have many advantages.

-- 
Pat