Message ID | cover.1587487612.git.mchehab+huawei@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | fs: convert remaining docs to ReST file format | expand |
NAK, this makes the document significantly harder to read.
On Tue, Apr 21, 2020 at 06:55:34PM +0200, Christoph Hellwig wrote:
> NAK, this makes the document significantly harder to read.
Really? It reads more easily to me in the new format. Enclosing
section headers in [] is really weird.
On Tue, Apr 21, 2020 at 10:02:23AM -0700, Matthew Wilcox wrote: > On Tue, Apr 21, 2020 at 06:55:34PM +0200, Christoph Hellwig wrote: > > NAK, this makes the document significantly harder to read. > > Really? It reads more easily to me in the new format. Enclosing > section headers in [] is really weird. It wasn't entirely uncommon, but that's not really the point. The Problem is all the weird ".." or "::" annotations that really kill the flow, or things like "|copy|" that have no reason to exist.
On Tue, Apr 21, 2020 at 07:23:37PM +0200, Christoph Hellwig wrote: > On Tue, Apr 21, 2020 at 10:02:23AM -0700, Matthew Wilcox wrote: > > On Tue, Apr 21, 2020 at 06:55:34PM +0200, Christoph Hellwig wrote: > > > NAK, this makes the document significantly harder to read. > > > > Really? It reads more easily to me in the new format. Enclosing > > section headers in [] is really weird. > > It wasn't entirely uncommon, but that's not really the point. The > Problem is all the weird ".." or "::" annotations that really kill > the flow, or things like "|copy|" that have no reason to exist. FWIW, I consider the rst transformations to be an improvement, even when reading them as a text mode. - Ted
On Tue, 21 Apr 2020 19:23:37 +0200 Christoph Hellwig <hch@lst.de> wrote: > On Tue, Apr 21, 2020 at 10:02:23AM -0700, Matthew Wilcox wrote: > > On Tue, Apr 21, 2020 at 06:55:34PM +0200, Christoph Hellwig wrote: > > > NAK, this makes the document significantly harder to read. > > > > Really? It reads more easily to me in the new format. Enclosing > > section headers in [] is really weird. > > It wasn't entirely uncommon, but that's not really the point. The > Problem is all the weird ".." or "::" annotations that really kill > the flow, or things like "|copy|" that have no reason to exist. This sounds sort of like "my markup is good, yours is bad", honestly. If somebody were trying to add bracketed headings to a new document, I suspect we'd get similar complaints. The markup can certainly be toned down. If you don't like |copy|, it can just as easily remain "(c)" or become ©, or just go away entirely. That would get rid of the ".. include:: <isonum.txt>" line too. I would happily make a rule that we don't bother with markup like |copy| anywhere in the kernel docs. The SPDX line is supposed to exist in all files, of course. If Mauro does that, can you live with "::" to mark a literal block? It doesn't seem like a whole lot of noise...? Thanks, jon
On 21/04/2020 18:23, Christoph Hellwig wrote: > It wasn't entirely uncommon, but that's not really the point. The > Problem is all the weird ".." or "::" annotations that really kill > the flow, or things like "|copy|" that have no reason to exist. You aren't supposed to read REST documentation files - as opposed to kerneldoc comments in the C source - any more than you read HTML. [ Exactly what should or should not be in C source kerneldoc is another matter. ] Developers are used to reading plain ol' text files for quick reference. But there is no make target to generate the text files. Can we create a method to build text *output* files?
On Fri, 24 Apr 2020 18:28:54 +0100 Peter Lister <peter@bikeshed.quignogs.org.uk> wrote: > On 21/04/2020 18:23, Christoph Hellwig wrote: > > It wasn't entirely uncommon, but that's not really the point. The > > Problem is all the weird ".." or "::" annotations that really kill > > the flow, or things like "|copy|" that have no reason to exist. > > You aren't supposed to read REST documentation files - as opposed to > kerneldoc comments in the C source - any more than you read HTML. I am sorry, but that is not the approach we take at all. RST was chosen *because* it is readable plain text, and the readability of the source docs is of high importance; that's not going to change. Thanks, jon
On Fri, Apr 24, 2020 at 06:28:54PM +0100, Peter Lister wrote: > On 21/04/2020 18:23, Christoph Hellwig wrote: >> It wasn't entirely uncommon, but that's not really the point. The >> Problem is all the weird ".." or "::" annotations that really kill >> the flow, or things like "|copy|" that have no reason to exist. > > You aren't supposed to read REST documentation files - as opposed to > kerneldoc comments in the C source - any more than you read HTML. And that is the whole problem. Optimizing for reading in a browser might be an okay tradeoff for end-user documentation. But it is absolutely the wrong thing for internal API documentation where you want to jump to them by opening them in the same text editor.
On Tue, Apr 21, 2020 at 04:53:17PM -0600, Jonathan Corbet wrote: > > It wasn't entirely uncommon, but that's not really the point. The > > Problem is all the weird ".." or "::" annotations that really kill > > the flow, or things like "|copy|" that have no reason to exist. > > This sounds sort of like "my markup is good, yours is bad", honestly. If > somebody were trying to add bracketed headings to a new document, I > suspect we'd get similar complaints. Not really. It is a "less markup is better". > The markup can certainly be toned down. If you don't like |copy|, it can > just as easily remain "(c)" or become ©, or just go away entirely. That > would get rid of the ".. include:: <isonum.txt>" line too. I would > happily make a rule that we don't bother with markup like |copy| > anywhere in the kernel docs. That is a good start. > The SPDX line is supposed to exist in all files, of course. No problem with that. I'll happily take a SPDX patch any time. > If Mauro does that, can you live with "::" to mark a literal block? It > doesn't seem like a whole lot of noise...? That is in fact one of my favourite pet pevees with the whole RST thing.
Em Tue, 21 Apr 2020 16:53:17 -0600 Jonathan Corbet <corbet@lwn.net> escreveu: > On Tue, 21 Apr 2020 19:23:37 +0200 > Christoph Hellwig <hch@lst.de> wrote: > > > On Tue, Apr 21, 2020 at 10:02:23AM -0700, Matthew Wilcox wrote: > > > On Tue, Apr 21, 2020 at 06:55:34PM +0200, Christoph Hellwig wrote: > > > > NAK, this makes the document significantly harder to read. > > > > > > Really? It reads more easily to me in the new format. Enclosing > > > section headers in [] is really weird. > > > > It wasn't entirely uncommon, but that's not really the point. The > > Problem is all the weird ".." or "::" annotations that really kill > > the flow, or things like "|copy|" that have no reason to exist. > > This sounds sort of like "my markup is good, yours is bad", honestly. If > somebody were trying to add bracketed headings to a new document, I > suspect we'd get similar complaints. > > The markup can certainly be toned down. If you don't like |copy|, it can > just as easily remain "(c)" or become ©, or just go away entirely. That > would get rid of the ".. include:: <isonum.txt>" line too. I would > happily make a rule that we don't bother with markup like |copy| > anywhere in the kernel docs. > > The SPDX line is supposed to exist in all files, of course. > > If Mauro does that, can you live with "::" to mark a literal block? It > doesn't seem like a whole lot of noise...? Yeah, I can remove most of the markups, preserving the "::". Will send a new patchset in a few. Thanks, Mauro