I'm a Linux sysadmin and I run open source services for free on NixNet
Ticket created by ~amolith on ~sircmpwn/aerc2
A friend of mine just sent me an email and trying to display it caused aerc to crash with the stack trace below. It wasn't until I tried to open it on mobile that I realised exactly why; OpenKeychain said K-9 was requested my friend's key, not mine.
❯ aerc panic: pgpmail: failed to read PGP message: openpgp: incorrect key goroutine 1 [running]: git.sr.ht/~sircmpwn/aerc/lib.NewMessageStoreView.func1(0x55a74e0727a0, 0xc000494f60) /home/amolith/repos/aerc/lib/messageview.go:71 +0x2c9 git.sr.ht/~sircmpwn/aerc/lib.(*MessageStore).Update(0xc0000ac3c0, 0x55a74e07e6a0, 0xc0004ae8c0) /home/amolith/repos/aerc/lib/msgstore.go:236 +0xa6a git.sr.ht/~sircmpwn/aerc/widgets.(*AccountView).onMessage(0xc00020b570, 0x55a74e07e6a0, 0xc0004ae8c0) /home/amolith/repos/aerc/widgets/account.go:265 +0x4ff git.sr.ht/~sircmpwn/aerc/widgets.(*AccountView).Tick(0xc00020b570, 0xc000210e00) /home/amolith/repos/aerc/widgets/account.go:104 +0xa3 git.sr.ht/~sircmpwn/aerc/widgets.(*Aerc).Tick(0xc00012c4d0, 0xc000296100) /home/amolith/repos/aerc/widgets/aerc.go:128 +0x93 main.main() /home/amolith/repos/aerc/aerc.go:185 +0x630
Comment by ~amolith on ~sircmpwn/aerc2
When it crashed, it was just sitting in an account view; I was working on something else in another workspace. This has happened a number of time before.
Ticket created by ~amolith on ~sircmpwn/aerc2
I'm not sure exactly what's causing aerc to crash but here is the stack trace. I'll start another session, log what's going on, and put it here as well.
❯ aerc panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x56498ae15891] goroutine 1 [running]: git.sr.ht/~sircmpwn/aerc/lib/format.ParseMessageFormat(0xc000025a41, 0x1c, 0xc00011e9a0, 0x11, 0xc000024860, 0x10, 0xc000029610, 0x7, 0x0, 0xc000206540, ...) /home/amolith/repos/aerc/lib/format/format.go:149 +0x28a1 git.sr.ht/~sircmpwn/aerc/config.(*TriggersConfig).ExecNewEmail.func1(0xc00011e9a0, 0x11, 0x1, 0x1, 0x2, 0xc0004a0380) /home/amolith/repos/aerc/config/triggers.go:39 +0xaa git.sr.ht/~sircmpwn/aerc/config.(*TriggersConfig).ExecTrigger(0xc000115778, 0xc00002b290, 0x29, 0xc00062da90, 0xc0000cc130, 0xc0000cc150) /home/amolith/repos/aerc/config/triggers.go:26 +0xd6 git.sr.ht/~sircmpwn/aerc/config.(*TriggersConfig).ExecNewEmail(0xc000115778, 0xc0001bd0e8, 0xc000115680, 0xc000206540) /home/amolith/repos/aerc/config/triggers.go:37 +0x9d git.sr.ht/~sircmpwn/aerc/widgets.(*AccountView).onMessage.func1(0xc000206540) /home/amolith/repos/aerc/widgets/account.go:247 +0x50 git.sr.ht/~sircmpwn/aerc/lib.(*MessageStore).Update(0xc00040e780, 0x56498b28d7a0, 0xc0004a0260) /home/amolith/repos/aerc/lib/msgstore.go:220 +0x659 git.sr.ht/~sircmpwn/aerc/widgets.(*AccountView).onMessage(0xc000207260, 0x56498b28d7a0, 0xc0004a0260) /home/amolith/repos/aerc/widgets/account.go:269 +0x1ae git.sr.ht/~sircmpwn/aerc/widgets.(*AccountView).Tick(0xc000207260, 0xc000210a00) /home/amolith/repos/aerc/widgets/account.go:104 +0xa3 git.sr.ht/~sircmpwn/aerc/widgets.(*Aerc).Tick(0xc00012c580, 0xc000216400) /home/amolith/repos/aerc/widgets/aerc.go:128 +0x93 main.main() /home/amolith/repos/aerc/aerc.go:185 +0x630
Comment by ~amolith on ~whereswaldon/arbor-dev
I don't know if there's another standard for application data but I would put it in something like
~/.arborso users don't have a folder cluttering up their home dir. As there isn't really anything they can interact with without wisteria or the GUI application, I don't think it needs to be visible. How that would be implemented on Windows, ¯\_(ツ)_/¯
Comment by ~amolith on ~whereswaldon/arbor-dev
To throw this out there, you could also differentiate between duplicate usernames in the bottom bar where metadata goes. For each user, maybe display a shortened version of their signature ID or
Name#8137as you suggested above. Personally, I like that in combination with colouring their names differently inline. It would be a subtle visual hint right where you're looking but also displayed in a more obvious manner below. It can sometimes be hard to differentiate between two colours so an additional method would be beneficial to include.
Comment by ~amolith on ~whereswaldon/arbor-dev
I don't think it's really worth chasing either; everything's working smoothly at the moment
~amolith assigned ~amolith to #55 on ~whereswaldon/arbor-dev
Comment by ~amolith on ~whereswaldon/arbor-dev
I didn't make clear what I meant. Yes, at the moment it only has one so pressing enter should use it. When it has multiple, however, one of them should be made default and it would use whatever terminal is currently in use but list others if desired. For example running
wisteriais GNOME Terminal should put GNOME Terminal on top and pressing enter would choose that. Runningwisteriain kitty should put kitty on top and pressing enter would choose that instead.
Comment by ~amolith on ~whereswaldon/arbor-dev
I've mocked up what I see on Codepen and what it might look like in bold and with another colour.
My background is set with my GTK theme, not the colour scheme of my terminal or shell.
Comment by ~amolith on ~whereswaldon/arbor-dev
The reason I said adding another might not be the best idea is because there are already two. I'm not sure how colours are defined in wisteria (terminals in general really) but it looks as if they're hardcoded at the moment. My theme is dynamically generated by pywal and based on my current wallpaper. The colours wisteria currently uses aren't the most accessible (especially red) and adding another one will make it harder to come up with a good palette while maintaining a high enough level of contrast with an arbitrary background to make it readable. Right now, my background is #323231, the current message is #FF000, children are #008000, and parents are #FDFD00. The parents look fine but the children and current message are somewhat challenging to read unless you focus on it.
I've mocked up what I see on Codepen and what it might look like in bold and with another colour.
As to your other question, I really don't know 🤷♂️ A large portion of terminal accessibility is based on the background and, when you can't control that, colour choice becomes very hard. I'm thinking there are variables that developers often use and that emulators respect so theirs TUIs conform to the user's chosen theme, whatever it may be.