To me this approach looks very good… this would allow us to keep our keyring in gpg instead of creating a copy for aerc.
https://lists.sr.ht/~sircmpwn/aerc/patches/23678 might be relevant. It can remove the "copy mailto" part, by registering a handler, but would not solve the issue on headless systems. (I am not sure if that is a common use-case… but I doubt it)
archive monthon multiple thousand mail entries (using VG to jump straight to the end of the list) I get:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x563d084f95d9] goroutine 1 [running]: git.sr.ht/~sircmpwn/aerc/commands/msg.Archive.Execute.func1(0x0, 0xc0007d57f0, 0x563d082a74c9) git.sr.ht/~sircmpwn/aerc/commands/msg/archive.go:63 +0x39 git.sr.ht/~sircmpwn/aerc/commands/msg.groupBy(0xc00013a000, 0xbdc, 0xbdc, 0xc0007d5918, 0x0) git.sr.ht/~sircmpwn/aerc/commands/msg/archive.go:109 +0x8d git.sr.ht/~sircmpwn/aerc/commands/msg.Archive.Execute(0xc0000c6580, 0xc00050ca60, 0x2, 0x2, 0x1, 0xc0001aee90) git.sr.ht/~sircmpwn/aerc/commands/msg/archive.go:61 +0x69b git.sr.ht/~sircmpwn/aerc/commands.(*Commands).ExecuteCommand(0xc0000101e8, 0xc0000c6580, 0xc00050ca60, 0x2, 0x2, 0x563d086d8348, 0xc0002667e0) git.sr.ht/~sircmpwn/aerc/commands/commands.go:66 +0xaa main.execCommand(0xc0000c6580, 0xc000252870, 0xc00050ca60, 0x2, 0x2, 0x563d086d6988, 0xc000815a40) git.sr.ht/~sircmpwn/aerc/aerc.go:60 +0x150 main.main.func2(0xc00050ca60, 0x2, 0x2, 0x2, 0x2) git.sr.ht/~sircmpwn/aerc/aerc.go:157 +0x59 git.sr.ht/~sircmpwn/aerc/widgets.(*Aerc).BeginExCommand.func1(0xc00046c720, 0xd) git.sr.ht/~sircmpwn/aerc/widgets/aerc.go:433 +0x88 git.sr.ht/~sircmpwn/aerc/widgets.(*ExLine).Event(0xc000252500, 0x563d086d7248, 0xc000392000, 0xc0002649c0) git.sr.ht/~sircmpwn/aerc/widgets/exline.go:81 +0x138 git.sr.ht/~sircmpwn/aerc/widgets.(*Aerc).Event(0xc0000c6580, 0x563d086d7248, 0xc000392000, 0x7f7ecc37ff00) git.sr.ht/~sircmpwn/aerc/widgets/aerc.go:224 +0x4c3 git.sr.ht/~sircmpwn/aerc/lib/ui.(*UI).Tick(0xc000252870, 0xc00011a200) git.sr.ht/~sircmpwn/aerc/lib/ui/ui.go:98 +0x182 main.main() git.sr.ht/~sircmpwn/aerc/aerc.go:194 +0x6b3
My guess would be that this is caused by intermediary emails not being fetched ahead of time.
Reading up on the format of URLs again helps. The correct format would be
While simple mailto links work just fine, some more complex do not work. As an example:
mailto:firstname.lastname@example.org&subject=Re%3A%20post-titletries to send an email to email@example.com&subject=Re%3A%20post-title which is obviously wrong.
I found the reason: apparently, the
-mswitch is required. Reading the manpage completely instead of just skimming it is helpful.
Hi, compared to a format-patch patchset the pipe-output omits the
Piped from aerc:
Signed-off-by: Name <firstname.lastname@example.org> --- recover.go | 37 +++++++++++++++++++++++++++++++++++++ try-it-out/main.go | 6 ++++++ 2 files changed, 43 insertions(+) create mode 100644 recover.go diff --git a/recover.go b/recover.go new file mode 100644 index 0000000..1492081 --- /dev/null +++ b/recover.go @@ -0,0 +1,37 @@
Output of format-patch:
From 1f0a8611eb300bad2865bf965163a5d51ce983be Mon Sep 17 00:00:00 2001 From: Name <email@example.com> Date: Wed, 21 Apr 2021 21:36:08 +0200 Subject: [PATCH 1/3] added the panic handler Signed-off-by: Name <firstname.lastname@example.org> --- recover.go | 37 +++++++++++++++++++++++++++++++++++++ try-it-out/main.go | 6 ++++++ 2 files changed, 43 insertions(+) create mode 100644 recover.go diff --git a/recover.go b/recover.go new file mode 100644 index 0000000..1492081 --- /dev/null +++ b/recover.go @@ -0,0 +1,37 @@
I assume the headers are cut off.
While similar to #125, this seems to not involve the UID (because I did not mess with that). I have the following setup:
- Encrypted Laptop
- complete GPG-Key used for emails and code signing
- Unencrypted Desktop PC
- sign-only GPG-Key used only for code signing
While I can add my main Key without issues, the sign-only is a different story. I get
We were unable to encrypt a test message with this key
A possible solution I could think of would be another section allowing sign-only keys or just detecting them directly.