everything below --citation follows this line (read-only)-- erased

jonathanwilner commented 3 years ago

Every time I try to reply to a message using org-msg, any text that should be cited is instead removed from the message. This is true in the preview & the final results.

System is Notmuch on Emacs 27.1 or Emacs 28 on Mac OS X Catalina. I'm using Doom Emacs. I've tried the latest version from master as well as the experimental branch. Both produce the same results.

I'm running the latest notmuch from git.

Any ideas?

TimQuelch commented 3 years ago

I believe this is the intended behaviour. If you want to quote something in your reply you should specifically include it above the--citation...-- line in a #+begin_quote ... #+end_quote block

jonathanwilner commented 3 years ago

So, it’s cited below the original email in order to allow the user to copy the text into the right block ? That makes sense.

Is there an example configuration that uses org-msg only for composition, not for replies, In order to still use html mail, but make it less cumbersome to keep threads full of info for others in the email conversation?

jeremy-compostella commented 3 years ago

Is there an example configuration that uses org-msg only for composition, not for replies, In order to still use html mail, but make it less cumbersome to keep threads full of info for others in the email conversation?

Could you be more specific ? I am having a hard understanding your request

whudwl commented 3 years ago

@jeremy-compostella Sorry to intrude. But I was wondering the exact same question when trying to use org-msg with notmuch.

With mu4e, when replying to an email, the original email appears below my reply(below a grey horizontal line), making my reply totally Outlook style.

But with notmuch, my reply would only contain my reply, without the original email below it. (Hence as this issue said, things below --citation follows...--- are erased).

I could not figure out why there is such difference. Would you mind sharing your thoughts? Please let me know in case my description above isn't clear.

whudwl commented 3 years ago

@jeremy-compostella Sorry to intrude. But I was wondering the exact same question when trying to use org-msg with notmuch.

With mu4e, when replying to an email, the original email appears below my reply(below a grey horizontal line), making my reply totally Outlook style.

But with notmuch, my reply would only contain my reply, without the original email below it. (Hence as this issue said, things below --citation follows...--- are erased).

I could not figure out why there is such difference. Would you mind sharing your thoughts? Please let me know in case my description above isn't clear.

I have realized that the problem is the notmuch implementation did not privode a org-msg-save-article-for-reply-notmuch function.

jonathanwilner commented 3 years ago

@whudwl - thank you for intruding! That's precisely the issue. I really appreciate your help documenting what happens and why !

jeremy-compostella commented 3 years ago

@whudwl and @jonathanwilner, feel to volunteer and write this function. I do not use notmuch and I cannot write it.

whudwl commented 3 years ago

just quickly whipped up this piece which seems to work for me. I'm no expert on lisp so this could be totally far from an optimal solution.

(defvar org-msg-notmuch-saved-article-path "")

