diff for duplicates of <20210515132344.0206c8fc@coco.lan>

diff --git a/a/1.txt b/N1/1.txt
index 0af070b..4b63203 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -44,7 +44,7 @@ David Woodhouse <dwmw2@infradead.org> escreveu:
 > *happens* to be UTF-8.
 > 
 > UTF-8 *happens* to be compatible with ASCII for the limited subset of
-> characters which ASCII contains, sure — just as *many*, but not all, of
+> characters which ASCII contains, sure ? just as *many*, but not all, of
 > the legacy 8-bit character sets are also a superset of ASCII's 7 bits.
 > 
 > But if the docs contain *any* characters which aren't ASCII, and you
@@ -55,12 +55,12 @@ David Woodhouse <dwmw2@infradead.org> escreveu:
 > instead of making stupid and bogus assumptions based on a system
 > default.
 > 
-> You concede keeping U+00a9 © COPYRIGHT SIGN. And that's encoded in UTF-
+> You concede keeping U+00a9 ? COPYRIGHT SIGN. And that's encoded in UTF-
 > 8 as two bytes 0xC2 0xA9. If some broken build system *assumes* those
 > bytes are ISO8859-15 it'll take them to mean two separate characters
 > 
->     U+00C2 Â LATIN CAPITAL LETTER A WITH CIRCUMFLEX
->     U+00A9 © COPYRIGHT SIGN
+>     U+00C2 ? LATIN CAPITAL LETTER A WITH CIRCUMFLEX
+>     U+00A9 ? COPYRIGHT SIGN
 > 
 > Your broken build system that started all this is never going to be
 > *anything* other than broken. You can only paper over the cracks and
@@ -103,7 +103,7 @@ reproduce it and to address it, I'll post a separate series.
 If you want to discuss this issue further, let's not discuss here, but
 instead, at the linux-doc thread:
 
-	https://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/
+	https://lore.kernel.org/linux-doc/20210506103913.GE6564 at kitsune.suse.cz/
 
 > 
 > 
@@ -137,7 +137,7 @@ Yes. That's what I said.
 > > So, I'll post a v3 of this series, changing only:
 > > 
 > >         - U+00a0 (' '): NO-BREAK SPACE
-> >         - U+feff (''): ZERO WIDTH NO-BREAK SPACE (BOM)  
+> >         - U+feff ('?'): ZERO WIDTH NO-BREAK SPACE (BOM)  
 > 
 > Ack, as long as those make *no* mention of UTF-8. Except perhaps to
 > note that BOM is redundant because UTF-8 doesn't have a byteorder.
@@ -153,10 +153,10 @@ are displayed the same way, and BOM is invisible.
 > > 
 > > 5. curly commas:
 > > 
-> >         - U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
-> >         - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
-> >         - U+201c ('“'): LEFT DOUBLE QUOTATION MARK
-> >         - U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
+> >         - U+2018 ('?'): LEFT SINGLE QUOTATION MARK
+> >         - U+2019 ('?'): RIGHT SINGLE QUOTATION MARK
+> >         - U+201c ('?'): LEFT DOUBLE QUOTATION MARK
+> >         - U+201d ('?'): RIGHT DOUBLE QUOTATION MARK
 > > 
 > > IMO, those should be replaced by ASCII commas: ' and ".
 > > 
@@ -164,7 +164,7 @@ are displayed the same way, and BOM is invisible.
 > > 
 > > - most were introduced during the conversion from Docbook,
 > >   markdown and LaTex;
-> > - they don't add any extra value, as using "foo" of “foo” means
+> > - they don't add any extra value, as using "foo" of ?foo? means
 > >   the same thing;
 > > - Sphinx already use "fancy" commas at the output. 
 > > 
@@ -253,9 +253,9 @@ So, my vote here is to keep aspas as plain ASCII.
 > > 
 > > 6. Hyphen/Dashes and ellipsis
 > > 
-> >         - U+2212 ('−'): MINUS SIGN
-> >         - U+00ad (''): SOFT HYPHEN
-> >         - U+2010 ('‐'): HYPHEN
+> >         - U+2212 ('?'): MINUS SIGN
+> >         - U+00ad ('?'): SOFT HYPHEN
+> >         - U+2010 ('?'): HYPHEN
 > > 
 > >             Those three are used on places where a normal ASCII hyphen/minus
 > >             should be used instead. There are even a couple of C files which
