Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 24 Jul 2020 11:33:25 -0600
From:   Jonathan Corbet <corbet@lwn.net>
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Peter Zijlstra <peterz@infradead.org>, linux-doc@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>, Neil Brown <neilb@suse.de>
Subject: Re: Minor RST rant
Message-ID: <20200724113325.44923f75@lwn.net>
In-Reply-To: <20200724132200.51fd2065@oasis.local.home>
References: <20200724132200.51fd2065@oasis.local.home>
Organization: LWN.net
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, 24 Jul 2020 13:22:00 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> > It is tempting to describe the second kind as starting with a
> > component, but that isn't always accurate: a pathname can lack both
> > slashes and components, it can be empty, in other words.  This is
> > generally forbidden in POSIX, but some of those "xxx``at``" system calls
> > in Linux permit it when the ``AT_EMPTY_PATH`` flag is given.  For
> > example, if you have an open file descriptor on an executable file you
> > can execute it by calling `execveat() <execveat_>`_ passing
> > the file descriptor, an empty path, and the ``AT_EMPTY_PATH`` flag.  
> 
> All those `` are throwing me off to understanding what is being written.

Give people a tool, some of them will make more use of it than you might
like. I do my best to push back against excessive markup (which all of the
above qualifies as, as far as I'm concerned), but I can't really even do
that will all that goes through my tree, much less all the docs stuff
merged by others.

The markup in question was seemingly added by Neil; I've added him to CC
in case he wants to comment on it.

I'm not sure what to do other than to continue to push for minimal use of
intrusive markup.

jon