Hi,

I do see the use for such a feature, I myself have this behaviour 
and a little more in my aerc config:

```
U = :pipe -b bash -c "xurls | rofi -dmenu | url_handler -loglevel none"<Enter> 
Y = :pipe -b bash -c "xurls -r | rofi -dmenu | clipboard"<Enter>
```
Where url_handler[1] is my alternative to xdg-open (because reasons) and 
clipboard does exactly what it sounds like.

I fell like having this outside of aerc makes it more versatile and 
also means less code in aerc which in my opinion is a good thing.

Hi

On Mon May 30, 2022 at 2:16 PM CEST, Ivan Oleynikov wrote:
> 1. Dragging the image with one finger (like scrolling) moves it slower
> than I move my finger over the screen. Almost as if the speed was
> reduced by some coefficient. I wonder if this is the effect of DPI
> scaling on Wayland (my screen is scaled by 1.4, since it's high DPI),
> I'm running Sway.

You seem quite right about that, when changing the scale things feel really 
more slugish. As I said, I am not the original author of these patches but 
I can have a look at the code to see if I can spot the culprit.

But more generally I fell like panning the image with touch is lagging behind

I looked into into OSC8 support a few weeks ago, and I have a few comments about it.
First I would imagine many big links we receive are in html emails. In that case, it will pass through the w3m filter (by default) but w3m does not support OSC8 escape sequences and their codebase is a mess, so trying to implement it was quite a task.
And for links in plain text emails, I think having a filter add the osc8 escape sequence would be best, that would make it easy for anybody not wanting them to not have them but also it would mean that aerc itself wouldn't need to have any special code to handle some content in a special way.
Even then, from what I gathered, {go-,}libvterm used to display the email themselves seem to strip the osc8 escape sequences (that what I assumed at least but seeing that tcell added support for them, maybe they were the culprit)

So what I imagine would need to be done is:
* Add support for osc8 escape sequences in w3m
* Make libvterm (or go-libvterm)
And/or
* Add some code in aerc to use the new osc8 support from tCell if it is needed

On Fri Mar 25, 2022 at 12:08 PM CET, Koni Marti wrote:
> To get your hands on some mbox files, there are two easy options: (1) mark
> messages in aerc and ":pipe tee file.mbox" or (2) go to the message list in
> lists.sr.ht and export the last 30 days as an mbox file.

I am not sure about the format of an mbox, but method 1 doens't look like it
is complete (the mbox exported by sourcehut start every message with "From ...",
and the line ends aren't the same).

> The mbox files can be opened in aerc either from the command line (./aerc
> mbox://<path>) or from a new section in accounts.conf with "source =
> mbox://<path>".

Would it make sense for aerc to open a new instance with only the mbox account

On Fri Mar 18, 2022 at 10:19 PM CET, Robin Jarry wrote:
> Apparently, this is yet another non-standard OSC 8 escape sequence.
>
> https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

I am not sure how standardized any of the OSC escape sequences are, but OSC 8 is at least common
enough to be used in coreutils such as ls so support for it would be that weird.
But anyways, I have had a look into adding support for it into w3m a few weeks back (but wow is that
codebase hard to get into!) and I think go-libvterm removes them before they even get to aerc.
So more work would need to be done before clicking links (including mailto links) in the body of an 
email will be possible.
But having hte OSC 8 sequences would be a great quality of life improvement in the context of aerc.
Very long links get split in a way that makes my terminal not able to auto detect them (I an not
how exactly but I suspect it add a cariage return or something like that). With OSC 8 sequences,

> 2) All patches must be Acked-by or Reviewed-by someone else than their
>    author.

What would be the difference between Acked-by and Reviewed-by here, 
I asume you'd have to review a patch to Ack it, but reviewing a patch you 
don't like and wouldn't ack seems a bit strange 🤔
(Or do you just mean any of those is formulations is acceptable)

All in all I like it, it would make make other people more involved in aerc 
spread the weight of maintenance a bit which I can only imagine is good for 
the project 👍

Aaaaand I included the .editorconfig file I added by mistake, I can send a 
new patch without it if you want...

When using touch, if you the zoom image the image, then lift one finger
and start draging the remaining finger, the image will jump mostly out
of the viewport before starting the zoom.

This is the patch proposed by mlngh[1] on the github PR
regarding enabling touch navigation[2]

1: https://github.com/mlngh
2: https://github.com/eXeC64/imv/pull/245
---
 src/.editorconfig |   3 +
 src/imv.c         |   6 +-
 src/viewport.c    |  42 ++++----
 src/viewport.h    |   8 +-
[message trimmed]

* tap to left/right side to navigate to previous/next image
* tap into the middle to show overlay
* move single touch to pan the image
* pinch in/out to zoom

This is the PR[1] by gg-rewrite[2] for adding touch navigation from
github rebased on HEAD from master.

1: https://github.com/eXeC64/imv/pull/245
2: https://github.com/gg-rewrite
---
 src/imv.c       |  60 +++++++++++
 src/viewport.c  |  51 ++++++---
 src/viewport.h  |  11 +-
[message trimmed]

I have been using the touch navigation PR for about 2 years now 
and it works flawlessly (with the fix posted later in the comments)
So I rebased it on master's HEAD from the new sourcehut repo.

I am not really the one who wrote the code and I tried to make that 
clear in the commits messages. Though I did not use the name and email 
address from the original author for privacy reasons, only their github 
use names.

If you prefer I could try to reach out to the two authors to get there 
aproval before this get merged. (if it does gets marged, in the ~2 years
I have been using it I can't seem to recal ever encountering a bug 🙃)

Nicolai Dagestad (2):