@@ -265,9 +265,9 @@ So, my vote here is to keep aspas as plain ASCII.
 > 
 > That seems to make sense.
 > 
-> >         - U+2013 ('–'): EN DASH
-> >         - U+2014 ('—'): EM DASH
-> >         - U+2026 ('…'): HORIZONTAL ELLIPSIS
+> >         - U+2013 ('?'): EN DASH
+> >         - U+2014 ('?'): EM DASH
+> >         - U+2026 ('?'): HORIZONTAL ELLIPSIS
 > > 
 > >             Those are auto-replaced by Sphinx from "--", "---" and "...",
 > >             respectively.
@@ -284,7 +284,7 @@ So, my vote here is to keep aspas as plain ASCII.
 > >   
 > 
 > Again using the trigraph-like '--' and '...' instead of just using the
-> plain text '—' and '…' breaks searching, because what's in the output
+> plain text '?' and '?' breaks searching, because what's in the output
 > doesn't match the input. Again consistency is good, but perhaps we
 > should standardise on just putting these in their plain text form
 > instead of the trigraphs?
@@ -301,19 +301,19 @@ the same.
 > 
 > > 7. math symbols:
 > > 
-> >         - U+00d7 ('×'): MULTIPLICATION SIGN
+> >         - U+00d7 ('?'): MULTIPLICATION SIGN
 > > 
 > >            This one is used mostly do describe video resolutions, but this is
 > >            on a smaller changeset than the ones that use "x" letter.  
 > 
-> I think standardising on × for video resolutions in documentation would
+> I think standardising on ? for video resolutions in documentation would
 > make it look better and be easier to read.
 > 
 > > 
-> >         - U+2217 ('∗'): ASTERISK OPERATOR
+> >         - U+2217 ('?'): ASTERISK OPERATOR
 > > 
 > >            This is used only here:
-> >                 Documentation/filesystems/ext4/blockgroup.rst:filesystem size to 2^21 ∗ 2^27 = 2^48bytes or 256TiB.
+> >                 Documentation/filesystems/ext4/blockgroup.rst:filesystem size to 2^21 ? 2^27 = 2^48bytes or 256TiB.
 > > 
 > >            Probably added by some conversion tool. IMO, this one should
 > >            also be replaced by an ASCII asterisk.
diff --git a/a/content_digest b/N1/content_digest
index af713d8..15b8cdd 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -5,37 +5,9 @@
  "ref\020210515102239.2ffd0451@coco.lan\0"
  "ref\0c2a4cb8457823685ecba6833d57047d059b36fbb.camel@infradead.org\0"
  "From\0Mauro Carvalho Chehab <mchehab+huawei@kernel.org>\0"
- "Subject\0Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols\0"
+ "Subject\0[Intel-wired-lan] [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols\0"
  "Date\0Sat, 15 May 2021 13:23:44 +0200\0"
- "To\0David Woodhouse <dwmw2@infradead.org>\0"
- "Cc\0alsa-devel@alsa-project.org"
-  kvm@vger.kernel.org
-  Linux Doc Mailing List <linux-doc@vger.kernel.org>
-  linux-iio@vger.kernel.org
-  linux-pci@vger.kernel.org
-  keyrings@vger.kernel.org
-  linux-sgx@vger.kernel.org
-  Jonathan Corbet <corbet@lwn.net>
-  linux-rdma@vger.kernel.org
-  linux-acpi@vger.kernel.org
-  Mali DP Maintainers <malidp@foss.arm.com>
-  linux-input@vger.kernel.org
-  intel-wired-lan@lists.osuosl.org
-  linux-ext4@vger.kernel.org
-  intel-gfx@lists.freedesktop.org
-  linux-media@vger.kernel.org
-  linux-pm@vger.kernel.org
-  coresight@lists.linaro.org
-  rcu@vger.kernel.org
-  mjpeg-users@lists.sourceforge.net
-  linux-arm-kernel@lists.infradead.org
-  linux-edac@vger.kernel.org
-  linux-hwmon@vger.kernel.org
-  netdev@vger.kernel.org
-  linux-usb@vger.kernel.org
-  linux-kernel@vger.kernel.org
-  linux-f2fs-devel@lists.sourceforge.net
- " linux-integrity@vger.kernel.org\0"
+ "To\0intel-wired-lan@osuosl.org\0"
  "\00:1\0"
  "b\0"
  "Em Sat, 15 May 2021 10:24:28 +0100\n"
