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

jonathanwilner · 2020-09-30T23:39:23Z

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 · 2020-10-01T00:24:27Z

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 · 2020-10-01T14:03:14Z

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 · 2020-12-22T01:50:00Z

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 · 2021-05-04T09:15:50Z

@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 · 2021-05-04T09:40:52Z

@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 · 2021-05-04T15:17:31Z

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

jeremy-compostella · 2021-05-04T17:38:48Z

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

whudwl · 2021-05-05T04:55:42Z

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 · 2021-05-06T00:32:42Z

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 · 2021-05-06T00:57:19Z

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 · 2021-05-06T02:03:51Z

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 <img> 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> .

whudwl · 2021-05-06T02:58:35Z

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 · 2021-05-06T03:53:27Z

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

whudwl · 2021-05-06T05:26:49Z

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 · 2021-05-06T05:51:48Z

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 · 2021-05-06T06:46:35Z

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 · 2021-05-06T16:25:23Z

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)))))))

This patch addresses #73. Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>

jeremy-compostella · 2021-05-06T18:31:32Z

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 · 2021-05-06T22:28:42Z

@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 · 2021-05-06T22:30:21Z

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

whudwl · 2021-05-06T22:34:15Z

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 · 2021-05-06T22:56:03Z

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 · 2021-05-06T23:02:37Z

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.

This patch addresses #73. Signed-off-by: Dave Dai <whudwl@gmail.com> Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>

jeremy-compostella · 2021-05-06T23:38:11Z

@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.

This patch addresses #73. Signed-off-by: Dave Dai <whudwl@gmail.com> Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>

HyunggyuJang · 2021-05-12T04:22:50Z

@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 · 2021-05-12T04:54:56Z

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 · 2021-05-12T05:37:23Z

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

jonathanwilner · 2021-05-12T15:38:06Z

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 · 2021-05-12T16:14:06Z

@HyunggyuJang, indeed if you do not have specified the list of alternative for reply to text, OrgMsg does not enable itself (as described in the documentation). Disabling itself for text message has always been the default behavior of OrgMsg since the very beginning and except for the notmuch backend which was very poorly written.

Patch b26aa6c put the notmuch backend to the same level. I suggest that you define org-msg-default-alternatives appropriately for your use-case. See my configuration example in the README.org.

jeremy-compostella · 2021-05-12T16:14:35Z

@jonathanwilner and @whudwl I would appreciate if a notmuch user could try to debug the experimental branch.

jeremy-compostella · 2021-05-12T16:15:22Z

@whudwl any update on your testing with regard to respond to various email type (text, html, mixed) ?

HyunggyuJang · 2021-05-12T22:31:09Z

@jeremy-compostella Seems like my configuration for Org Msg is somewhat obsolete, haven’t tracked the changes breaking backward compatibility so far.
Specifically mine follows the version before the commit, d670f91, and I glimpsed that the clause before treating ’reply-to-text specially, there was general one, but haven’t reach to the point that I have to update, or inspect change logs. Think setting it properly as you did in README.org would perfectly fit to my use-case.

jeremy-compostella · 2021-05-12T23:49:53Z

@HyunggyuJang

Seems like my configuration for Org Msg is somewhat obsolete, haven’t tracked the changes breaking backward compatibility so far.

There should not be any backward compatibility issue except as I said with the notmuch backend as it was poorly implemented originally and was not behaving as it should have.

Think setting it properly as you did in README.org would perfectly fit to my use-case.

Does it work ? Do you still faces a crash on reply to text only emails ?

HyunggyuJang · 2021-05-13T00:22:20Z

@jeremy-compostella Sorry for misleading. Was due to my short understanding. Seems like there’s no issue about backward compatibility. What I conceived as a discrepancy was the change made to default alternative format setting, but it appears also well maintained to support previous ones. As I’m away from environment now, I’ll test it as soon as I get there. Regards, — Hyunggyu Jang

…

On May 13, 2021, at 8:50 AM, Jérémy Compostella ***@***.***> wrote: Seems like my configuration for Org Msg is somewhat obsolete, haven’t tracked the changes breaking backward compatibility so far. There should not be any backward compatibility issue except as I said with the notmuch backend as it was poorly implemented originally. Think setting it properly as you did in README.org would perfectly fit to my use-case. Does it work ? Do you still faces a crash on reply to text only emails ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

HyunggyuJang · 2021-05-13T01:56:37Z

@jeremy-compostella

Can confirm now it works also for text only messages.

However, the signature part comes after the text citation, is it intended? To me it betrays what the top-posting style describes. On top of that, when it comes to reply to html mail, it only crawls the target mail, to which replying command issued, not the full thread, as a read only citation. Since I have no expertise about mail things, don’t know whether it is along the line or not.

Furthermore, what I’ve delineated at this comment, was from html only message, not the text only format, still exists.

I’ll send the problematic mail to your email address. Note that if [ text/html ] part nested within [ multipart/mixed ] then, it doesn’t arouse any issue.

Thanks for your hard work.

whudwl · 2021-05-13T08:44:47Z

@jeremy-compostella

