From: "Martin Liška" <mliska@suse.cz>
To: Eli Zaretskii <eliz@gnu.org>
Cc: joseph@codesourcery.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Port GCC documentation to Sphinx
Date: Fri, 2 Jul 2021 15:23:14 +0200 [thread overview]
Message-ID: <ec481329-a2ac-3574-5fbc-686fae7956d0@suse.cz> (raw)
In-Reply-To: <83im1tj9ci.fsf@gnu.org>
On 7/2/21 12:31 PM, Eli Zaretskii wrote:
>> Cc: joseph@codesourcery.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
>> From: Martin Liška <mliska@suse.cz>
>> Date: Fri, 2 Jul 2021 11:30:02 +0200
>>
>>> So the purpose of having the comma there is to avoid having a period
>>> in the middle of a sentence, which is added by makeinfo (because the
>>> Info readers need that). Having a comma there may seem a bit
>>> redundant, but having a period will definitely look like a typo, if
>>> not confuse the heck out of the reader, especially if you want to use
>>> these inline cross-references so massively.
>>
>> Well, then it's a bug in Makeinfo.
>
> No, it isn't a bug in makeinfo. It's a (mis)feature of the Info
> format: a cross-reference needs to have a punctuation character after
> it, so that Info readers would know where's the end of the node/anchor
> name to which the cross-reference points. Info files are largely
> plain-ASCII files, so the Info readers need help in this case, and
> makeinfo produces what they need.
Indeed. Agree that Info format is legacy format with very limited capability
of a formatting.
>
>>>> What type of conversions and style are going to change with conversion to Sphinx?
>>>
>>> Anything that is different from the style conventions described in the
>>> Texinfo manual. We have many such conventions.
>>
>> Which is supposed to be here:
>> https://www.gnu.org/prep/standards/html_node/Documentation.html#Documentation
>> right?
>>
>> I've just the text. About the shortening of section names in a TOC. I couldn't find
>> it in the GNU Documentation manual.
>
> No, there's also a lot of style guidelines in the Texinfo manual
> itself. Basically, the documentation of almost every Texinfo
> directive includes some style guidelines, and there are also sections
> which are pure guidelines, like the nodes "Conventions", "Node Names",
> "Structuring Command Types", and some others.
You are right, it's mentioned in "Node Names". Anyway, I declare it as a minor
regression to the current format.
>
>>>> Again, please show up concrete examples. What you describe is very theoretical.
>>>
>>> We've already seen one: the style of writing inline cross-references
>>> with the equivalent of @ref. We also saw another: the way you
>>> converted the menus. It is quite clear to me that there will be
>>> others. So I'm not sure why you need more evidence that this could be
>>> a real issue.
>>
>> As explained, @ref are generated by Makeinfo in a strange way.
>> About the menus, I was unable to find it..
>
> See the node "Menu Parts" in the Texinfo manual. If you look at other
> GNU manuals, you will see that it is a de-facto standard to provide
> most menu items with short descriptions.
>
>>> But maybe all of this is intentional: maybe the GCC project
>>> consciously and deliberately decided to move away of the GNU
>>> documentation style and conventions, and replace them with whatever
>>> the Sphinx and RST conventions are? In that case, there's no reason
>>> for me to even mention these aspects.
>>
>> My intention is preserving status quo as much as possible.
>
> Well, but you definitely deviated from the status quo, and it sounds
> like you did that deliberately, without any discussion.
>
>> On the other hand, Sphinx provides quite some nice features why I wanted to use it.
>
> Which features are those?
>
Feel free to read this email discussion, it's mentioned there multiple times what are
main benefits of the transition.
Cheers,
Martin
next prev parent reply other threads:[~2021-07-02 13:23 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1446990946.2994.192.camel@surprise>
[not found] ` <e7f490fc-ab76-5bc5-5e94-1d9f00f34b62@suse.cz>
2021-05-13 11:45 ` RFC: Sphinx for GCC documentation Martin Liška
2021-05-31 13:25 ` GCC documentation: porting to Sphinx Martin Liška
2021-05-31 15:49 ` Michael Matz
2021-06-01 7:31 ` Martin Liška
2021-06-01 13:31 ` Michael Matz
2021-06-02 7:36 ` Martin Liška
2021-06-02 16:05 ` Joel Sherrill
2021-06-02 16:44 ` Joseph Myers
2021-06-03 12:26 ` Martin Liška
2021-06-03 17:16 ` Joseph Myers
2021-06-04 7:27 ` Martin Liška
2021-06-02 17:27 ` Joseph Myers
2021-06-10 14:06 ` Martin Liška
2021-06-10 16:49 ` Joseph Myers
2021-06-11 14:33 ` Martin Liška
2021-06-11 15:50 ` Joseph Myers
2021-06-11 18:48 ` Koning, Paul
2021-06-23 13:13 ` Martin Liška
2021-06-23 16:00 ` Joseph Myers
2021-06-24 14:08 ` Martin Liška
2021-06-25 13:11 ` Martin Liška
2021-06-25 13:14 ` Martin Liška
2021-06-28 10:23 ` Arnaud Charlet
2021-06-28 10:44 ` Martin Liška
2021-06-29 15:54 ` Arnaud Charlet
2021-06-30 7:52 ` Martin Liška
2021-08-10 15:43 ` Martin Liška
2021-08-27 9:31 ` Martin Liška
2021-06-28 12:01 ` [PATCH] Port GCC documentation " Martin Liška
2021-06-28 15:33 ` Joseph Myers
2021-06-29 10:09 ` Martin Liška
2021-06-29 10:50 ` Richard Earnshaw
2021-06-30 4:47 ` Martin Liška
2021-06-30 10:14 ` Richard Earnshaw
2021-06-30 11:58 ` Martin Liška
2021-06-29 16:57 ` Eli Zaretskii
2021-06-29 18:01 ` Eli Zaretskii
2021-06-30 10:11 ` Martin Liška
2021-06-30 10:46 ` Martin Liška
2021-06-30 13:09 ` Eli Zaretskii
2021-07-01 12:44 ` Martin Liška
2021-07-01 13:33 ` Eli Zaretskii
2021-07-01 14:14 ` Martin Liška
2021-07-01 15:06 ` Michael Matz
2021-07-02 9:40 ` Martin Liška
2021-07-02 10:32 ` Eli Zaretskii
2021-07-01 15:44 ` Eli Zaretskii
2021-07-01 16:04 ` Martin Liška
2021-07-01 16:58 ` Eli Zaretskii
2021-07-02 9:30 ` Martin Liška
2021-07-02 10:31 ` Eli Zaretskii
2021-07-02 13:23 ` Martin Liška [this message]
2021-07-02 23:53 ` Hans-Peter Nilsson
2021-07-05 9:17 ` Richard Sandiford
2021-07-05 12:14 ` Eli Zaretskii
2021-07-05 13:03 ` Richard Sandiford
2021-07-12 13:25 ` Benefits of using Sphinx documentation format Martin Liška
2021-07-12 13:39 ` Eli Zaretskii
2021-07-12 13:53 ` Jonathan Wakely
2021-07-12 14:05 ` Jonathan Wakely
2021-07-12 14:16 ` Eli Zaretskii
2021-07-12 14:34 ` Martin Liška
2021-07-12 17:09 ` Eli Zaretskii
2021-07-12 14:12 ` Eli Zaretskii
2021-07-12 14:30 ` Martin Liška
2021-07-12 14:54 ` Matthias Kretz
2021-07-12 17:03 ` Eli Zaretskii
2021-07-12 17:15 ` Jonathan Wakely
2021-07-12 17:23 ` Eli Zaretskii
2021-07-12 17:33 ` Jonathan Wakely
2021-07-13 6:24 ` Richard Biener
2021-07-13 11:52 ` Eli Zaretskii
2021-07-13 12:46 ` Richard Biener
2021-07-13 12:55 ` Eli Zaretskii
2021-08-09 12:12 ` Martin Liška
2021-07-13 14:19 ` Jonathan Wakely
2021-07-12 14:52 ` Jonathan Wakely
2021-07-12 14:54 ` Jonathan Wakely
2021-07-12 17:14 ` Eli Zaretskii
2021-07-12 15:03 ` Jonathan Wakely
2021-07-12 16:00 ` Gavin Smith
2021-07-12 16:15 ` Jonathan Wakely
2022-07-05 12:27 ` Copiable anchor links in gcc manual Gavin Smith
2022-07-05 13:28 ` Jonathan Wakely
2021-07-12 14:37 ` Benefits of using Sphinx documentation format Martin Liška
2021-07-12 17:12 ` Eli Zaretskii
2021-07-12 16:36 ` David Malcolm
2021-07-12 18:23 ` Koning, Paul
2021-06-30 12:26 ` [PATCH] Port GCC documentation to Sphinx Martin Liška
2021-06-30 13:28 ` Martin Liška
2021-06-30 13:38 ` Eli Zaretskii
2021-06-30 14:04 ` Martin Liška
2021-06-30 15:43 ` Eli Zaretskii
2021-07-01 12:31 ` Martin Liška
2021-07-12 17:18 ` Martin Sebor
2021-08-09 12:18 ` Martin Liška
2021-07-13 14:54 ` Tamar Christina
2021-08-09 13:29 ` Martin Liška
2021-06-02 20:41 ` GCC documentation: porting " Martin Sebor
2021-06-03 10:56 ` Martin Liška
2021-06-04 15:10 ` Martin Sebor
2021-06-10 9:07 ` Martin Liška
2021-06-10 13:18 ` Martin Liška
2021-06-10 23:48 ` Martin Sebor
2021-06-11 14:34 ` Martin Liška
2021-06-04 7:55 ` RFC: Sphinx for GCC documentation Tobias Burnus
2021-06-04 14:24 ` Koning, Paul
2021-06-07 13:30 ` Martin Liška
2021-06-07 21:26 ` Bernhard Reutner-Fischer
2021-06-08 7:43 ` Martin Liška
2021-06-07 13:28 ` Martin Liška
2021-06-07 14:19 ` Tobias Burnus
2021-06-10 10:32 ` Martin Liška
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=ec481329-a2ac-3574-5fbc-686fae7956d0@suse.cz \
--to=mliska@suse.cz \
--cc=eliz@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=joseph@codesourcery.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).