From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [ANN] Edit emails in Org-mode Date: Fri, 21 Jun 2013 13:44:42 +0200 Message-ID: <87txkradsl.fsf@gmail.com> References: <8738sedkk4.fsf@gmail.com> <86ip19dzwh.fsf@somewhere.org> <8761x90z4o.fsf@gmail.com> <861u7w6i5i.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upzlx-0007Yp-0r for emacs-orgmode@gnu.org; Fri, 21 Jun 2013 07:44:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Upzlv-0004JK-2u for emacs-orgmode@gnu.org; Fri, 21 Jun 2013 07:44:56 -0400 Received: from plane.gmane.org ([80.91.229.3]:51708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upzlu-0004J8-PL for emacs-orgmode@gnu.org; Fri, 21 Jun 2013 07:44:55 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Upzlt-0000iL-EB for emacs-orgmode@gnu.org; Fri, 21 Jun 2013 13:44:53 +0200 Received: from e178058009.adsl.alicedsl.de ([85.178.58.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jun 2013 13:44:53 +0200 Received: from tjolitz by e178058009.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jun 2013 13:44:53 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org "Sebastien Vauban" writes: Hi Sebastien, > Thorsten Jolitz wrote: >> "Sebastien Vauban" >> writes: >>> Thorsten Jolitz wrote: >>>> 2.3 Usage >>>> ~~~~~~~~~ >>>> >>>> There are only two commands involved: >>>> >>>> Command Keybinding Comment >>>> ----------------------------------------------------------------------- >>>> M-x outorg-edit-as-org M-# M-# or M-# # outline-prefix M-# >>>> C-c ' outline-prefix C-c >>>> M-x outorg-copy-edits-and-exit M-# --- >>> >>> When I have "message" code blocks, and when I edit them in an >>> indirect buffer (for refilling them, for example), then I have a >>> draft message that stays in my Gnus/Message emails. >>> >>> Any idea how to get rid of that? >> >> its a nice idea to be able to replace the source-blocks by their >> results when composing messages (if I understood your feature request >> right). > > No, this may be a good idea, but not what I was talking about. anyway, I really like it for myself ... > I now have the following capture command: > > #+begin_src emacs-lisp > (add-to-list 'org-capture-templates > `("m" "Mail to task" entry > (file+headline ,org-default-notes-file "Tasks") > "* TODO %:subject%? (from %:fromname) :mail: > %:date-timestamp-inactive > > #+begin_src message > %i > #+end_src > > From %a" > :immediate-finish t) t) > #+end_src > > But, sometimes, I want to refill the contents of the captured email. > > To do so, I go onto the email message code block, edit it in an indirect > buffer (through C-c '), refill, and quit the indirect buffer (another C-c '). > > Though, after having done that, I now have the above email saved as a draft in > Gnus. Not what I was expecting. > > So, my question was: how to avoid the email to be saved as a draft? Thats quite a complicated set-up, not sure if I really can say something about that. Maybe you noticed, that in my original post I exported my mail written in the *outorg-edit-buffer* to ASCII with this code block: #+begin_src emacs-lisp :results output replace (org-export-to-buffer 'ascii "email-transcode-buffer") (print (with-current-buffer "email-transcode-buffer" (let ((mail-as-ascii (buffer-substring-no-properties (point-min) (point-max)))) (set-buffer-modified-p nil) (kill-buffer) mail-as-ascii))) #+end_src and the result looked like this (I did not fiddle with the export options, just used the settings I have): #+results: ,---------------------------------------------- | " _________________ | | 134 | | Thorsten Jolitz | _________________ | | | Table of Contents | _________________ | | 1 --text follows this line-- | 2 Documentation `---------------------------------------------- I think this 134 in the headline comes from Gnus too, and is a draft number or so. I'm not really sure whats happening there, it seems to be something between Org and Gnus. I do use C-c ' in the *outorg-edit-buffer* too for editing source-blocks, not sure if Org-mode automatically saves the original buffer when returning from the temporal (source-code) edit buffer and updating the original buffer - but that would then be the *outorg-edit-buffer*, not the message-buffer. I checked outorg.el - there is only one explicit use of 'save-buffer' not related to this, so I don't seem to save the original-buffer when returning from *outorg-edit-buffer* buffer (and I remember that I decided to better leave that to the user). >> Opens a lot of possiblilities for (semi-)automatic email creation. >> >> Here is the doc-string: >> >> #+begin_src emacs-lisp >> (defun outorg-replace-source-blocks-with-results >> (&optional arg &rest languages) >> "Replace source-blocks with their results. >> >> Only source-blocks with ':export results' in their header >> arguments will be mapped. >> >> If LANGUAGES is non-nil, only those source-blocks with a >> language found in the list are mapped. >> >> If LANGUAGES is nil but a prefix-argument ARG is given, only the >> languages read from the mini-buffer (separated by blanks) are mapped. >> >> Otherwise, all languages found in `org-babel-load-languages' are mapped." ...) >> #+end_src >> >> it basically says: >> >> - only blocks with ':export results' will be mapped >> >> - blocks for all languages found in `org-babel-load-languages' will be mapped, >> except the function ist called (from a program) with a list of language >> names (as strings) or the user calls the command with prefix arg (e.g. C-u) >> and enters language names (like this: R emacs-lisp sh org). >> >> let me know if the function does what you wanted. >> >> Do we need a keybinding for that, or should it rather be a bit oscure (only >> accessible by M-x) to avoid confusing accidents? > > Best regards, > Seb -- cheers, Thorsten