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. 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. > I do not like that idea than much as it uses the Tag table in a way that > is not consistent with other uses, but I do not see any other obvious > way that reuses the existing Info data but not the locale variables. > > Note that this may be moreeasily dropped if an other change I proposed > is accepted, that Info readers only consider as index a menu with index > markup. > > -- > Pat
