(feature) Scripting Astroid: open specific mail or file

[hugoroy]

Not sure if this is already possible with astroid, but this is an interesting script with mutt: http://git.upsilon.cc/?p=utils/org-mutt.git;a=blob_plain;f=mutt-open;hb=HEAD that enables the user to open mutt directly on a specific email found in notmuch (also see this version: https://github.com/hugoroy/org-mutt/blob/mutt-kz/mutt-open)

[gauteh]

It should be, related to #11. Haven't figured out how to open a new window with an argument yet.

In that way calling:

• astroid id:xxxxx@adxxx will open the mail or the search
• astroid -s asdf will open the search asdf
• astroid /path/to/mail.eml will open that email file
• astroid asdf@asdf.as will open a new mail composed to asdf@asdf.as

[ff2000]

Wouldn't it be better to not rely on parsing $1 but rather add new options? e.g.

• astroid -o <path> to open an email file
• astroid -m <addr> to write a new message
• astroid -i <id> to open based on msgid

Just like astroid -s <term> opens a new search.

[gauteh]

With the latest (https://github.com/astroidmail/astroid/commit/b0a7a3a2582a295210f859e857ba3a7c72af0e81) changes to astroid.cc this one should be relatively easy to implement if anyone wants to have a stab.

[dnebauer]

If anyone decides to enhance this feature, my wishlist item is to add the ability to specify an attachment or attachments when creating a new email with --mailto. One of my favorite customisations of mc was a menu option that opened a new draft email in thunderbird with the currently selected files (or current file if none selected) as attachments.

This could possible be done with another command line option (--attach-file?) or by parsing the argument to --mailto. In thunderbird various email elements can be specified in a command line argument. The full syntax is given here, but here is an example from that page:

thunderbird -compose "to='john@example.com,kathy@example.com',cc='britney@example.com',subject='dinner',body='How about dinner tonight?',attachment='C:\temp\info.doc,C:\temp\food.doc'"

The increased flexibility is offset by the fiddly syntax.

Thanks for writing a great program.

[gauteh]

dnebauer writes on januar 3, 2018 11:08:

If anyone decides to enhance this feature, my wishlist item is to add the ability to specify an attachment or attachments when creating a new email with --mailto. One of my favorite customisations of mc was a menu option that opened a new draft email in thunderbird with the currently selected files (or current file if none selected) as attachments.

Good suggestion! Should not be too hard if anyone decides to try.

[mxmehl]

I'd like to add that we should not forget to support the common mailto syntax. So astroid should be able to understand astroid mailto:test@example.com?subject=test%20space.

It should not rely on parameters like -m since these cannot be set in modern Firefox for mailto links for example; apart from the fact that astroid -m mailto:test@example.com causes a wrong addressee.

[gauteh]

Max writes on februar 5, 2018 15:42:

I'd like to add that we should not forget to support the common mailto syntax. So astroid should be able to understand astroid mailto:test@example.com?subject=test%20space.

It should not rely on parameters like -m since these cannot be set in modern Firefox for mailto links for example; apart from the fact that astroid -m mailto:test@example.com causes a wrong addressee.

I think this issue stalled on parsing the input string.

On a slighly different note; I would also like to see support for piped-in messages so that e.g. git send-email can be used with astroid and we'll be able to edit the cover letter before sending.. but I guess that's one for the future.

[igoralmeida]

My use-case for this would be opening a message in the currently running astroid window from org-mode links inside emacs.

I wouldn't mind extra command-line arguments, but the id:xxxxx@adxxx syntax seems more useful than finding the message's filename. Though, since I would create the links from inside astroid anyway, even if filenames were used it would not be the end of the world...

Is there an issue tracking this "parsing the input string" problem/task?

[gauteh]

tor. 20. feb. 2020, 03:15 skrev Igor Almeida notifications@github.com:

My use-case for this would be opening a message in the currently running astroid window from org-mode links inside emacs.

I wouldn't mind extra command-line arguments, but the id:xxxxx@adxxx syntax seems more useful than finding the message's filename. Though, since I would create the links from inside astroid anyway, even if filenames were used it would not be the end of the world...

Is there an issue tracking this "parsing the input string" problem/task?

No, not yet.

[igoralmeida]

Here's a hack for this, feedback welcome:

Keybindings:

thread_index.run(emacsclient org-protocol://capture:/A/thread:%1/no-easy-way-to-get-thread-title)=M-c # org-capture this thread's index
thread_view.run(emacsclient org-protocol://capture:/A/mid:%2/no-easy-way-to-get-message-title)=M-c # org-capture this message's index

With this I can create links using org-capture-templates. The only way I could think of to include titles there would be creating a hook script instead of calling run directly.

Patch:

diff --git a/src/astroid.cc b/src/astroid.cc
index 3d5dc9f..1f8660b 100644
--- a/src/astroid.cc
+++ b/src/astroid.cc
@@ -127,6 +127,7 @@ namespace Astroid {
       ( "test-config,t",  "use test config (same as used when tests are run), only makes sense from the source root")
 # endif
       ( "mailto,m", po::value<ustring>(), "compose mail with mailto url or address")
+      ( "open", po::value<ustring>(), "open a ThreadIndex tab with a given notmuch search term")
       ( "no-auto-poll",   "do not poll automatically")
       ( "disable-log",    "disable logging")
       ( "log-stdout",     "log to stdout regardless of configuration")
@@ -451,6 +452,12 @@ namespace Astroid {
         new_window = false;
       }

+      if (vm.count("open")) {
+          ustring nmterm = vm["open"].as<ustring>();
+          send_open (nmterm);
+          new_window = false;
+      }
+
       if ((vm.count ("start-polling") ? 1:0) + (vm.count ("stop-polling") ? 1:0) + (vm.count("refresh") ? 1:0) > 1) {
           LOG (error) << "only one of --start-polling, --stop-polling and --refresh should be specified";
           return 1;
@@ -545,6 +552,13 @@ namespace Astroid {
     open_new_window ();
   }

+  void Astroid::send_open (ustring term) {
+    LOG (info) << "astroid: open: " << term;
+    MainWindow * mw = (MainWindow*) get_windows ()[0];
+    Mode * ti = new ThreadIndex (mw, term, term);
+    mw->add_mode (ti);
+  }
+
   void Astroid::send_mailto (ustring url) {
     LOG (info) << "astroid: mailto: " << url;

diff --git a/src/astroid.hh b/src/astroid.hh
index f048037..d5a0956 100644
--- a/src/astroid.hh
+++ b/src/astroid.hh
@@ -90,6 +90,7 @@ namespace Astroid {
       void on_quit ();

       void send_mailto (ustring);
+      void send_open (ustring);

       int _hint_level = 0;

One immediate problem is that both astroid --open thread:somethreadid and astroid --open mid:somemessageid will open a threadindex, even if the messageid already gives you a single message, but that's fixable...

I do get a segfault every time I call this, though. Not sure why, but it happens with ./examples/astroid --help as well.

[danielkrajnik]

It would be amazing to have this feature added to the project. Astroid would be really useful in scripts and programs like mutt or mu4e, which don't support html rendering.