@@ -84,7 +56,7 @@
  "> *happens* to be UTF-8.\n"
  "> \n"
  "> UTF-8 *happens* to be compatible with ASCII for the limited subset of\n"
- "> characters which ASCII contains, sure \342\200\224 just as *many*, but not all, of\n"
+ "> characters which ASCII contains, sure ? just as *many*, but not all, of\n"
  "> the legacy 8-bit character sets are also a superset of ASCII's 7 bits.\n"
  "> \n"
  "> But if the docs contain *any* characters which aren't ASCII, and you\n"
@@ -95,12 +67,12 @@
  "> instead of making stupid and bogus assumptions based on a system\n"
  "> default.\n"
  "> \n"
- "> You concede keeping U+00a9 \302\251 COPYRIGHT SIGN. And that's encoded in UTF-\n"
+ "> You concede keeping U+00a9 ? COPYRIGHT SIGN. And that's encoded in UTF-\n"
  "> 8 as two bytes 0xC2 0xA9. If some broken build system *assumes* those\n"
  "> bytes are ISO8859-15 it'll take them to mean two separate characters\n"
  "> \n"
- ">     U+00C2 \303\202 LATIN CAPITAL LETTER A WITH CIRCUMFLEX\n"
- ">     U+00A9 \302\251 COPYRIGHT SIGN\n"
+ ">     U+00C2 ? LATIN CAPITAL LETTER A WITH CIRCUMFLEX\n"
+ ">     U+00A9 ? COPYRIGHT SIGN\n"
  "> \n"
  "> Your broken build system that started all this is never going to be\n"
  "> *anything* other than broken. You can only paper over the cracks and\n"
@@ -143,7 +115,7 @@
  "If you want to discuss this issue further, let's not discuss here, but\n"
  "instead, at the linux-doc thread:\n"
  "\n"
- "\thttps://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/\n"
+ "\thttps://lore.kernel.org/linux-doc/20210506103913.GE6564 at kitsune.suse.cz/\n"
  "\n"
  "> \n"
  "> \n"
@@ -177,7 +149,7 @@
  "> > So, I'll post a v3 of this series, changing only:\n"
  "> > \n"
  "> >         - U+00a0 (' '): NO-BREAK SPACE\n"
- "> >         - U+feff ('\357\273\277'): ZERO WIDTH NO-BREAK SPACE (BOM)  \n"
+ "> >         - U+feff ('?'): ZERO WIDTH NO-BREAK SPACE (BOM)  \n"
  "> \n"
  "> Ack, as long as those make *no* mention of UTF-8. Except perhaps to\n"
  "> note that BOM is redundant because UTF-8 doesn't have a byteorder.\n"
@@ -193,10 +165,10 @@
  "> > \n"
  "> > 5. curly commas:\n"
  "> > \n"
- "> >         - U+2018 ('\342\200\230'): LEFT SINGLE QUOTATION MARK\n"
- "> >         - U+2019 ('\342\200\231'): RIGHT SINGLE QUOTATION MARK\n"
- "> >         - U+201c ('\342\200\234'): LEFT DOUBLE QUOTATION MARK\n"
- "> >         - U+201d ('\342\200\235'): RIGHT DOUBLE QUOTATION MARK\n"
+ "> >         - U+2018 ('?'): LEFT SINGLE QUOTATION MARK\n"
+ "> >         - U+2019 ('?'): RIGHT SINGLE QUOTATION MARK\n"
+ "> >         - U+201c ('?'): LEFT DOUBLE QUOTATION MARK\n"
+ "> >         - U+201d ('?'): RIGHT DOUBLE QUOTATION MARK\n"
  "> > \n"
  "> > IMO, those should be replaced by ASCII commas: ' and \".\n"
  "> > \n"
