From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org
Subject: Re: [PATCH] capget.2, execve.2, readv.2, socketpair.2, utime.2, utimensat.2, getloadavg.3, proc.5, mount_namespaces.7, unix.7: ffix
Date: Sat, 21 Nov 2020 22:47:47 +0100 [thread overview]
Message-ID: <2c1df93c-15d9-fb81-b85e-1a4a310b0cac@gmail.com> (raw)
In-Reply-To: <a0006cce-d243-4804-5f47-cd467aa5eb6f@gmail.com>
Hi Alex,
On 11/20/20 10:55 PM, Alejandro Colomar (man-pages) wrote:
> Hi Michael,
>
> As you said in other patches about global changes,
> I completely agree in that such changes,
> if automated in scripts,
> are very dangerous.
>
> That said, yes, internally there's something in my head
> telling me to do such changes when I see them.
>
> And yes, one good reason to fix them is that consistency
> simplifies scripting a lot.
>
> So I tend to slowly fix some of them
> as I see them while fixing similar things.
> But I try not to add so many of those fixes that
> I would distract from the main fix.
>
> The rationale for why some an not other fixes in this specific case:
> I first grepped to find the files the files that contained
> {.IR var [x]}:
> $ grep -rn "^\.I[ |R].* \\[.*\\]" |sort
> (BTW, I forgot to add that script to the commit msg,
> I'll add it in the next version).
>
> And then inside the file I ctrl+F'd '[' to find them.
> That showed me a few more lines than I searched for,
> and found a few more fixes to do.
> They weren't completely unrelated,
> so I added them to the same patch.
> That's why I only changed some of:
>>> -(26) \fIstartcode\fP \ %lu \ [PT]
>>> +.RI "(26) " startcode " %lu [PT]"
> They showed up while finding branckets.
>
> However... if you feel that's still too much for a patch,
> I completely understand it, so I can separate the changes.
It is too much :-).
> Please, tell me your thoughts.
Please, let's just start off with one patch that implements
your original idea: {.IR var [x]} -> {.I var[x]}. Then we can
discuss other changes.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2020-11-21 21:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 17:46 [PATCH] capget.2, execve.2, readv.2, socketpair.2, utime.2, utimensat.2, getloadavg.3, proc.5, mount_namespaces.7, unix.7: ffix Alejandro Colomar
2020-11-20 21:27 ` Michael Kerrisk (man-pages)
2020-11-20 21:55 ` Alejandro Colomar (man-pages)
2020-11-21 21:47 ` Michael Kerrisk (man-pages) [this message]
2020-11-21 22:03 ` [PATCH v2] " Alejandro Colomar
2020-11-21 22:33 ` Michael Kerrisk (man-pages)
2020-11-21 22:34 ` [PATCH v2 2/2] execve.2, proc.5, mount_namespaces.7, unix.7: srcfix Alejandro Colomar
2020-11-21 23:07 ` Alejandro Colomar (mailing lists; readonly)
2020-11-22 22:48 ` Michael Kerrisk (man-pages)
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=2c1df93c-15d9-fb81-b85e-1a4a310b0cac@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=alx.manpages@gmail.com \
--cc=linux-man@vger.kernel.org \
/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 NNTP newsgroup(s).