Got an (wrong-type-argument stringp nil) error when trying to reply to an email. Not sure if it's related to this thread though.
It's an auto generated, notification type of email, very simple.
Trace here:
trace.txt

And for another email I replied to, the subject in the quoted section got doubled up a dozen times. For example, the subject of the mail I replied to is "urgent issue", though the subject of my reply is OK, but below my reply, in the citation section, the subject became "urgent issue urgent issue urgent issue.....". Just FYI, could be off topic.

For most emails, it works pretty well though. I thought all the heavy lifting is done by gnus engine which is supposed to be mature, so a bit surprised.

whudwl · 2021-05-13T10:27:46Z

@jeremy-compostella It seems, for this super simple email I was trying to reply to, it had only 1 part (not sure this is how to describe it?). mm-dissect-buffer returns:
( *mm*-581355 (text/html (charset . UTF-8)) 7bit nil nil nil nil nil)

which needs to be enclosed in a list. so inside org-msg-save-article-for-reply-gnus, it should probably be like this?

(gnus-article-browse-html-parts (list parts) header)

jeremy-compostella · 2021-05-13T16:01:28Z

@whudwl, good catch! Indeed, the gnus-article-browse-html-article takes care of this so we should also take care of this. I have pushed a patch on the experiment branch for you and @HyunggyuJang to test.

I removed 7c235d5 from the experimental branch but would appreciate if someone could look into it. It would be better to get rid of the use of a macro.

jonathanwilner · 2021-05-13T16:12:34Z

Hi @jeremy-compostella - this continues to generally work well for me, except for forwarding HTML email. I've got to turn off org-msg before a forward now, or I just get the signature, but not the forwarded message in the multi-part message.

jeremy-compostella · 2021-05-13T20:37:37Z

@HyunggyuJang

However, the signature part comes after the text citation, is it intended? To me it betrays what the top-posting style describes.

It does not betray anything. The posting-style only applied to HTML emails.

(defcustom org-msg-posting-style 'top-posting
  "Define the posting style for HTML replies.
Can be either `top-posting' or nil."
  :type '(symbol))

Or from the README.org

OrgMsg composes reply to HTML emails in top-posting style. This behavior can be disabled by setting org-msg-posting-style to any value other than top-posting.

On top of that, when it comes to reply to html mail, it only crawls the target mail, to which replying command issued, not the full thread, as a read only citation. Since I have no expertise about mail things, don’t know whether it is along the line or not.

Could you provide more details? (I feel like you are expecting to much from what OrgMsg can do).

jeremy-compostella · 2021-05-13T20:38:43Z

@jonathanwilner

Hi @jeremy-compostella - this continues to generally work well for me, except for forwarding HTML email. I've got to turn off org-msg before a forward now, or I just get the signature, but not the forwarded message in the multi-part message.

Since which commit does forwarding does not work for you anymore ?

jeremy-compostella · 2021-05-14T18:40:27Z

@whudwl, could you validate 18a4620 which basically implement your suggestion? I would like to push it to master ASAP as the issue it fixes an issue which should be highly visible to notmuch users.

jeremy-compostella · 2021-05-14T21:07:08Z

@whudwl I found a way to validate and pushed to master. I also found a bug when forwarding an html email which is not a multipart. I pushed the fix to master too.

jeremy-compostella · 2021-05-14T21:19:37Z

@HyunggyuJang I tested 0418fa1 which remove the use of `with-current-notmuch-show-message' and it works like a charm on a clean Emacs.

jonathanwilner · 2021-05-14T23:42:47Z

Hi @jeremy-compostella - it seems (at least for me) that I'm getting the "Select All" effect again from the most recent master.

Re: forwarding HTML - I can forward cleanly a message with no plaintext. If it has HTML and Plaintext, the forward now includes the From, To, Subject and Date, but then "---End of Forwarded Message---"

HyunggyuJang · 2021-05-15T23:21:52Z

@jeremy-compostella
Thanks for your detailed advice! I’ll look into relevant source code, or protocol related to top posting style. I’d better study these concepts before leaving comments.

Glad to know that you found the way to test notmuch related stuff. At a glimpse, your new commits works smoothly in my setting.

Thanks for your enthusiasm and endeavor!

jeremy-compostella · 2021-05-17T18:01:49Z

@HyunggyuJang, including the experimental branch ?

HyunggyuJang · 2021-05-17T23:10:56Z

@jeremy-compostella Yeah, without experimental branch, macro related things keep buzzing. At least to me, experimental branch is good to be merged to mainstream. Regards, — Hyunggyu Jang

…

On May 18, 2021, at 3:02 AM, Jérémy Compostella ***@***.***> wrote: @HyunggyuJang, including the experimental branch ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

joshuaoco · 2021-07-30T09:44:41Z

Aha, I will be the annoying person who was relying on a bug :)

I use notmuch and I've only just updated and noticed that my HTML replies now include the citation.

This is actually not what I want, and I preferred not including the citation in my reply.

Is there any configuration to stop this?
Thanks

jeremy-compostella · 2021-08-31T02:06:07Z

I believe so, have a look at the documentation (README.org). If you set org-msg-posting-style to nil, then the citation is not going to be included in your HTML replies.

