i like pragmatic minimalism



Last active 1 year, 14 days ago


Last active 1 year, 9 months ago

#63 noticeable delay when moving to :next message while in message view with sorted folder 4 months ago

Comment by ~akspecs on ~rjarry/aerc

#63 noticeable delay when moving to :next message while in message view with sorted folder 4 months ago

Ticket created by ~akspecs on ~rjarry/aerc

there is a noticeable delay when switching from message to message while in view mode within a sorted mailbox folder with :prev or :next (J or K with default keybindings).

this delay did not exist prior to e50ab5928475 ('sort: keep sort criteria applied to folder')

expected behaviour: load :next or :prev message quickly with the maildir backend.

problem: messages take as long and sometimes longer to load than with the imap backend.

steps to reproduce: use the maildir backend with a default unsorted config, run :sort (e.g. :sort -r date), view a message and attempt to view the next messages with :next (J).

there is no delay when attempting this on an unsorted maildir.

#62 inconsistent and awkward filtering behaviour 4 months ago

Comment by ~akspecs on ~rjarry/aerc

#62 inconsistent and awkward filtering behaviour 4 months ago

Ticket created by ~akspecs on ~rjarry/aerc

commit c2f4404f 'threading: enable filtering of server-side threads', introduces an inconsistent and awkward behaviour to ':filter -u'.

one can run ':filter -u' with the imap backend, read or mark a message read, and still have the same message in the list of filtered messages until the same filter is applied again. this allows for one to also perform another action to the message (e.g. move / copy / archive). this behaviour was the same before, and after the mentioned commit.

with the maildir backend, another behaviour is observed: running the same ':filter -u' will appear to awkwardly [0] perform live updates to the initial filtered results based on whether the messages still match the initial filter criteria. messages that are (marked) read will no longer appear in the list of filtered messages. one does not have the opportunity to perform an action to the message once it is read like they would have if they were using the imap backend.

"awkward" demonstration: [0]: https://asciinema.org/a/MmWSaQrpIFxpBb2whg9TlFtcU

#58 another panic caused by closing a tab introduced with d7feb56 4 months ago

Ticket created by ~akspecs on ~rjarry/aerc

commit d7feb56 'fix panic on closing a tab' is causing another panic on closing a tab.

there is more than one way to reproduce the issue. here is one approach:

  1. launch an up to date dev build (or a build that includes d7feb56)
  2. open an email
  3. open another tab (e.g. ctrl+t for a terminal tab)
  4. go back to the prior tab with ctrl+p
  5. close it
  6. crash

without d7feb56 this bug cannot be reproduced with these steps.

panic: runtime error: index out of range [7] with length 7 [recovered]
	panic: runtime error: index out of range [7] with length 7

goroutine 1 [running]:
	git.sr.ht/~rjarry/aerc/logging/panic-logger.go:47 +0x6de
panic({0xa69c00, 0xc00043e1c8})
	runtime/panic.go:844 +0x258
git.sr.ht/~rjarry/aerc/lib/ui.(*TabContent).Draw(0xc000440930?, 0xc00027f0e0?)
	git.sr.ht/~rjarry/aerc/lib/ui/tab.go:403 +0x145
git.sr.ht/~rjarry/aerc/lib/ui.(*Grid).Draw(0xc000150630, 0xc00019e2a0)
	git.sr.ht/~rjarry/aerc/lib/ui/grid.go:148 +0x2ff
git.sr.ht/~rjarry/aerc/widgets.(*Aerc).Draw(0xc00044a000, 0xc00019e2a0)
	git.sr.ht/~rjarry/aerc/widgets/aerc.go:182 +0x2e
	git.sr.ht/~rjarry/aerc/lib/ui/ui.go:116 +0x1f7
	git.sr.ht/~rjarry/aerc/aerc.go:228 +0xb74

#363 Add Git LFS support 6 months ago

Comment by ~akspecs on ~sircmpwn/git.sr.ht

#9 Documentation! 11 months ago

~akspecs assigned ~akspecs to #9 on ~akspecs/numbeo-scraping

#2 Add # of contributors to existing data 1 year, 14 days ago

on ~akspecs/numbeo-scraping


#1 refactor json2sqlite.py 1 year, 17 days ago

Ticket created by ~akspecs on ~akspecs/numbeo-scraping

the code should be broken up into as many functions as needed, and guarded.

an obvious benefit of this well be improved maintainability.

this will also give us the opportunity to run specific database update procedures rather than update all of the database at once (this will also help when we implement cli arguments).

example from the refactoring thread on the numbeo-scraping-dev mailing list:

# ...
def main():

if __name__ == '__main__':

#525 abort message and avoid send / reply prompt with non zero exit status of editor 1 year, 3 months ago

Ticket created by ~akspecs on ~sircmpwn/aerc2

aerc aborting a send or reply when the embedded $EDITOR exits with a non zero status would mimic git's behavior when interactively writing a commit with `git commit'.

to reiterate the git example, when the $EDITOR exits with an error, git will cancel the commit.

for example, when using vim one would could exit the editor with `:cq' to force a non-zero exit status. considering that many users of aerc use vim as their $EDITOR, it does not make sense to (prompt to) send a message if the embedded $EDITOR exits with an error.