From: Matthew Wilcox <willy@infradead.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
Date: Mon, 10 May 2021 14:59:08 +0100 [thread overview]
Message-ID: <YJk8LMFViV7Z3Uu7@casper.infradead.org> (raw)
In-Reply-To: <df6b4567-030c-a480-c5a6-fe579830e8c0@gmail.com>
On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
>
> > - U+2014 ('?'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
> serve 'equally well'. People use em dashes because ? even in
> monospace fonts ? they make text easier to read and comprehend, when
> used correctly.
> I accept that some of the other distinctions ? like en dashes ? are
> needlessly pedantic (though I don't doubt there is someone out there
> who will gladly defend them with the same fervour with which I argue
> for the em dash) and I wouldn't take the trouble to use them myself;
> but I think there is a reasonable assumption that when someone goes
> to the effort of using a Unicode punctuation mark that is semantic
> (rather than merely typographical), they probably had a reason for
> doing so.
I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has. Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).
You seem quite knowedgeable about the various differences. Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line? https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.
next prev parent reply other threads:[~2021-05-10 13:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 10:26 [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII Mauro Carvalho Chehab
2021-05-10 10:26 ` [Intel-wired-lan] [PATCH 36/53] docs: networking: device_drivers: avoid using UTF-8 chars Mauro Carvalho Chehab
2021-05-10 10:52 ` [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII Thorsten Leemhuis
2021-05-10 11:19 ` Mauro Carvalho Chehab
2021-05-10 12:27 ` Mauro Carvalho Chehab
2021-05-10 10:54 ` David Woodhouse
2021-05-10 11:55 ` Mauro Carvalho Chehab
2021-05-10 13:16 ` Edward Cree
2021-05-10 13:38 ` Mauro Carvalho Chehab
2021-05-10 13:58 ` Edward Cree
2021-05-10 13:59 ` Matthew Wilcox [this message]
2021-05-10 14:33 ` Edward Cree
2021-05-11 9:00 ` Mauro Carvalho Chehab
2021-05-11 9:19 ` David Woodhouse
2021-05-10 13:49 ` David Woodhouse
2021-05-10 19:22 ` Theodore Ts'o
2021-05-11 9:37 ` Mauro Carvalho Chehab
2021-05-11 9:25 ` Mauro Carvalho Chehab
2021-05-10 14:00 ` Ben Boeckel
2021-05-10 21:57 ` Adam Borowski
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=YJk8LMFViV7Z3Uu7@casper.infradead.org \
--to=willy@infradead.org \
--cc=intel-wired-lan@osuosl.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