(defun org-msg-notmuch-save-article (handle)
  "recursively search through the result of (mm-dissect-buffer) and save the text/html part.
path of the saved file is saved in valiable org-msg-notmuch-saved-article-path
"
  (cond
   ((stringp (car handle)) (mapcar #'org-msg-notmuch-save-article (cdr handle)))
   ((bufferp (car handle))
    (if (string= (car (car (cdr handle))) "text/html")
        (progn
          (let ((file (make-temp-file "org-msg" nil ".html")))
            (mm-save-part-to-file handle file)
            (setq org-msg-notmuch-saved-article-path file)))))
   (t
    (mapcar #'org-msg-notmuch-save-article handle))))

(defun org-msg-save-article-for-reply-notmuch ()
  (let ((message-id  (save-excursion
                       (goto-char (point-min))
                       (re-search-forward "In-Reply-To: <\\(.*\\)>")
                       (match-string-no-properties 1))))
    (save-window-excursion
      (let ((notmuch-show-only-matching-messages t))
        (notmuch-show (format "id:%s" message-id)))
      (with-current-notmuch-show-message
       (org-msg-notmuch-save-article (mm-dissect-buffer)))
      (list org-msg-notmuch-saved-article-path))))

jeremy-compostella commented 3 years ago

This is interesting. While I was re-working you code I realized a few things:

it does not save the images or re-bind them in the <img> tags
it does create the header

Then I figured we could re-use the gnus engine.

Does the following work for you ? Note that I reworked some stuff too, so you may have to debug it a little bit.

(defun org-msg-save-article-for-reply-notmuch ()
  (let ((id (trim (org-msg-message-fetch-field "in-reply-to")))
    header parts)
    (cl-flet ((get-field (field)
           (when-let ((value (org-msg-message-fetch-field field)))
         (concat (capitalize field) ": " value))))
      (save-window-excursion
    (let ((notmuch-show-only-matching-messages t))
          (notmuch-show (format "id:%s" (substring id 1 -1))))
    (with-current-notmuch-show-message
     (let ((fields (mapcar #'get-field
                   '("from" "subject" "to" "cc" "date"))))
       (setf header (mapconcat 'identity (delq nil fields) "\n")))
     (setf parts (mm-dissect-buffer)))
      (let* ((browse-url-browser-function #'ignore)
         (save (cl-copy-list gnus-article-browse-html-temp-list)))
    (cl-letf (((symbol-function 'gnus-summary-show-article) #'ignore))
      (save-window-excursion
        (gnus-article-browse-html-parts parts header)))
    (let ((temp-files (cl-set-difference gnus-article-browse-html-temp-list save
                         :test 'string=)))
      (setq gnus-article-browse-html-temp-list save)
      temp-files))))))

It creates a code duplication in OrgMsg that if it that code work will have to be taken care of.

whudwl commented 3 years ago

This is interesting. While I was re-working you code I realized a few things:

it does not save the images or re-bind them in the <img> tags
it does create the header

Then I figured we could re-use the gnus engine.

Does the following work for you ? Note that I reworked some stuff too, so you may have to debug it a little bit.

(defun org-msg-save-article-for-reply-notmuch ()
  (let ((id (trim (org-msg-message-fetch-field "in-reply-to")))
  header parts)
    (cl-flet ((get-field (field)
         (when-let ((value (org-msg-message-fetch-field field)))
       (concat (capitalize field) ": " value))))
      (save-window-excursion
  (let ((notmuch-show-only-matching-messages t))
          (notmuch-show (format "id:%s" (substring id 1 -1))))
  (with-current-notmuch-show-message
   (let ((fields (mapcar #'get-field
                 '("from" "subject" "to" "cc" "date"))))
     (setf header (mapconcat 'identity (delq nil fields) "\n")))
   (setf parts (mm-dissect-buffer)))
      (let* ((browse-url-browser-function #'ignore)
       (save (cl-copy-list gnus-article-browse-html-temp-list)))
  (cl-letf (((symbol-function 'gnus-summary-show-article) #'ignore))
    (save-window-excursion
      (gnus-article-browse-html-parts parts header)))
  (let ((temp-files (cl-set-difference gnus-article-browse-html-temp-list save
                       :test 'string=)))
    (setq gnus-article-browse-html-temp-list save)
    temp-files))))))

It creates a code duplication in OrgMsg that if it that code work will have to be taken care of.

where does the (trim ...) function come from? My emacs couldn't find it.

jeremy-compostella commented 3 years ago

I don't know. I added it for safety but you can probably remove the call to this function.

On Wed, May 5, 2021, 5:57 PM David @.***> wrote:

This is interesting. While I was re-working you code I realized a few things:

it does not save the images or re-bind them in the tags

it does create the header

Then I figured we could re-use the gnus engine.

Does the following work for you ? Note that I reworked some stuff too, so you may have to debug it a little bit.

(defun org-msg-save-article-for-reply-notmuch () (let ((id (trim (org-msg-message-fetch-field "in-reply-to"))) header parts) (cl-flet ((get-field (field) (when-let ((value (org-msg-message-fetch-field field))) (concat (capitalize field) ": " value)))) (save-window-excursion (let ((notmuch-show-only-matching-messages t)) (notmuch-show (format "id:%s" (substring id 1 -1)))) (with-current-notmuch-show-message (let ((fields (mapcar #'get-field '("from" "subject" "to" "cc" "date")))) (setf header (mapconcat 'identity (delq nil fields) "\n"))) (setf parts (mm-dissect-buffer))) (let* ((browse-url-browser-function #'ignore) (save (cl-copy-list gnus-article-browse-html-temp-list))) (cl-letf (((symbol-function 'gnus-summary-show-article) #'ignore)) (save-window-excursion (gnus-article-browse-html-parts parts header))) (let ((temp-files (cl-set-difference gnus-article-browse-html-temp-list save :test 'string=))) (setq gnus-article-browse-html-temp-list save) temp-files))))))

It creates a code duplication in OrgMsg that if it that code work will have to be taken care of.

where does the (trim ...) function come from? My emacs couldn't find it.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jeremy-compostella/org-msg/issues/73#issuecomment-833148516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMACBHUAJRAFIR5F3AO7XTTMHSP7ANCNFSM4R7WSCZA .

whudwl commented 3 years ago

I don't know. I added it for safety but you can probably remove the call to this function. … On Wed, May 5, 2021, 5:57 PM David @.**> wrote: This is interesting. While I was re-working you code I realized a few things: 1. it does not save the images or re-bind them in the tags 2. it does create the header Then I figured we could re-use the gnus engine. Does the following work for you ? Note that I reworked some stuff too, so you may have to debug it a little bit. (defun org-msg-save-article-for-reply-notmuch () (let ((id (trim (org-msg-message-fetch-field "in-reply-to"))) header parts) (cl-flet ((get-field (field) (when-let ((value (org-msg-message-fetch-field field))) (concat (capitalize field) ": " value)))) (save-window-excursion (let ((notmuch-show-only-matching-messages t)) (notmuch-show (format "id:%s" (substring id 1 -1)))) (with-current-notmuch-show-message (let ((fields (mapcar #'get-field '("from" "subject" "to" "cc" "date")))) (setf header (mapconcat 'identity (delq nil fields) "\n"))) (setf parts (mm-dissect-buffer))) (let ((browse-url-browser-function #'ignore) (save (cl-copy-list gnus-article-browse-html-temp-list))) (cl-letf (((symbol-function 'gnus-summary-show-article) #'ignore)) (save-window-excursion (gnus-article-browse-html-parts parts header))) (let ((temp-files (cl-set-difference gnus-article-browse-html-temp-list save :test 'string=))) (setq gnus-article-browse-html-temp-list save) temp-files)))))) It creates a code duplication in OrgMsg that if it that code work will have to be taken care of. where does the (trim ...) function come from? My emacs couldn't find it. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#73 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMACBHUAJRAFIR5F3AO7XTTMHSP7ANCNFSM4R7WSCZA .

I'm getting gnus-article-browse-html-parts: No buffer named *Article* error for most emails. any ideas what could be the issue?

jeremy-compostella commented 3 years ago

What do you mean by most emails? Does it work with some email? What is different in this emails?

whudwl commented 3 years ago

What do you mean by most emails? Does it work with some email? What is different in this emails!

Did a bit of more testing. Seems the error happens when there are inline images.

Sent myself an empty email with an inline image. When replying to it, got the "No buffer named Article" error.
Sent myself an empty email with an image attachment. Replying to it worked fine.

whudwl commented 3 years ago

What do you mean by most emails? Does it work with some email? What is different in this emails!

seems the error is emitted from line 2845 of gnus-art.el.

                (with-current-buffer gnus-article-buffer
                  gnus-article-mime-handles)

the value of the gnus-article-buffer variable is *Article* . Since I don't use gnus, I guess that's the default value.

whudwl commented 3 years ago

It seems gnus relies on the local variable gnus-article-mime-handles in the gnus-article-buffer to save cid contents. so how about this:

(defun org-msg-save-article-for-reply-notmuch ()
  (let ((id (string-trim (org-msg-message-fetch-field "in-reply-to")))
        header parts)
    (cl-flet ((get-field (field)
                         (when-let ((value (org-msg-message-fetch-field field)))
                           (concat (capitalize field) ": " value))))
      (save-window-excursion
        (let ((notmuch-show-only-matching-messages t))
          (notmuch-show (format "id:%s" (substring id 1 -1))))
        (with-current-notmuch-show-message
         (let ((fields (mapcar #'get-field
                               '("from" "subject" "to" "cc" "date"))))
           (setf header (mapconcat 'identity (delq nil fields) "\n")))
         (setf parts (mm-dissect-buffer)))
        (let* ((browse-url-browser-function #'ignore)
               (save (cl-copy-list gnus-article-browse-html-temp-list)))
          (cl-letf (((symbol-function 'gnus-summary-show-article) #'ignore))
            (save-window-excursion
              (setq-local gnus-article-mime-handles parts)
              (let ((gnus-article-buffer (current-buffer)))
                (gnus-article-browse-html-parts parts header))))
          (let ((temp-files (cl-set-difference gnus-article-browse-html-temp-list save
                                               :test 'string=)))
            (setq gnus-article-browse-html-temp-list save)
            temp-files))))))

jeremy-compostella commented 3 years ago

Even simpler:

(defun org-msg-save-article-for-reply-notmuch ()
  (let ((id (trim-string (org-msg-message-fetch-field "in-reply-to")))
    header parts)
    (cl-flet ((get-field (field)
           (when-let ((value (org-msg-message-fetch-field field)))
         (concat (capitalize field) ": " value))))
      (save-window-excursion
    (let ((notmuch-show-only-matching-messages t))
          (notmuch-show (format "id:%s" (substring id 1 -1))))
    (with-current-notmuch-show-message
     (let ((fields (mapcar #'get-field
                   '("from" "subject" "to" "cc" "date"))))
       (setf header (mapconcat 'identity (delq nil fields) "\n")))
     (setf parts (mm-dissect-buffer))))
      (with-temp-buffer
    (let ((gnus-article-buffer (current-buffer))
          (gnus-article-mime-handles parts))
      (let* ((browse-url-browser-function #'ignore)
         (save (cl-copy-list gnus-article-browse-html-temp-list)))
        (cl-letf (((symbol-function 'gnus-summary-show-article) #'ignore))
          (save-window-excursion
        (gnus-article-browse-html-parts parts header)))
        (let ((temp-files (cl-set-difference gnus-article-browse-html-temp-list save
                         :test 'string=)))
          (setq gnus-article-browse-html-temp-list save)
          temp-files)))))))

jeremy-compostella commented 3 years ago

I pushed the improved changes to the experimental branch. On this branch I also implemented org-msg-article-htmlp-notmuch. I don't use notmuch so I can't really test. Could you test and debug the experimental branch ? I tried to unitary test what I can but notmuch specific function are out of reach.

whudwl commented 3 years ago

@jeremy-compostella Thank you so much for that. I did a bit of testing of the experimental branch, made some minor fixes. Now it pretty much works perfectly for me. Have created pull request.

jonathanwilner commented 3 years ago

I've also tested the experimental branch and it's working for me as well using notmuch! Thanks @whudwl + @jeremy-compostella !

whudwl commented 3 years ago

I've also tested the experimental branch and it's working for me as well using notmuch! Thanks @whudwl + @jeremy-compostella !

Emm. Strange. It worked for you as it is? I had to modify it a bit for it to work.

jonathanwilner commented 3 years ago

Yes - each one of these has worked for me out of the box - except for "trim" - which I couldn't find either.

The current experimental branch has a weird "select all" effect where all of the previous message is selected for yank that is going on when the reply is first composed, but it's not holding me back too much.

whudwl commented 3 years ago

I saw that “select all” effect too. I think it’s the result of an error. Lets see if it’s fixed once jemery pulls my change. On 7 May 2021, 8:56 AM +1000, jonathanwilner @.***>, wrote:

Yes - each one of these has worked for me out of the box - except for "trim" - which I couldn't find either. The current experimental branch has a weird "select all" effect where all of the previous message is selected for yank that is going on when the reply is first composed, but it's not holding me back too much. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

jeremy-compostella commented 3 years ago

@whudwl I integrated all your changes. Let me know if it works better. BTW, I removed the call to string-trim because the message-fetch-field function already does it.

jeremy-compostella commented 3 years ago

@jonathanwilner and @whudwl Is the "select all" effect gone now ?

whudwl commented 3 years ago

Yes. Now it works perfectly.

jonathanwilner commented 3 years ago

Yes! Thank you !!!

whudwl commented 3 years ago

@jeremy-compostella , could you perhaps add a line to kill the notmuch buffer after using it? (notmuch-show) Returns the buffer containing the messages. I was testing and replying to the same message again and again, and I end up with a dozen buffers showing the same message.

jeremy-compostella commented 3 years ago

I suggest that you submit a patch.

On Fri, May 7, 2021, 10:25 PM David @.***> wrote:

@jeremy-compostella https://github.com/jeremy-compostella , could you perhaps add a line to kill the notmuch buffer after (notmuch-show) call? (notmuch-show) Returns the buffer containing the messages. I was testing and replying to the same message again and again, and I end up with a dozen buffers showing the same message.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremy-compostella/org-msg/issues/73#issuecomment-835110059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMACBATJSZDQUULYL7WE33TMTDMNANCNFSM4R7WSCZA .

jeremy-compostella commented 3 years ago

@whudwl Let me know if 9be11351 works.

HyunggyuJang commented 3 years ago

@jeremy-compostella Unfortunately, with the changes introduced by this thread, I met an error while trying to reply a mail as usual:

Debugger entered–Lisp error: (invalid-function with-current-notmuch-show-message)
with-current-notmuch-show-message(nil)
org-msg-article-htmlp-notmuch()
apply(org-msg-article-htmlp-notmuch nil)
org-msg-mua-call(article-htmlp)

f(compiled-function (&rest args) “Transform the current `message’ buffer into a OrgMsg buffer.\nIf the current `message’ buffer is a reply, the\n`org-msg-separator’ string is inserted at the end of the editing\narea. If the current buffer contains MML tags,\n`org-msg-edit-mode’ is not activated as OrgMsg does not support\nMML tags.” #<bytecode 0x5c442649>)(“thread:0000000000000a14” nil nil)

apply(#f(compiled-function (&rest args) “Transform the current `message’ buffer into a OrgMsg buffer.\nIf the current `message’ buffer is a reply, the\n`org-msg-separator’ string is inserted at the end of the editing\narea. If the current buffer contains MML tags,\n`org-msg-edit-mode’ is not activated as OrgMsg does not support\nMML tags.” #<bytecode 0x5c442649>) (“thread:0000000000000a14” nil nil))
org-msg-post-setup(“thread:0000000000000a14” nil nil)
apply(org-msg-post-setup (“thread:0000000000000a14” nil nil))
notmuch-mua-reply(“thread:0000000000000a14” nil nil)
notmuch-mua-new-reply(“thread:0000000000000a14” nil nil)
notmuch-search-reply-to-thread-sender(nil)
funcall-interactively(notmuch-search-reply-to-thread-sender nil)
call-interactively(notmuch-search-reply-to-thread-sender nil nil)
command-execute(notmuch-search-reply-to-thread-sender)

I thought it was due to some broken back compatibility changes made in recent notmuch commit, but it was not. I can confirm that such an error doesn’t occur when I reverted to the previous commit.

I wonder, can’t we make this auxiliary feature to let an option? That is, make it customizable. To me, the current implementation doesn’t allow user for any option to off it.

HyunggyuJang commented 3 years ago

Furthermore, I haven’t experienced any inconvenience raised in this issue, and a replied mail also appeared under given thread as well. So for me, this added feature actually doesn’t add any value, but broke my mail replying system.

I have to say this though, your masterpiece is superb, and I can’t imagine how I composed mail before I met this!

Thanks @jeremy-compostella,

Best regards,

– Hyunggyu Jang

jeremy-compostella commented 3 years ago

@HyunggyuJang,

First of all the goal is to get the notmuch backend to the same level than the other backend.

I wonder, can’t we make this auxiliary feature to let an option? That is, make it customizable. To me, the current implementation doesn’t allow user for any option to off it.

You could disable top-posting style by setting org-msg-posting-style to nil as described in the README.org.

However, I still think that we need to understand why isn't with-current-notmuch-show-message defined in your installation. Maybe this is due to the loading order. Make sure you load notmuch-show before you load org-msg.

I have to say this though, your masterpiece is superb, and I can’t imagine how I composed mail before I met this!

Thank you!

jeremy-compostella commented 3 years ago

@whudwl I fixed up my patch with yours. Let me know if 2bfdbff9 is ready to be pushed to master.

jonathanwilner commented 3 years ago

Hi Jeremy,

This is working great for me.

Regards,

– JW //

From: =?UTF-8?B?SsOpcsOpbXkgQ29tcG9zdGVsbGE=?= @.> Subject: Re: [jeremy-compostella/org-msg] everything below --citation follows this line (read-only)-- erased (#73) To: jeremy-compostella/org-msg Cc: jonathanwilner @.>, Mention Date: Tue, 11 May 2021 09:43:02 -0700

@whudwl I fixed up my patch with yours. Let me know if 9be1135 is ready to be pushed to master.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/jeremy-compostella/org-msg/issues/73#issuecomment-838807445", "url": "https://github.com/jeremy-compostella/org-msg/issues/73#issuecomment-838807445", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

whudwl commented 3 years ago

now it's perfection. thank you very much for your efforts.

HyunggyuJang commented 3 years ago

@jeremy-compostella

You could disable top-posting style by setting org-msg-posting-style to nil as described in the README.org.

Sorry for being myopic! It is the time to yell to myself RTFM!!

However, I still think that we need to understand why isn't with-current-notmuch-show-message defined in your installation. Maybe this is due to the loading order. Make sure you load notmuch-show before you load org-msg.

Have played with it about half an hour, and find out that it was indeed loading order issue, but, not in a runtime issue, was compile time’s.

Since the problematic one, with-current-notmuch-show-message, is actually a macro, think it should be available at build time, that is, compile time, as well as at the execution time.

So, at least for my environment, ensuring to load notmuch-show at the compilation process for org-msg, it seems like works as expected.

HyunggyuJang commented 3 years ago

Hi @jeremy-compostella,

Even with the proper setting, some mails cause troubles:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("/" nil 0)
  split-string(nil "/")
  gnus-article-browse-html-parts((#<buffer  *mm*-278607> ("text/plain" (format . "flowed") (charset . "UTF-8")) 8bit nil ("inline") nil nil nil) "From: kou-ryu@adm.nagoya-u.ac.jp\nSubject: =?UTF-8?...")
  org-msg-save-article-for-reply-gnus((#<buffer  *mm*-278607> ("text/plain" (format . "flowed") (charset . "UTF-8")) 8bit nil ("inline") nil nil nil) "From: kou-ryu@adm.nagoya-u.ac.jp\nSubject: =?UTF-8?...")
  org-msg-save-article-for-reply-notmuch()
  apply(org-msg-save-article-for-reply-notmuch nil)
  org-msg-mua-call(save-article-for-reply)
  #f(compiled-function (&rest args) "Transform the current `message' buffer into a OrgMsg buffer.\nIf the current `message' buffer is a reply, the\n`org-msg-separator' string is inserted at the end of the editing\narea. If the current buffer contains MML tags,\n`org-msg-edit-mode' is not activated as OrgMsg does not support\nMML tags." #<bytecode 0x4bb00f73>)("id:4283f95f9634d4e6a3a614670048e22c@adm.nagoya-u.a..." nil nil)
  apply(#f(compiled-function (&rest args) "Transform the current `message' buffer into a OrgMsg buffer.\nIf the current `message' buffer is a reply, the\n`org-msg-separator' string is inserted at the end of the editing\narea. If the current buffer contains MML tags,\n`org-msg-edit-mode' is not activated as OrgMsg does not support\nMML tags." #<bytecode 0x4bb00f73>) ("id:4283f95f9634d4e6a3a614670048e22c@adm.nagoya-u.a..." nil nil))
  org-msg-post-setup("id:4283f95f9634d4e6a3a614670048e22c@adm.nagoya-u.a..." nil nil)
  apply(org-msg-post-setup ("id:4283f95f9634d4e6a3a614670048e22c@adm.nagoya-u.a..." nil nil))
  notmuch-mua-reply("id:4283f95f9634d4e6a3a614670048e22c@adm.nagoya-u.a..." nil nil)
  notmuch-mua-new-reply("id:4283f95f9634d4e6a3a614670048e22c@adm.nagoya-u.a..." nil nil)
  notmuch-show-reply-sender(nil)
  funcall-interactively(notmuch-show-reply-sender nil)
  call-interactively(notmuch-show-reply-sender nil nil)
  command-execute(notmuch-show-reply-sender)

For the most mails seem to work fine, but the ones from my college pose such an error. The culprit of it might belong to college side, not the gnus or yours, but anyhow, I’d better turn off your new feature for the ones from my university.

Regards,

– Hyunggyu Jang

jeremy-compostella commented 3 years ago

@HyunggyuJang and @whudwl

Thanks, I understand what the issue is now: Since with-current-notmuch-show-message is a macro and it is undefined at the time org-msg is compiled, it is assumed to be a function which explain the crash at runtime. I think this is an issue that we should address other configuration could hit this issue. We cannot ad any (require 'notmuch) at the root as the point of this module is to work dynamically with different backends without making the end-user installing all the different backends.

I think that the best option is to replace with-current-notmuch-show-message with a function. Obviously we do not want to duplicate code from notmuch as it would eventually lead to a maintenance nightmare. I found the notmuch-show-view-raw-message function which seem to be doing something very similar and I made a patch (see 7c235d5) on the experimental branch. As you know I don't use notmuch so I can't test. Could you give it a shot and make some adjustment if needed ?

jeremy-compostella commented 3 years ago

@HyunggyuJang,

Regarding your university email does it contains an html part ? If it does and does not contain any confidential information could you export the original article content into a file and send it to me by email ? Running (org-msg-with-original-notmuch-message (write-file "/tmp/failing.mail")) from the reply buffer should do it. Compress it and share the compressed file. This is an extra safety measure to make sure no mailer (your or mine) is going to touch it.

HyunggyuJang commented 3 years ago

@jeremy-compostella

At a glimpse, it has solved the load order issue! Thanks for investing your time to support notmuch! I’ll look into why some mails crashes gnus article related function in my free time.

HyunggyuJang commented 3 years ago

@HyunggyuJang,

Regarding your university email does it contains an html part ? If it does and does not contain any confidential information could you export the original article content into a file and send it to me by email ? Running (org-msg-with-original-notmuch-message (write-file "/tmp/failing.mail")) from the reply buffer should do it. Compress it and share the compressed file. This is an extra safety measure to make sure no mailer (your or mine) is going to touch it.

Thanks for your sincere supporting! I’ll do as you suggested!

HyunggyuJang commented 3 years ago

@jeremy-compostella

I’ve sent failing mail to your email address. It wasn’t involved html part, after all.

Best regards,

– Hyunggyu Jang

HyunggyuJang commented 3 years ago

Can confirm that such errors occur whenever the mail doesn’t have multiple part as mail format.

What I’ve checked as problematic type:

Text only
Html only
Text with attachment

On the other hand, those with multiple part containing both html and text parts always success.

jeremy-compostella commented 3 years ago

Are you sure you have org-msg loaded properly? (org-msg-article-htmlp) evaluates as nil, (org-msg-article-htmlp) is called by org-msg-article-htmlp-notmuch and it should have prevented the export of the html content as there is no html part to export.

HyunggyuJang commented 3 years ago

Don’t know why, but seems like even after setting org-msg-posting-style to nil, malfunction persists. Somehow such an error message has gone, but in those problematic mail types, Org Msg doesn’t get set properly. It left the major mode as Message[Notmuch] mode, not org-msg-edit-mode.

This kind of glitch don’t appear in the OK types.

Furthermore, this fallacious behavior isn’t observed if I revert the commit to the previous one, before the ones introduced in this thread.

More specifically here some examples for the successful ones:

If I trigger reply command to it, I get

Now comes the minimal failure example:

with this buffer, if I try to reply, I get

Due to this unexpected behavior, I reverted back to https://github.com/jeremy-compostella/org-msg/commit/b0765b2d0bc06cdd1fd78836ef958eb81e603dd1, and it seems to work fine.

HyunggyuJang commented 3 years ago

@jeremy-compostella
Sorry about littering this space. I examined the source code closely, and it is indeed intended behavior? The whole org-msg-post-setup command wrapped by when so that when it comes to reply-to-text type, do not trigger org-msg-edit-mode. If that so, what I conceived as malfunction is from the fact that, so far, I accustomed to always on org-msg-edit-mode since its type always has been reply-to-html.

It makes sense to not activate org-msg-edit-mode for non html type messages, since it doesn’t do anything for those plain text exports.

Saying this, I think your new commit in experimental branch works seamlessly to me, also.

whudwl commented 3 years ago

org-msg is supposed to determine if it's replying to a html message or text message. So what @HyunggyuJang ponted out is probably indeed a problem. I have tried replying to some text emails, I also got various issues. But different issues though. Will do more testing later and report back.

whudwl commented 3 years ago

Now I'm getting Invalid function: with-current-notmuch-show-message error...

jonathanwilner commented 3 years ago

Hi all,

This current version in the experimental branch appears to erase the forwarded email again & leave just the HTML signature. Previous versions appeared to work beautifully to forward HTML email.

This could be just me & my config. Please ignore if it's working well for @whudwl or others.

Thanks!

jeremy-compostella / org-msg

everything below --citation follows this line (read-only)-- erased #73