Tag: Lisp

How to reintegrate changes for Word back into Org-Mode

Via: 

From:   Ken Mankoff
Subject:  Re: [O] Organizing and taming hectic Academia work (faculty   viewpoint)? Tips or a good guides sought after :)
Date:   Fri, 12 Jun 2015 10:02:50 -0400
Hi Julian,
On 2015-06-10 at 10:16, Julian Burgos <address@hidden> wrote:
> a) I first write in org-mode. Export to Word, either exporting first
> to ODT and then to Word, or to LaTex and then use pandoc to convert
> LaTex to Word. My coauthor can edit the document as he wishes, using
> the "Track changes" option. Then, I transcribe their edits back into
> the org-mode document. Advantage of this approach: your coauthor
> receives a clean word file, that could include figures, references,
> etc., and he/she uses the tools she likes to edit the file.
> Disadvantage: you have to manually incorporate the changes to the
> org-mode file each time there are edits.
>
> b) I write the manuscript in org-mode. Then I send the org-mode file
> to my coauthor. Because the org-mode file is just a text file, my
> coauthor can use Word to edit it. I ask him/her *not* to use "track
> changes" and to save the edited version also as a text file. Then,
> when I receive it I use ediff in emacs to compare both documents and
> incorporate the edits I want. Advantage of this approach: the merging
> of the documents is easy using ediff. Disadvantage: your coauthor has
> to edit a weird-looking document, with markup, code blocks, etc.
It seems like with a bit of extra (scriptable?) work you could remove both
disadvantages.
Why can't you use method (a) above, and then DOCX -> Org via pandoc (with
--accept-all option)?
I know pandoc introduce some of its own changes to the Org syntax but not the
document itself. You can get around this. You can remove the pandoc-generated
changes automagically so that only co-author changes appear in Org format,
which you can then use with your (b) above and emacs ediff.
Original: Your Org source
A: Org -> DOCX for co-authors (using pandoc)
B: Org -> DOCX -> Org (using pandoc).
C: A -> Org (using pandoc and --accept-all-changes)
D: B-Original
The difference between B and Original are pandoc-introduced changes that you do
not want. Ignore/remove these changes from C, call it D and then the difference
between D and the Original are your co-author comments. Now your authors can
edit DOCX with Track Changes and you can work on those edits with Emacs ediff.
  -k.

Uniquely Name Source-Blocks and Headline IDs in Org-Mode

Always name all of your Source-Blocks and uniquely ID Headlines in Org-Mode. It is the only way to make Literate Programming pleasant and predictable. At the very least you will understand what is happening during tangling.

Org-Mode Release 8.3

Org 8.3 is now out.

Addendum: 2015-08-16
Interesting:

  • org-show-context-detail
  • Markdown export supports switches in source blocks
  • ASCII export additions
  • Export inline source blocks
  • ascii plot
  • date macro parms
  • mathjax cdn
  • viewport for html mobile
  • remotely edit footnote definition
  • texinfo image support
  • Removed option org-koma-letter-use-title
  • Three slash URI links
  • Footnotes in included files are now local to the file
  • When exporting, throw an error on unresolved id/fuzzy links and code refs

Easily Go To and Return From Headlines in Org-Mode

Quit using goto-line and isearch to navigate in your Org-Mode document. I didn’t want to use Helm or Imenu to do it and Org-Mode has a built in solution with org-goto. Be sure to bind the “pop” key very close-by to make it symmetrical and fast.
(define-key org-mode-map (kbd "s-u") #'org-goto)
(define-key org-mode-map (kbd "s-U") #'org-mark-ring-goto)

Handling 4 Kinds of Return in Org Mode

You might want more than a few ways to “return” when inside of Org; I did.

  • org-return-indent: Make it really easy to work in existing list items, headings, and tables
    • This is listed first because I often go back to modify entries
    • <return> because it is used the most
  • org-meta-return: Make it really easy to add new list items, headings, and table contents
    • M-<return> because the binding comes with Org
  • electric-indent-just-newline: For when I want to break out of the default Org indentation to start working at the beginning of the line for example when I’m done working in a list or have just created a new heading
    • C-M-<return> because it is next step “lower” in the binding

  • This: When I want to insert a new line between the current and next line then position the cursor correctly indented at the start of it. 

    (defun help/smart-open-line ()
  "Insert a new line, indent it, and move the cursor there.

This behavior is different then the typical function bound to return which may be `open-line' or `newline-and-indent'. When you call with the cursor between ^ and $, the contents of the line to the right of it will be moved to the newly inserted line. This function will not do that. The current line is left alone, a new line is inserted, indented, and the cursor is moved there.

Attribution: URL `http://emacsredux.com/blog/2013/03/26/smarter-open-line/'"
  (interactive)
  (move-end-of-line nil)
  (newline-and-indent))
    • s-<return because it is that is the last place in the modifier key chain

You Probably Want org-return-indent Bound to Return

Started questioning why after hitting RETURN while in lists I have to hit TAB to get indented properly. Kind of a dead giveaway that I should be return-and-indenting! Looked at org-return to find that it has an argument about indenting and then saw that org-return-indent passes it for you. With that in mind, RETURN is bound to that now.

You probably want org-return-indent bound to return. It saves a lot of actions.