diff for duplicates of <ZN5OJO/xOWUjLK2w@ghost>

diff --git a/a/1.txt b/N1/1.txt
index 2a1189b..aa209e9 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -14,7 +14,7 @@ On Thu, Aug 17, 2023 at 05:05:45AM +0100, Jessica Clarke wrote:
 > >>>>> extensions.
 > >>>>> 
 > >>>>> ---
-> >>>>> This is modifying code that https://lore.kernel.org/lkml/20230731183925.152145-1-namcaov@gmail.com/
+> >>>>> This is modifying code that https://lore.kernel.org/lkml/20230731183925.152145-1-namcaov at gmail.com/
 > >>>>> is also touching.
 > >>>>> 
 > >>>>> ---
@@ -40,7 +40,7 @@ On Thu, Aug 17, 2023 at 05:05:45AM +0100, Jessica Clarke wrote:
 > >> interacted.
 > > 
 > > Huh? Andrew has replied to you twice on your PR, and was the last one to
-> > comment. That’s hardly “has not interacted”.
+> > comment. That?s hardly ?has not interacted?.
 > > 
 I should have been more clear because Andrew was very responsive.
 However, Neel Gala appears to be the "maintainer" in the sense that
@@ -52,18 +52,18 @@ anything in.
 > >> arguments to select which instructions should be included. There is a
 > >> "C" format, but it is actually just a Spike format.
 > > 
-> > So extend it? Or do something with QEMU’s equivalent that expresses it.
+> > So extend it? Or do something with QEMU?s equivalent that expresses it.
 Yes, that is a possibility. To my knowledge GCC and the spec generator
 have moved away from using this repo. Is it still used by QEMU?
 > 
 > Note that every field already identifies the bit order (or, for the
-> case of compressed instructions, register restrictions) since that’s
-> needed to produce the old LaTeX instruction set listings; that’s why
-> there’s jimm20 vs imm20, for example. One could surely encode that in
+> case of compressed instructions, register restrictions) since that?s
+> needed to produce the old LaTeX instruction set listings; that?s why
+> there?s jimm20 vs imm20, for example. One could surely encode that in
 > Python and generate the LaTeX strings from the Python, making the
 > details of the encodings available elsewhere. Or just have your own
 > mapping from name to whatever you need. But, either way, the
-> information should all be there today in the input files, it’s just a
+> information should all be there today in the input files, it?s just a
 > matter of extending the script to produce whatever you want from them.
 All of the LaTeX bit orders were hardcoded in strings. As such, the bit
 order is described for the LaTeX format but not in general. It would not
@@ -164,12 +164,12 @@ that they need.
 > >>>>> 
 > >>>>> -- 
 > >>>>> kvm-riscv mailing list
-> >>>>> kvm-riscv@lists.infradead.org
+> >>>>> kvm-riscv at lists.infradead.org
 > >>>>> http://lists.infradead.org/mailman/listinfo/kvm-riscv
 > >> 
 > >> _______________________________________________
 > >> linux-riscv mailing list
-> >> linux-riscv@lists.infradead.org
+> >> linux-riscv at lists.infradead.org
 > >> http://lists.infradead.org/mailman/listinfo/linux-riscv
 > 
 >
diff --git a/a/content_digest b/N1/content_digest
index e124292..6755445 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -5,40 +5,9 @@
  "ref\012FAB5A9-5723-4A5B-8729-75D8A38921B9@jrtc27.com\0"
  "ref\046884D2C-F3AA-4A83-8295-AE5C0F58FE13@jrtc27.com\0"
  "From\0Charlie Jenkins <charlie@rivosinc.com>\0"
- "Subject\0Re: [PATCH 00/10] RISC-V: Refactor instructions\0"
+ "Subject\0[PATCH 00/10] RISC-V: Refactor instructions\0"
  "Date\0Thu, 17 Aug 2023 09:43:16 -0700\0"