@@ -204,7 +176,7 @@
  "> > \n"
  "> > - most were introduced during the conversion from Docbook,\n"
  "> >   markdown and LaTex;\n"
- "> > - they don't add any extra value, as using \"foo\" of \342\200\234foo\342\200\235 means\n"
+ "> > - they don't add any extra value, as using \"foo\" of ?foo? means\n"
  "> >   the same thing;\n"
  "> > - Sphinx already use \"fancy\" commas at the output. \n"
  "> > \n"
@@ -293,9 +265,9 @@
  "> > \n"
  "> > 6. Hyphen/Dashes and ellipsis\n"
  "> > \n"
- "> >         - U+2212 ('\342\210\222'): MINUS SIGN\n"
- "> >         - U+00ad ('\302\255'): SOFT HYPHEN\n"
- "> >         - U+2010 ('\342\200\220'): HYPHEN\n"
+ "> >         - U+2212 ('?'): MINUS SIGN\n"
+ "> >         - U+00ad ('?'): SOFT HYPHEN\n"
+ "> >         - U+2010 ('?'): HYPHEN\n"
  "> > \n"
  "> >             Those three are used on places where a normal ASCII hyphen/minus\n"
  "> >             should be used instead. There are even a couple of C files which\n"
@@ -305,9 +277,9 @@
  "> \n"
  "> That seems to make sense.\n"
  "> \n"
- "> >         - U+2013 ('\342\200\223'): EN DASH\n"
- "> >         - U+2014 ('\342\200\224'): EM DASH\n"
- "> >         - U+2026 ('\342\200\246'): HORIZONTAL ELLIPSIS\n"
+ "> >         - U+2013 ('?'): EN DASH\n"
+ "> >         - U+2014 ('?'): EM DASH\n"
+ "> >         - U+2026 ('?'): HORIZONTAL ELLIPSIS\n"
  "> > \n"
  "> >             Those are auto-replaced by Sphinx from \"--\", \"---\" and \"...\",\n"
  "> >             respectively.\n"
@@ -324,7 +296,7 @@
  "> >   \n"
  "> \n"
  "> Again using the trigraph-like '--' and '...' instead of just using the\n"
- "> plain text '\342\200\224' and '\342\200\246' breaks searching, because what's in the output\n"
+ "> plain text '?' and '?' breaks searching, because what's in the output\n"
  "> doesn't match the input. Again consistency is good, but perhaps we\n"
  "> should standardise on just putting these in their plain text form\n"
  "> instead of the trigraphs?\n"
@@ -341,19 +313,19 @@
  "> \n"
  "> > 7. math symbols:\n"
  "> > \n"
- "> >         - U+00d7 ('\303\227'): MULTIPLICATION SIGN\n"
+ "> >         - U+00d7 ('?'): MULTIPLICATION SIGN\n"
  "> > \n"
  "> >            This one is used mostly do describe video resolutions, but this is\n"
  "> >            on a smaller changeset than the ones that use \"x\" letter.  \n"
  "> \n"
- "> I think standardising on \303\227 for video resolutions in documentation would\n"
+ "> I think standardising on ? for video resolutions in documentation would\n"
  "> make it look better and be easier to read.\n"
  "> \n"
  "> > \n"
- "> >         - U+2217 ('\342\210\227'): ASTERISK OPERATOR\n"
+ "> >         - U+2217 ('?'): ASTERISK OPERATOR\n"
  "> > \n"
  "> >            This is used only here:\n"
- "> >                 Documentation/filesystems/ext4/blockgroup.rst:filesystem size to 2^21 \342\210\227 2^27 = 2^48bytes or 256TiB.\n"
+ "> >                 Documentation/filesystems/ext4/blockgroup.rst:filesystem size to 2^21 ? 2^27 = 2^48bytes or 256TiB.\n"
  "> > \n"
  "> >            Probably added by some conversion tool. IMO, this one should\n"
  "> >            also be replaced by an ASCII asterisk.\n"
@@ -367,4 +339,4 @@
  "Thanks,\n"
  Mauro
 
-6eb52ce9bf15123c2b30653ebee29e2251fd944b52ae872d42c91b42a17a6604
+b1b850897505c8cf28a9bde23ef86099628b8d49d500aafeb4e74d6c8de8bfae