joshuaoco · 2021-08-31T05:54:00Z

Hi, Thanks for that, that's /almost/ perfect, however it still does include a copy of the text (thankfully editable however) above my message. I can just delete it each time (or define a function to do so), but before I do, is there any way around that? Cheers! Joshua

jeremy-compostella · 2021-09-01T16:34:44Z

This second part of the issue has nothing to do with org-msg. This is the responsibility of the Mail User Agent to pass (or not) the citation the the mail composer. For instance, with gnus, I call call either gnus-summary-reply or gnus-summary-reply-with-original to decide if I want the original message in my reply buffer. I don't which MUA you are using but you should look into the options it offers.

jeremy-compostella closed this as completed Apr 27, 2021

jeremy-compostella reopened this May 4, 2021

jeremy-compostella added a commit that referenced this issue May 6, 2021

notmuch: Support `save-article-for-reply' callback

317a59b

This patch addresses #73. Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>

jeremy-compostella added a commit that referenced this issue May 6, 2021

notmuch: Support the `save-article-for-reply' callback

6116818

This patch addresses #73. Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>

jeremy-compostella added a commit that referenced this issue May 6, 2021

notmuch: Support the `save-article-for-reply' callback

066ea3f

This patch addresses #73. Signed-off-by: Dave Dai <whudwl@gmail.com> Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>

jeremy-compostella added a commit that referenced this issue May 7, 2021

notmuch: Support the `save-article-for-reply' callback

49331fe

This patch addresses #73. Signed-off-by: Dave Dai <whudwl@gmail.com> Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>

rjhwelsh mentioned this issue Jul 2, 2021

Forwarded mail citation only includes html #120

Open

cnoceda mentioned this issue Jul 18, 2024

Tab does not auto-complete emails in the To: field #166

Open

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

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

Comments

jonathanwilner commented Sep 30, 2020

TimQuelch commented Oct 1, 2020

jonathanwilner commented Oct 1, 2020 • edited Loading

jeremy-compostella commented Dec 22, 2020

whudwl commented May 4, 2021

whudwl commented May 4, 2021

jonathanwilner commented May 4, 2021

jeremy-compostella commented May 4, 2021

whudwl commented May 5, 2021 • edited Loading

jeremy-compostella commented May 6, 2021 • edited Loading

whudwl commented May 6, 2021

jeremy-compostella commented May 6, 2021 via email

whudwl commented May 6, 2021

jeremy-compostella commented May 6, 2021 via email • edited Loading

whudwl commented May 6, 2021

whudwl commented May 6, 2021 • edited Loading

whudwl commented May 6, 2021

jeremy-compostella commented May 6, 2021

jeremy-compostella commented May 6, 2021

whudwl commented May 6, 2021

jonathanwilner commented May 6, 2021

whudwl commented May 6, 2021

jonathanwilner commented May 6, 2021

whudwl commented May 6, 2021 via email

jeremy-compostella commented May 6, 2021 • edited Loading

HyunggyuJang commented May 12, 2021 • edited Loading

whudwl commented May 12, 2021

whudwl commented May 12, 2021

jonathanwilner commented May 12, 2021

jeremy-compostella commented May 12, 2021

jeremy-compostella commented May 12, 2021 • edited Loading

jeremy-compostella commented May 12, 2021

HyunggyuJang commented May 12, 2021 • edited Loading

jeremy-compostella commented May 12, 2021 • edited Loading

HyunggyuJang commented May 13, 2021 via email

HyunggyuJang commented May 13, 2021 • edited Loading

whudwl commented May 13, 2021

whudwl commented May 13, 2021 • edited Loading

jeremy-compostella commented May 13, 2021

jonathanwilner commented May 13, 2021

jeremy-compostella commented May 13, 2021

jeremy-compostella commented May 13, 2021

jeremy-compostella commented May 14, 2021

jeremy-compostella commented May 14, 2021

jeremy-compostella commented May 14, 2021

jonathanwilner commented May 14, 2021

HyunggyuJang commented May 15, 2021

jeremy-compostella commented May 17, 2021

HyunggyuJang commented May 17, 2021 via email

joshuaoco commented Jul 30, 2021

jeremy-compostella commented Aug 31, 2021

joshuaoco commented Aug 31, 2021 via email

jeremy-compostella commented Sep 1, 2021

jonathanwilner commented Oct 1, 2020 •

edited

Loading

whudwl commented May 5, 2021 •

edited

Loading

jeremy-compostella commented May 6, 2021 •

edited

Loading

jeremy-compostella commented May 6, 2021 via email •

edited

Loading

whudwl commented May 6, 2021 •

edited

Loading

jeremy-compostella commented May 6, 2021 •

edited

Loading

HyunggyuJang commented May 12, 2021 •

edited

Loading

jeremy-compostella commented May 12, 2021 •

edited

Loading

HyunggyuJang commented May 12, 2021 •

edited

Loading

jeremy-compostella commented May 12, 2021 •

edited

Loading

HyunggyuJang commented May 13, 2021 •

edited

Loading

whudwl commented May 13, 2021 •

edited

Loading