diff for duplicates of <20210510153807.4405695e@coco.lan>

diff --git a/a/1.txt b/N1/1.txt
index 46502c5..3579f77 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -5,17 +5,17 @@ Edward Cree <ecree.xilinx@gmail.com> escreveu:
 > > The main point on this series is to replace just the occurrences
 > > where ASCII represents the symbol equally well  
 > 
-> > 	- U+2014 ('—'): EM DASH  
+> > 	- 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
+>  serve 'equally well'.  People use em dashes because ? even in
+>  monospace fonts ? they make text easier to read and comprehend, when
 >  used correctly.
 
 True, but if you look at the diff, on several places, IMHO a single
 hyphen would make more sensus. Maybe those places came from a converted
 doc.
 
-> I accept that some of the other distinctions — like en dashes — are
+> 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;
@@ -24,13 +24,13 @@ doc.
 >  (rather than merely typographical), they probably had a reason for
 >  doing so.
 > 
-> > 	- 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  
 > (These are purely typographic, I have no problem with dumping them.)
 > 
-> > 	- U+00d7 ('×'): MULTIPLICATION SIGN  
+> > 	- U+00d7 ('?'): MULTIPLICATION SIGN  
 > Presumably this is appearing in mathematical formulae, in which case
 >  changing it to 'x' loses semantic information.
 > 
@@ -38,26 +38,26 @@ doc.
 > > reason.  
 > NBSP, sure.  That one's probably an artefact of some document format
 >  conversion somewhere along the line, anyway.
-> But what kinds of things with × or — in are going to be grept for?
+> But what kinds of things with ? or ? in are going to be grept for?
 
 Actually, on almost all places, those aren't used inside math formulae, but
 instead, they describe video some resolutions:
 
-	$ git grep × Documentation/
-	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
-	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
-	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF × 1.096
-	Documentation/userspace-api/media/v4l/crop.rst:of 16 × 16 pixels. The source cropping rectangle is set to defaults,
-	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 × 400 pixels at
-	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 × 225 pixels,
-	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 × 224,
-	Documentation/userspace-api/media/v4l/crop.rst:is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
-	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 × 456 pixels. The present scaling factors limit
-	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 × 384, so the driver returns the cropping size 608 × 384
-	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 × 192.
-	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
-	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 × 480
-	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM
+	$ git grep ? Documentation/
+	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080?1920 LCD Panel
+	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080?1920 LCD Panel
+	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF ? 1.096
+	Documentation/userspace-api/media/v4l/crop.rst:of 16 ? 16 pixels. The source cropping rectangle is set to defaults,
+	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 ? 400 pixels at
+	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 ? 225 pixels,
+	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 ? 224,
+	Documentation/userspace-api/media/v4l/crop.rst:is 608 ? 224 (224 ? 2:1 would exceed the limit 400). The offset 0, 0 is
+	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 ? 456 pixels. The present scaling factors limit
+	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 ? 384, so the driver returns the cropping size 608 ? 384
+	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 ? 192.
+	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 ? 625 bits. Struct :c:type:`v4l2_window`
+	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 ? 480
+	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 ? 576 rectangle for PAL and SECAM
 
 it is a way more likely that, if someone wants to grep, they would be 
 doing something like this, in order to get video resolutions:
diff --git a/a/content_digest b/N1/content_digest
index a6f228a..8128a6e 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -3,41 +3,9 @@
  "ref\020210510135518.305cc03d@coco.lan\0"
  "ref\0df6b4567-030c-a480-c5a6-fe579830e8c0@gmail.com\0"
  "From\0Mauro Carvalho Chehab <mchehab+huawei@kernel.org>\0"
- "Subject\0Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII\0"
+ "Subject\0[Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII\0"
  "Date\0Mon, 10 May 2021 15:38:07 +0200\0"
- "To\0Edward Cree <ecree.xilinx@gmail.com>\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
-  linux-fpga@vger.kernel.org
-  dri-devel@lists.freedesktop.org
-  keyrings@vger.kernel.org
-  linux-riscv@lists.infradead.org
-  Jonathan Corbet <corbet@lwn.net>
-  linux-rdma@vger.kernel.org
-  x86@kernel.org
-  linux-acpi@vger.kernel.org
-  intel-wired-lan@lists.osuosl.org
-  linux-input@vger.kernel.org
-  linux-ext4@vger.kernel.org
-  intel-gfx@lists.freedesktop.org
-  linux-media@vger.kernel.org
-  linux-pm@vger.kernel.org
-  linux-sgx@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
- " David Woodhouse <dwmw2@infradead.org>\0"
+ "To\0intel-wired-lan@osuosl.org\0"
  "\00:1\0"
  "b\0"
  "Em Mon, 10 May 2021 14:16:16 +0100\n"
@@ -47,17 +15,17 @@
  "> > The main point on this series is to replace just the occurrences\n"
  "> > where ASCII represents the symbol equally well  \n"
  "> \n"
- "> > \t- U+2014 ('\342\200\224'): EM DASH  \n"
+ "> > \t- U+2014 ('?'): EM DASH  \n"
  "> Em dash is not the same thing as hyphen-minus, and the latter does not\n"
