Re: Merged indexes with subentries

[Gavin Smith]

On Tue, Nov 19, 2019 at 8:09 PM Akim Demaille <akim.demaille@gmail.com> wrote:
> Structured indexes are great, thanks a lot for this!  However they don't work 
> well for Bison for three different reasons (two "bugs", and one "missing 
> feature"), presented in the attachement.
>
> > @syncodeindex fn cp
> > @syncodeindex vr cp
> > @syncodeindex tp cp
> >
> > @cindex %define @subentry api.cindex
> > @vindex %define @subentry api.vindex
> > @findex %define @subentry api.findex
> >
> > @deffn {Directive} {%define @subentry api.prefix} @{@var{prefix}@}
> > Foo
> > @end deffn
>
>
> gives in PDF:
>
>
> > %
> >
> > %define api.vindex ............................ 1
> > %define api.findex ............................ 1
> > %define api.prefix ............................ 1
> > %define,
> >   api.cindex................................... 1
>
> 1. As you can see, the merged indexes do not get subentries, but plain old 
> entries.

(Apologies for the late response. I have been planning on coming back
to this but expected it to be tricky.)

I've tried to fix this in commit cc8abf17b, so that subentries work
correctly in code indices. More testing is needed.

> 2. api.cindex is typeset in rm, not in tt as I would expected for the code 
> index.

The current behaviour is correct, as cp is the concept index and is
not typeset in a fixed-width font. The fact you merge other indices
into it with @syncodeindex is irrelevant.

An alternative is to merge everything into the function index instead,
e.g. with @syncodeindex cp fn. Then everything would be in
fixed-width.

> 3. I would love to be able to use @subentry in @deffn like structures.  
> Indeed, in Bison that's the way we define our "variable": with its defining 
> %define directive.  Unfortunately that's not what happens here, and I can 
> understand if you reject this.

Not on the horizon, I'm afraid.