- "To\0Jessica Clarke <jrtc27@jrtc27.com>\0"
- "Cc\0Andrew Jones <ajones@ventanamicro.com>"
-  linux-riscv <linux-riscv@lists.infradead.org>
-  LKML <linux-kernel@vger.kernel.org>
-  kvm@vger.kernel.org
-  kvm-riscv@lists.infradead.org
-  bpf@vger.kernel.org
-  Paul Walmsley <paul.walmsley@sifive.com>
-  Palmer Dabbelt <palmer@dabbelt.com>
-  Albert Ou <aou@eecs.berkeley.edu>
-  Peter Zijlstra <peterz@infradead.org>
-  Josh Poimboeuf <jpoimboe@kernel.org>
-  Jason Baron <jbaron@akamai.com>
-  Steven Rostedt <rostedt@goodmis.org>
-  Ard Biesheuvel <ardb@kernel.org>
-  Anup Patel <anup@brainfault.org>
-  Atish Patra <atishp@atishpatra.org>
-  Alexei Starovoitov <ast@kernel.org>
-  Daniel Borkmann <daniel@iogearbox.net>
-  Andrii Nakryiko <andrii@kernel.org>
-  Martin KaFai Lau <martin.lau@linux.dev>
-  Song Liu <song@kernel.org>
-  Yonghong Song <yhs@fb.com>
-  John Fastabend <john.fastabend@gmail.com>
-  KP Singh <kpsingh@kernel.org>
-  Stanislav Fomichev <sdf@google.com>
-  Hao Luo <haoluo@google.com>
-  Jiri Olsa <jolsa@kernel.org>
- " Bj\303\266rn T\303\266pel <bjorn@kernel.org>"
-  Luke Nelson <luke.r.nels@gmail.com>
-  Xi Wang <xi.wang@gmail.com>
- " Nam Cao <namcaov@gmail.com>\0"
+ "To\0kvm-riscv@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Thu, Aug 17, 2023 at 05:05:45AM +0100, Jessica Clarke wrote:\n"
@@ -57,7 +26,7 @@
  "> >>>>> extensions.\n"
  "> >>>>> \n"
  "> >>>>> ---\n"
- "> >>>>> This is modifying code that https://lore.kernel.org/lkml/20230731183925.152145-1-namcaov@gmail.com/\n"
+ "> >>>>> This is modifying code that https://lore.kernel.org/lkml/20230731183925.152145-1-namcaov at gmail.com/\n"
  "> >>>>> is also touching.\n"
  "> >>>>> \n"
  "> >>>>> ---\n"
@@ -83,7 +52,7 @@
  "> >> interacted.\n"
  "> > \n"
  "> > Huh? Andrew has replied to you twice on your PR, and was the last one to\n"
- "> > comment. That\342\200\231s hardly \342\200\234has not interacted\342\200\235.\n"
+ "> > comment. That?s hardly ?has not interacted?.\n"
  "> > \n"
  "I should have been more clear because Andrew was very responsive.\n"
  "However, Neel Gala appears to be the \"maintainer\" in the sense that\n"
@@ -95,18 +64,18 @@
  "> >> arguments to select which instructions should be included. There is a\n"
  "> >> \"C\" format, but it is actually just a Spike format.\n"
  "> > \n"
- "> > So extend it? Or do something with QEMU\342\200\231s equivalent that expresses it.\n"
+ "> > So extend it? Or do something with QEMU?s equivalent that expresses it.\n"
  "Yes, that is a possibility. To my knowledge GCC and the spec generator\n"
  "have moved away from using this repo. Is it still used by QEMU?\n"
  "> \n"
  "> Note that every field already identifies the bit order (or, for the\n"
- "> case of compressed instructions, register restrictions) since that\342\200\231s\n"
- "> needed to produce the old LaTeX instruction set listings; that\342\200\231s why\n"
- "> there\342\200\231s jimm20 vs imm20, for example. One could surely encode that in\n"
+ "> case of compressed instructions, register restrictions) since that?s\n"
+ "> needed to produce the old LaTeX instruction set listings; that?s why\n"
+ "> there?s jimm20 vs imm20, for example. One could surely encode that in\n"
  "> Python and generate the LaTeX strings from the Python, making the\n"
  "> details of the encodings available elsewhere. Or just have your own\n"
  "> mapping from name to whatever you need. But, either way, the\n"
- "> information should all be there today in the input files, it\342\200\231s just a\n"
+ "> information should all be there today in the input files, it?s just a\n"
  "> matter of extending the script to produce whatever you want from them.\n"
  "All of the LaTeX bit orders were hardcoded in strings. As such, the bit\n"
  "order is described for the LaTeX format but not in general. It would not\n"
@@ -207,14 +176,14 @@
  "> >>>>> \n"
  "> >>>>> -- \n"
  "> >>>>> kvm-riscv mailing list\n"
- "> >>>>> kvm-riscv@lists.infradead.org\n"
+ "> >>>>> kvm-riscv at lists.infradead.org\n"
  "> >>>>> http://lists.infradead.org/mailman/listinfo/kvm-riscv\n"
  "> >> \n"
  "> >> _______________________________________________\n"
  "> >> linux-riscv mailing list\n"
- "> >> linux-riscv@lists.infradead.org\n"
+ "> >> linux-riscv at lists.infradead.org\n"
  "> >> http://lists.infradead.org/mailman/listinfo/linux-riscv\n"
  "> \n"
  >
 
-4f125a2ba51866ddbc90faa7f6a38de6cf3202eb6778f4e91256ac6b0adec27a
+a390ce4f5b9646819097bb6597c397b12be4e4a9029dae5dd9ccf27e7a547dc4
