Support xdg-email via mailto: scheme

[toastal]

https://www.systutorials.com/docs/linux/man/1-xdg-email/

By using the himalaya.desktop file, I discovered new errors

$ xdg-email --body "test"                                      
error: The subcommand 'mailto:?body=test' wasn't recognized
	Did you mean 'mailboxes'?

If you believe you received this message in error, try re-running with 'himalaya -- mailto:?body=test'

USAGE:
    himalaya [OPTIONS] [SUBCOMMAND]

For more information try --help

This looks like the mailto: protocol you might see on an HTML anchor <a href="mailto:[email protected]?body=xx&cc=yy">mail it</a>. With this being the XDG standard, it would be nice if this mailto: were given a special case and handed off to himalaya write. What this would then allow is downstream scripts to hand-off email duty to whatever tool the user has set.

[soywod]

Maybe we should introduce a new subcommand (let's say mailto) for this specific use case. This way we can also replace the Exec command in the .desktop file with himalaya mailto -- %U. What do you think?

[toastal]

I would disagree. As a user, if I saw a application menu item for Himalaya (ala the Start menu in Windows), I would expect:

1. Default terminal opens
2. My default inbox is shown (maybe in the Vim client, I dunno)

This is what the default action should probably be (which is why himalaya with no args does exactly this). I added "Compose" as an Action because it would be the second most common task: starting a blank message.

xdg-email is just going to pass this mailto: scheme to the default command. For reference, thunderbird %U is for Thunderbird.

---

Docs show:

Description

xdg-email opens the user's preferred e-mail composer in order to send a mail to
address(es) or mailto-uri. RFC2368 defines mailto: URIs. xdg-email limits
support to, cc, subject and body fields in mailto-uri, all other fields are
silently ignored. address(es) must follow the syntax of RFC822. Multiple
addresses may be provided as separate arguments.

All information provided on the command line is used to prefill corresponding
fields in the user's e-mail composer. The user will have the opportunity to
change any of this information before actually sending the e-mail.

Examples

xdg-email 'Jeremy White <[email protected]>'
xdg-email --attach /tmp/logo.png \
          --subject 'Logo contest' \
          --body 'Attached you find the logo for the contest.' \
          '[email protected]'
xdg-email --subject 'Your password is about to expire' \
          '[email protected]' '[email protected]' '[email protected]'

which is just handed off to the default .desktop file. I assume given this scheme, the onus is the client is to recognize and use this information. If you do a web search for like "how to send email using default mail app" or whatever, everyone will point you to using xdg-email so it's probably best to support it "as is".

That last command for reference:

$ xdg-email --subject 'Your password is about to expire' \                                                       
                      '[email protected]' '[email protected]' '[email protected]'
error: Found argument 'mailto:[email protected]?subject=Your%20password%20is%20about%20to%20expire&[email protected]&[email protected]' which wasn't expected, or isn't valid in this context

USAGE:
    himalaya [OPTIONS] [SUBCOMMAND]

For more information try --help

Other effects: I would assume this is similar if not exactly what a browser would give you too which is another common vector for opening the TUI.

Thoughts?

[toastal]

I have never written C but here's what NeoMutt appears to be doing

https://github.com/neomutt/neomutt/blob/a5f8317a52aca8dee96335888eb17ac53c959805/main.c#L865

And it being in the main file with argv tells me it's parsed as an input arg.

[soywod]

I totally agree with you. Thank you for your deep analysis.

The template API I refactored recently really looks like the xdg-email one, I think a simple bridge could be enough. I will take care of this one ASAP.

[soywod]

After diving into this issue, I realize that a simple bridge will not be enough. In fact we need to be able to parse the mailto URL scheme (which is specified in the RFC2368). I did not find a crate doing this job. I'm thinking about creating a special crate for this purpose, what do you think @toastal?

[soywod]

Wait, in fact I just tried with https://crates.io/crates/url and it works well. I thought it was only for URLs, but it seems to be more generic. Good news!

[toastal]

Good to hear!

[soywod]

I just pushed a first attempt. Could you try and let me know? Notice that attachments are not handled yet (I would like to validate the model with you first).

[soywod]

Oops, I forgot the From header. I just pushed the fix!

[TornaxO7]

Can this be closed or does this issue still exist?

[soywod]

Well, I would like to wait for @toastal to approve the fix whenever he can. It's been a while tho. Let's wait a bit more before closing!

[toastal]

Approve what?

I haven't seen a new release cut, so I'm still on the latest stable from my package manager.

[TornaxO7]

The master branch has been merged with my PR with several changes. So it might fix your issue as well. Could you please try it again with the master branch?

[soywod]

Approve what?

I haven't seen a new release cut, so I'm still on the latest stable from my package manager.

I was referring to this comment of mine: #162 (comment). I can also put this feature in the next release and I will let you open an issue if sth does not work as expected? I just wanted to be sure to have implemented the thing correctly (as you described).

[toastal]

As I described? 😅 I'm no expert; I was just relaying what other mail apps were doing/expecting. I only vaguely know Rust, but it seems okay. A faster, even slightly broken release would be preferable. Currently the app is mildly broken on Linux because of the desktop file passing in arguments that Himalaya cannot handle which makes it able to but unsuitable to be the default mail app on GNU/Linux.

[soywod]

Alright, then let's see the result in the next release. Thanks!