-
Notifications
You must be signed in to change notification settings - Fork 769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Odd indexing for bitset::set #743
Comments
There is a similar problem with any/bitset::any |
Well, \indexlibrarymember{a}{b} adds "b under a" and "a under b" index entries, so the above is a natural fallout of this design. But I agree it's confusing in this particular case. |
This seems somewhat ad-hoc to me. The general problem is that a single top-level index entry with subentries is used with multiple different meanings that differ across the subentries. Are there more such cases? Is the right answer to randomly select one meaning as the desired one and discard the others? Or should we maybe disambiguate the meaning and keep both entries, such as "set (m)" for the member and "set (t)" for the type or template? |
Good point: Maybe we should just say "set (member)" for the bitset members to disambiguate (and assume a class / template) otherwise). |
Maybe |
... at least for the first-level entry. |
Your commit looks sensible, it's a nice local solution that's adequate for the problem. |
In the index of library names
bitset::set
is grouped underset
along with members ofstd::set
so looks like it's actually a member function,std::set::bitset
The text was updated successfully, but these errors were encountered: