On Mon, Oct 19, 2026 at 07:04:04PM +0200, Patrice Dumas wrote: > On Tue, Oct 13, 2026 at 05:38:45PM +0100, Gavin Smith wrote: > > On Tue, Oct 13, 2026 at 04:34:20PM +0200, Patrice Dumas wrote: > > > On Tue, Oct 13, 2026 at 02:35:00PM +0100, Gavin Smith wrote: > > > > I'm happy with using "^HIndex cp" as an anchor name for the "cp" index. > > > > > > I do not think that it convey that Index is actually a kind of specifier > > > and not a true anchor name. I would prefer: > > > > > > "^HIndex^H cp" > > > or, which would actually be my preferred format: > > > "^HIndex: cp" > > > > "^HIndex: cp" is better in my opinion as it looks better if the user sees > > it. > > I have implemented a support for that and "^HIndex: _" when there is no > @printindex in texi2any, as well as support in the standalone Info > reader. For the standalone Info reader I tested manually, but should > there be tests added? I am not very familiar with the standalone Info > reader tests, and I have even less clue about the expected coverage.
I basically added tests when I felt like it, mainly copying existing tests which were similar. There is no requirement to add tests. They could be useful for testing complicated areas of the code or use cases which are likely to break without anybody noticing them. Basically a new test would have a new file under info/t/infodir which the test script would access. I've had in mind for sometime that the Info tests would benefit from being more self-contained, so not operating on files under t/infodir - creating Info files temporarily during the test. This way you wouldn't have to worry about the effect of changing one of the test files on any test that might reference it. I've never had any reason to work on this, though. As far as I am aware the Info tests currently work well. > My feeling is that it is quite different from texi2any, at least for two > reasons, because testing is more tedious and refactoring is unlikely > (while texi2any is almost continuously refactored). I agree. > I will make some changes to the documentation too. > > What about the emacs reader? I tried to have a look, but it is quite > out of my reach. My reading of the code gives that when calling > Info-index, Info-index-nodes is somehow called, and my reading of > Info-index-nodes is that, for an Info file generated by a recent > texi2any, Info-file-supports-index-cookies returns true and the whole > file is scanned for index markers. > > However, when I tested, an index was only found if the node names has > Index in it, I do not know why. > > So if my reading of the code is correct, reading the tag tables and > using the Index tags could speed up the Emacs Info reader, but would not > be too necessary. I've never touched the Emacs Lisp implementation so can't be of any help here.
