expose glossary link on hover

[cjerdonek]

BPO	15693
Nosy	@birkenfeld, @ezio-melotti, @bitdancer, @cjerdonek

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2012-08-16.15:48:28.210>
labels = ['type-bug', '3.8', '3.9', '3.10', 'docs']
title = 'expose glossary link on hover'
updated_at = <Date 2020-11-07.00:28:52.660>
user = 'https://github.com/cjerdonek'

bugs.python.org fields:

activity = <Date 2020-11-07.00:28:52.660>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2012-08-16.15:48:28.210>
creator = 'chris.jerdonek'
dependencies = []
files = []
hgrepos = []
issue_num = 15693
keywords = []
message_count = 9.0
messages = ['168388', '168389', '168391', '168393', '168394', '168395', '168398', '169169', '261495']
nosy_count = 5.0
nosy_names = ['georg.brandl', 'ezio.melotti', 'r.david.murray', 'chris.jerdonek', 'docs@python']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15693'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[cjerdonek]

It would be nice if hovering over the right side of the header to a glossary entry would expose a link in the same way that it does for function definitions, etc.

http://docs.python.org/dev/glossary.html#glossary

Otherwise, there doesn't seem to be a convenient way to get a direct link to a glossary entry.

I'm not sure if this issue should also be filed with Sphinx.

[bitdancer]

I think it probably should be filed with sphinx instead, rather than also.

[cjerdonek]

Do we pin the version of Sphinx that we use to generate the documentation? If Sphinx fixes the issue, would we need to make a corresponding change here to reflect the fix?

[bitdancer]

We do pin it, but we generally have no problem with upgrading. I think we generally upgrade it exactly when there is a new Sphinx feature we want for our docs :) We don't maintain local patches to Sphinx (though we do have code that is specific to our docs, using Sphinx's extension mechanisms).

[cjerdonek]

I think we generally upgrade it exactly when there is a new Sphinx feature we want for our docs :)

:) Would the appropriate way to handle it be then to create an issue to "upgrade Sphinx when XXX issue is resolved" and link to the corresponding Sphinx issue?

I also see value in Python being able to track and possibly assist Sphinx in fixing an issue that we want.

Incidentally, bpo-15455 may fall into the same category now that I know more.

[bitdancer]

Well, I think it depends on what we consider the priority of the issue. So, I personally would count this one as low, and would be happy that it gets fixed whenever we happen to upgrade to a version of Sphinx that fixes it. If it is an issue we consider higher priority, then yes linking to the corresponding Sphinx issue here would be appropriate, and we have done that in the past. (My notions are of course not the sole determining factor on the priority.)

In case you don't know, Georg is the primary author/maintainer of Sphinx, and I'm sure he'll be happy for any help you (or others) want to provide :).

By the way, although I use it on my own site I'm not by any means a Sphinx expert, so my thoughts about where this should be changed could be wrong.

[cjerdonek]

I created a Sphinx issue for this here:

https://bitbucket.org/birkenfeld/sphinx/issue/996/expose-glossary-entry-link-on-hover

[cjerdonek]

I submitted a patch for this issue on the Sphinx tracker.