> 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

Signed-off-by: Nicolai Dagestad <nicolai@dagestad.fr>
---

I didn't get any replies begging for this feature, but nobody
opposed the feature either, but since I wan't it here's the more 
complete patch 🙃.

v1 -> v2 
	* Hande aliases regexs in in the invite command as well
	* Run `make fmt`
	* Update the manuals

 CHANGELOG.md           |  1 +
 commands/msg/invite.go | 28 ++++++++++++++++++++++++++--
[message trimmed]

Signed-off-by: Nicolai Dagestad <nicolai@dagestad.fr>
---

The manual says that if one of this-{day,week,year}-time-format is
missing, they fallback to timestamp-format. This fallback only works 
if the corresponding config.This{..}TimeFormat attribute is set to an
empty string, which does not happend if no manual test is made to check 
if the option is present in the config file (go-ini will just fill in 
with the default value if the option is empty or missing)

With this patch, the entry not being in the config file fallbacks to 
timestamp-format but if the entry is there and empty it uses the default
value.
[message trimmed]

Hi,

On Tue Sep 20, 2022 at 10:52 PM CEST, Tim Culverhouse wrote:
> - Add OSC-8 support (and works in aerc with this bump)

Thanks for this, support for OSC-8 is really cool. What I found out when 
trying to impement this a while back was that w3m does not use OSC-8 escape 
codes when displaying it's links, and for HTML email with gigantic links, they 
get split over multiple lines by aerc in a way where the terminal can't 
autodetect them anymore. I would assume that you haven't worked on w3m to make 
make this use case work ?

(Also maybe some piping can be rigged up to escape the links before everything 
get shown in the pager in aerc)

Also I'll run make fmt before submitting the patch...