[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.

@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.

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

EDIT: also what terminal are you using?

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

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

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? :)

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

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 :)

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).

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).