On Tue May 30, 2023 at 4:09 PM CEST, Conrad Hoffmann wrote:
> Hey,
>
> That address is currently not set up, I guess it would make sense to do 
> so, but that's a decision that Drew would ultimately have to make. 
> AFAIK, Eli Schwartz is the maintainer of the Arch packages, both the 
> actual sourcehut packages as well as the python packages needed in 
> addition to what is available upstream. I think he's quite busy, but 
> there is a branch `staging` in sr.ht-pkgbuilds where he commited the 
> update to Python 3.11 ~two weeks ago. He also seems to be active on Github.
>
> That's about all I can tell you, as the Arch packages are not an 
> official SourceHut thing, it's basically just Eli as a volunteer. I too 
> have occasionally not heard from him for a while, but that's just the 

Hi,

I have tried to contact the package maintaner for the arch linux packages and haven't gotten any
answers yet.
The archlinux@sr.ht addresse listed in the packages bounces, and the person I have previously
interacted with regarding sourcehut related packages has not answered and I am not even sure if they
really are the maintainer or if it was just for the python dependencies.

Here's the message I sent:

> Hi,
>
> Over a month ago now, a message was sent out warning about a
> vulnerability in git.sr.ht and hg.sr.ht. It was recommended to upgrade

Hi, 
I just stumbled uppon the new "rust" branch in the aerc repo. This might have been discussed on
the irc channel but I havent been there in a while so I wouldn't know, are there plans to rewrite 
aerc in rust ?

Sure, fine by me

> Thanks for the review Nicolai!
> I've tried searching for existing patches and I'm sorry that I've missed
> your attempt - could've saved some time.
Yeah, I had to look specifically for my email to find it again, lots of stuff has 
happened recently so it looks like it got drowned in other pathes with similar
keywords.

> A usual practice for this is to use a '+' sign, e.g.
> nikolai+something@dagestad.fr. Email services I'm using don't support
> alias filtering on that level, only a wildcard (everything for
> domain).
True, it was only an exemple. I have just gotten used to using a dot as a 
separator because some site decided that a plus could not appear in a valid email 
address...

Hi,
This is similar in the idea to what I wanted to achieve with this patch[1]
some month ago. 

It would be nice if the wildcard was a litle bit more granular, making it possible 
to use wildcards like `name.*@domain.com` for exemple, and also having the possibility 
to have wildcards in the domain part.

The man page would also need to be updated to reflect the new changes.

I haven't tested the code, but it looks good 👍
It would be nice to drop some of my personal patches that I haven't gotten upstream 
yet, thanks 🙃

On Sun Sep 25, 2022 at 11:13 AM CEST, Robin Jarry wrote:
> Moritz Poldrack, Sep 24, 2022 at 10:25:
> Could we avoid adding a new setting and allow glob-like wildcards in the
> existing aliases setting? 

Yeah I suppose it could be done, when I looked at the handling of the aliase key
it looked simpler to have a seccond key since a valid email regex is not necessarly 
a valid email address, but it can be, so having a way to disintguish them didn't 
seem obvious.

> By the way, the comma separated values makes
> no sense here. Wouldn't it be better to use spaces/tabs?
>
> Example:

On Sat Sep 24, 2022 at 10:25 AM CEST, Moritz Poldrack wrote:
> TOML would make that clear as day. Just saying :D
It's true that in this part of the man page, it's not specified that the list 
is comma separated.
But I would agree with you for this case, because there is an ambiguity in the
syntax, A comma has a meaning in some regex contexts but is also used to separate
the list elements so it cannot be used in the regex anyomore...

> @Nicolai: could you please add an example on how this could look like?

Sure, in my accounts.conf I have this line for one of my account after making 
this patch:

```

Sure, no problem. 👍

On Thu Sep 22, 2022 at 6:20 AM CEST, Tim Culverhouse wrote:
> I didn't intend on upstreaming any OSC support to w3m...my intent was
> that aerc now has support for it, so if there is a third part HTML
> renderer that can output OSC8 links, they will work in aerc. I am
> working on a filter that will take long links and shorten them and with
> OSC8 support.
>

Having looked at w3m's code base, I wouldn't ask anybody to do it either x)
Maybe I'll go back and give it another try...

> Something like ...
>
> https://really.long.url.com/?what-are-all-these-trackers-doing-here