- ">  serve 'equally well'.  People use em dashes because \342\200\224 even in\n"
- ">  monospace fonts \342\200\224 they make text easier to read and comprehend, when\n"
+ ">  serve 'equally well'.  People use em dashes because ? even in\n"
+ ">  monospace fonts ? they make text easier to read and comprehend, when\n"
  ">  used correctly.\n"
  "\n"
  "True, but if you look at the diff, on several places, IMHO a single\n"
  "hyphen would make more sensus. Maybe those places came from a converted\n"
  "doc.\n"
  "\n"
- "> I accept that some of the other distinctions \342\200\224 like en dashes \342\200\224 are\n"
+ "> I accept that some of the other distinctions ? like en dashes ? are\n"
  ">  needlessly pedantic (though I don't doubt there is someone out there\n"
  ">  who will gladly defend them with the same fervour with which I argue\n"
  ">  for the em dash) and I wouldn't take the trouble to use them myself;\n"
@@ -66,13 +34,13 @@
  ">  (rather than merely typographical), they probably had a reason for\n"
  ">  doing so.\n"
  "> \n"
- "> > \t- U+2018 ('\342\200\230'): LEFT SINGLE QUOTATION MARK\n"
- "> > \t- U+2019 ('\342\200\231'): RIGHT SINGLE QUOTATION MARK\n"
- "> > \t- U+201c ('\342\200\234'): LEFT DOUBLE QUOTATION MARK\n"
- "> > \t- U+201d ('\342\200\235'): RIGHT DOUBLE QUOTATION MARK  \n"
+ "> > \t- U+2018 ('?'): LEFT SINGLE QUOTATION MARK\n"
+ "> > \t- U+2019 ('?'): RIGHT SINGLE QUOTATION MARK\n"
+ "> > \t- U+201c ('?'): LEFT DOUBLE QUOTATION MARK\n"
+ "> > \t- U+201d ('?'): RIGHT DOUBLE QUOTATION MARK  \n"
  "> (These are purely typographic, I have no problem with dumping them.)\n"
  "> \n"
- "> > \t- U+00d7 ('\303\227'): MULTIPLICATION SIGN  \n"
+ "> > \t- U+00d7 ('?'): MULTIPLICATION SIGN  \n"
  "> Presumably this is appearing in mathematical formulae, in which case\n"
  ">  changing it to 'x' loses semantic information.\n"
  "> \n"
@@ -80,26 +48,26 @@
  "> > reason.  \n"
  "> NBSP, sure.  That one's probably an artefact of some document format\n"
  ">  conversion somewhere along the line, anyway.\n"
- "> But what kinds of things with \303\227 or \342\200\224 in are going to be grept for?\n"
+ "> But what kinds of things with ? or ? in are going to be grept for?\n"
  "\n"
  "Actually, on almost all places, those aren't used inside math formulae, but\n"
  "instead, they describe video some resolutions:\n"
  "\n"
- "\t$ git grep \303\227 Documentation/\n"
- "\tDocumentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5\" 1080\303\2271920 LCD Panel\n"
- "\tDocumentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95\" 1080\303\2271920 LCD Panel\n"
- "\tDocumentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF \303\227 1.096\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:of 16 \303\227 16 pixels. The source cropping rectangle is set to defaults,\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 \303\227 400 pixels at\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 \303\227 225 pixels,\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 \303\227 224,\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:is 608 \303\227 224 (224 \303\227 2:1 would exceed the limit 400). The offset 0, 0 is\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:rectangle of 608 \303\227 456 pixels. The present scaling factors limit\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:cropping to 640 \303\227 384, so the driver returns the cropping size 608 \303\227 384\n"
- "\tDocumentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 \303\227 192.\n"
- "\tDocumentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 \303\227 625 bits. Struct :c:type:`v4l2_window`\n"
- "\tDocumentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 \303\227 480\n"
- "\tDocumentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 \303\227 576 rectangle for PAL and SECAM\n"
+ "\t$ git grep ? Documentation/\n"
+ "\tDocumentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5\" 1080?1920 LCD Panel\n"
+ "\tDocumentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95\" 1080?1920 LCD Panel\n"
+ "\tDocumentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF ? 1.096\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:of 16 ? 16 pixels. The source cropping rectangle is set to defaults,\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 ? 400 pixels at\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 ? 225 pixels,\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 ? 224,\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:is 608 ? 224 (224 ? 2:1 would exceed the limit 400). The offset 0, 0 is\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:rectangle of 608 ? 456 pixels. The present scaling factors limit\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:cropping to 640 ? 384, so the driver returns the cropping size 608 ? 384\n"
+ "\tDocumentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 ? 192.\n"
+ "\tDocumentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 ? 625 bits. Struct :c:type:`v4l2_window`\n"
+ "\tDocumentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 ? 480\n"
+ "\tDocumentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 ? 576 rectangle for PAL and SECAM\n"
  "\n"
  "it is a way more likely that, if someone wants to grep, they would be \n"
  "doing something like this, in order to get video resolutions:\n"
@@ -146,4 +114,4 @@
  "Thanks,\n"
  Mauro
 
-c0e0b1a6c1cbdf7016a565302059827f0bba0c7bbc5864c554254e22fab598fd
+b4ce65528bbe6984a82180f993db867872b6aeacd5cf84c30db07900bc916b2a
