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.
