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
