On Thu, Oct 15, 2026 at 09:39:22AM +0100, Gavin Smith wrote: > On Wed, Oct 14, 2026 at 10:33:02PM +0200, Patrice Dumas wrote: > > On Tue, Oct 13, 2026 at 05:38:45PM +0100, Gavin Smith wrote: > > > "^HIndex: cp" is better in my opinion as it looks better if the user sees > > > it. > > > > Something I had forgotten about is the idea to use a Tag to convey that > > there are no indices and that the previous scheme used for finding > > indices should not be followed. > > > > It could be something like (with 'Ref: ^H' prepended if needed) > > Index: _^?0 > > or any other impossible or improbable value for an index name as > > argument. > > As I understand this would only be useful for a manual that didn't contain > any indices, and which did contain nodes with "Index" in the name. If this > construct occurred, these nodes with "Index" in the name wouldn't be > considered > to be indices.
It did not occur to me that it would only be needed if there are nodes with "Index" in the name in the document. It would even be possible to add it for Info files without index and with "Index" in a node name with a menu in the node (following the code in the standalone Info reader). I propose to add this marker if there is a node name with "Index" in its name and no index in the Info file, independently of menus, to make it simpler. > Your "Index: _^?0" suggestion looks good. > > Another point is that a special syntax may not be necessary. Since we would > always use the index tags in conjunction with the index markers > ^@^H[index^@^], > we could use a normal index name. > > Say the tag table had "Index: cp^?999" and no index was found at byte 999. > This would still count as a use of an index tag in the tag table, so > Info wouldn't look for "Index" in node names to find indices. > > Of course we wouldn't output arbitrary byte offsets like 999 but Info > could process input like "Index: _^?0" using this general rule, exactly > as it would process "Index: cp^?999" if there were no index at byte 999 > - look for an index at byte 0, and fail to find it. Info wouldn't need > to recognize "-" or "0" as special values. Indeed, I had not realized that there is no real need for a special treatment, as the tag would trigger the code that requires index markers. However, I think that it is better to have a documented special case/special name to help Info readers take the right decision regarding this entry. It could be relevant for error reporting, for instance, the Info reader would know that not having an actual Index for _ is expected, while any other name could trigger a warning/log or similar. Another reason why it is important to know that it is not a true index, is if we use the new "Index: XX" tags for other purposes than the i command, for example for new Info readers commands such as something like the g command but for indices. -- Pat
