~john1doe


#131 wrap utility should skip the signature delimiter block 22 days ago

Ticket created by ~john1doe on ~rjarry/aerc

[A] signature block is conventionally delimited from the body of the message by a single line consisting of exactly two hyphens, followed by a space, followed by the end of line (i.e., in C-notation: "-- \n").

As of now, when reflowing, wrap deletes the space that follows the two hyphens, which leads to failing to recognize the signature (for example, if some other program is used as a pager after wrap).

Probably, wrap should just skip ^-- $ lines altogether.

#46 mouse in aerc's terminal doesn't work? a month ago

Comment by ~john1doe on ~rjarry/aerc

@rjarry, it does :) As I said above, it even worked in other applications in aerc's term, the problem was Vim. And now @rockorager's hint, set ttymouse=sgr, seems to solve it (thanks, Tim! As per your question, it's mainly kitty, but I was testing in xterm, too).

So, we can probably close this now, thank you guys for support.

#46 mouse in aerc's terminal doesn't work? a month ago

on ~rjarry/aerc

~john1doe, can you also try :set ttymouse=sgr and see if it fixes it?\

EDIT: also what terminal are you using?

#46 mouse in aerc's terminal doesn't work? a month ago

on ~rjarry/aerc

~john1doe, can you confirm that your mouse works properly outside of aerc's terminal?

#117 'script: completed with status 0' message is not consistent a month ago

Comment by ~john1doe on ~rjarry/aerc

@rjarry You mean, you can't reproduce it with Gmail and the provided scripts?

#117 'script: completed with status 0' message is not consistent a month ago

Ticket created by ~john1doe on ~rjarry/aerc

I'm facing a very strange issue: for certain IMAP providers (like Gmail, and I don't know about other backends) the status line message script: completed with status 0 doesn't always show after running a script via :pipe -b.

First, it wasn't like this before but was introduced somwhere between these commits (I build aerc from time to time and can't reproduce this nuance prior to v.0.12.0-74-g8cd4770f329c, while it does appear in the next build, v.0.12.0-88-ge804fac59f41):

e804fac (2022-10-07) mk: exclude govulncheck from lint (Robin Jarry)
049c723 (2022-10-06) invalidatable: always mark ui as dirty OnInvalidate (Tim Culverhouse)
a49caf9 (2022-10-06) terminal: use Invalidate and QueueRedraw (Tim Culverhouse)
725fe07 (2022-10-06) render: clean up render code (Tim Culverhouse)
bb12491 (2022-10-06) aerc: use single event loop (Tim Culverhouse)
d847073 (2022-10-06) events: introduce AercMsg and QueueRedraw (Tim Culverhouse)
c6561d3 (2022-10-05) forward,recall: fix charsets in part attachment (Koni Marti)
d2f4f12 (2022-10-04) compose: avoid double lock in MouseEvent (Tim Culverhouse)
d99b608 (2022-10-04) imap: fix flags update (Koni Marti)
d3b62dd (2022-10-03) view: add peek flag and propagate (Koni Marti)
e4d418e (2022-10-03) viewer: option to not mark message as seen (Koni Marti)
4c37117 (2022-09-27) worker: use container/list as job queue (Tim Culverhouse)
1c2dd4c (2022-10-03) bindings: properly check for exKey keystrokes (Tim Culverhouse)
150aa0f (2022-10-03) maildir: hide invalid folders (Julian Pidancet)
8cd4770 (2022-09-29) msgstore: fix data race on access to store.needsFlags (Tim Culverhouse)

Second, as I said, it doesn't affect all the IMAP providers (I can reproduce it on Gmail but can't reproduce on some others).

And third, it doesn't happen for all the scripts but just for some. Example:

If I pipe a message to this script:

#!/usr/bin/env bash

Q=$(head -n 10 | grep .)
W=$(echo $Q | grep q)

The message script: completed with status 0 will appear. However, if I add another line, it won't:

#!/usr/bin/env bash

Q=$(head -n 10 | grep .)
W=$(echo $Q | grep q)
E=$(echo $W | grep w)

Any thoughts? :)

#97 Add support for <C-Fn> and <A-Fn> keys? 3 months ago

Ticket created by ~john1doe on ~rjarry/aerc

If it's possible, would be great to have the support for the modifiers and function keys combos, like <C-F1> or <A-F2>.

#46 mouse in aerc's terminal doesn't work? 3 months ago

Comment by ~john1doe on ~rjarry/aerc

May be the resolved/fixed status should be revoked for this not to get buried among closed tickets? It's certainly not resolved from my side :)

#52 Seems like aerc and its :term understand <F13> differently 3 months ago

Comment by ~john1doe on ~rjarry/aerc

What if you set $term to rxvt-256color?

Hhm... Seems like setting $TERM to rxvt-256color somehow reverses the situation (tested in alacritty with aerc version 0.12.0-67-g8e53d330614f):

  • If alacritty sends ^[[25~ as <F13>:
    • I can map it in aerc as <F13>, aerc reacts to these mappings
    • aerc's :term doesn't recognize it: I run :term, launch cat there, press <F13>, see ^@
  • If alacritty sends ^[[1;2P as <F13>:
    • aerc doesn't react to <F13> mappings
    • aerc's :term recognizes it correctly (cat in :term reports ^[[1;2P).

#52 Seems like aerc and its :term understand <F13> differently 3 months ago

Comment by ~john1doe on ~rjarry/aerc

What terminal are you using?

Mainly kitty. But it also fails in xterm and alacritty (though haven't tested it thoroughly there).

It was setting $TERM to xterm-256color,

Just to clarify, I was testing this when the bug with imposed $TERM was already fixed (:term was reporting the inherited $TERM, not xterm-256color).