public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>,
	Peter Olsson	 <peterdenbra@gmail.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Show name of compiler options when linking
Date: Thu, 04 Apr 2019 13:42:00 -0000	[thread overview]
Message-ID: <1554385325.18132.133.camel@redhat.com> (raw)
In-Reply-To: <CAH6eHdTU0vcFqMritXXf+yJW3KG1KuNOYq-w+JMVccrUMc5pZg@mail.gmail.com>

On Thu, 2019-04-04 at 10:12 +0000, Jonathan Wakely wrote:
> On Thu, 4 Apr 2019 at 11:10, Jonathan Wakely wrote:
> > 
> > On Thu, 4 Apr 2019 at 10:56, Peter Olsson wrote:
> > > 
> > > Hello,
> > > 
> > > I often want to link to specific compiler options in your online
> > > docs
> > > but the problem is that the named anchors are placed after the
> > > name of
> > > the option so when the link is clicked it will only show the
> > > description.
> > > 
> > > Example:
> > >   https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-W
> > > shadow
> > >   Will show the description for -Wshadow but not the name
> > > -Wshadow itself.
> > > 
> > > I think it would be very useful to be able to link in such a way
> > > that
> > > the name of the option also becomes visible. If this somehow
> > > breaks
> > > backwards compatibility you could introduce new ones that refers
> > > to
> > > the name and let the old ones refer to the description like it is
> > > today.
> > 
> > Yes, it's annoying. The HTML is auto-generated by the makeinfo
> > program, so as far as I know we don't have much control over the
> > placement of those anchors.
> 
> Maybe it's because we have @opindex entries after the @item e.g.
> 
> @item -Wfatal-errors
> @opindex Wfatal-errors
> @opindex Wno-fatal-errors
> 
> But I don't know texinfo or makeinfo well enough to be sure, or if we
> can do it differently.

FWIW I started a discussion related to this on the help-texinfo list
here a couple of months ago:
  http://lists.gnu.org/archive/html/help-texinfo/2019-02/msg00000.html

It may be that there's a way of fixing this from the GCC side (either
by changing our macros, or by changing our .texi source), but I'm not
expert enough at texinfo to figure that out.

Dave

      reply	other threads:[~2019-04-04 13:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  9:56 Peter Olsson
2019-04-04 10:11 ` Jonathan Wakely
2019-04-04 10:12   ` Jonathan Wakely
2019-04-04 13:42     ` David Malcolm [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1554385325.18132.133.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=peterdenbra@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).