Re: [O] [PATCH] ob-ruby.el fix for :session parameter
Achim Gratz writes: > Oleh writes: >> #+RESULTS: >> : >> : 3 > > Well, that would still be an empty line too many. But aside from that, > what I'm actually getting with a recent Emacs and inf-ruby is: > > #+RESULTS: > : > : irb(main):003:0> irb(main):004:0> irb(main):005:0> 3 > > So either comint-mode has developed some problem in the meantime or > there is some other configuration missing for this to work. I've worked around the strange comint behaviour by temporarily disabling all prompts. The empty line was triggered by an extra comint-send-input which I removed (and changed the test to follow suit). There's probably more such problems for other Babel languages that rely on comint for their session support. Both changes done on master in 4ef78e68c1. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Roman numerals in ordered lists
Hi Vikas,
Vikas Rawal writes:
> How can I use roman numerals in ordered lists in an org document? I
> need them in html and latex exports.
Try this document
#+LATEX_HEADER: \renewcommand{\theenumi}{\Roman{enumi}}
#+HTML_HEAD: ol {list-style-type: upper-roman;}
1. en
2. to
3. tre
There's also `org-export-number-to-roman (n)' so I guess you could
overlay with roman numbers in the buffer as well, if you really
wanted.
—Rasmus
--
This space is left intentionally blank
Re: [O] [patch, ox] #+INCLUDE resolves links
Hi,
Rasmus writes:
> This patch allows INCLUDE to have intuitive links as resolved by
> `org-link'-search'. A couple of examples:
>
> #+INCLUDE: file.org::#custom_id :noheadline :lines "3-"
> #+INCLUDE: file.org::*headline :lines "-10"
>
> :noheading tries to get rid of the first headline, and immediately
> subsequent drawer and property-drawer, if present. :noheading is only
> interpret when a headline argument is present. :lines is interpreted
> relatively, if coupled with a headline link.
>
> I should work for other types of links as well though it could be
> limited to headlines only.
>
> Perhaps it would even make sense to let it take a no-file argument to
> locate things within the same buffer. This would be useful for
> including, say, tables in babel/code-appendices.
Ups, I think the previous patch had a paredit mistake.
The attached patch includes documentation, better error handling and
enforces consistency when using `org-link-search'. I used the patch
this morning and I think it makes INCLUDE more enjoyable to use.
Cheers,
Rasmus
--
It was you, Jezebel, it was you
>From 6925403a72db7216b9deca56acc3f72f6d179f22 Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Sun, 21 Sep 2014 13:35:11 +0200
Subject: [PATCH] ox: Allow file-links with #+INCLUDE-keyword
* org.el (org-edit-special): Handle file-links for INCLUDE.
* ox.el (org-export--prepare-file-contents): Handle links and
add option no-heading.
* ox.el (org-export-expand-include-keyword): Resolve headline
links and add option :only-contents.
* orgguide.texi (Include files): Updated.
* org.texi (Include files): Updated.
---
doc/org.texi | 18
doc/orgguide.texi | 9 ++--
lisp/org.el | 8 ---
lisp/ox.el| 63 +++
4 files changed, 80 insertions(+), 18 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 7d98d51..9414314 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10008,6 +10008,24 @@ to use the obvious defaults.
#+INCLUDE: "~/.emacs" :lines "10-"@r{Include lines from 10 to EOF}
@end example
+Finally, you may use a file-link, see @ref{External links}, to extract an
+object as matched by @code{org-link-search}@footnote{Note that
+@code{org-link-search-must-match-exact-headline} is locally bound to non-nil.
+Therefore, @code{org-link-search} only matches headlines and named
+elements.}. If the keyword @code{:only-contents} is used, only the contents
+of the element in included. For headlines, drawers and properties
+immediately following the headline will not be included when using
+@code{:only-contents}. The @code{:lines} keyword is local to the
+element in question. Some examples:
+
+@example
+#+INCLUDE: "./paper.org::#theory" :only-contents
+ @r{Include the body of the heading with the custom id @code{theory}}
+#+INCLUDE: "./paper.org::mytable" @r{Include tabel with name and caption.}
+#+INCLUDE: "./paper.org::*conclusion" :lines 1-20
+ @r{Include the first 20 lines of the headline named conclusion.}
+@end example
+
@table @kbd
@kindex C-c '
@item C-c '
diff --git a/doc/orgguide.texi b/doc/orgguide.texi
index ca8e052..d3cee0c 100644
--- a/doc/orgguide.texi
+++ b/doc/orgguide.texi
@@ -2264,8 +2264,13 @@ include your @file{.emacs} file, you could use:
The optional second and third parameter are the markup (i.e., @samp{example}
or @samp{src}), and, if the markup is @samp{src}, the language for formatting
the contents. The markup is optional, if it is not given, the text will be
-assumed to be in Org mode format and will be processed normally. @kbd{C-c '}
-will visit the included file.
+assumed to be in Org mode format and will be processed normally. File-links
+will be interpret as well:
+@smallexample
+#+INCLUDE: "./otherfile.org::#my_custom_id" :no-contents
+@end smallexample
+@noindent
+@kbd{C-c '} will visit the included file.
@node Embedded @LaTeX{}, , Include files, Markup
@section Embedded @LaTeX{}
diff --git a/lisp/org.el b/lisp/org.el
index 4ffe1e8..86a1bf9 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20520,9 +20520,11 @@ Otherwise, return a user error."
session params))
(keyword
(if (member (org-element-property :key element) '("INCLUDE" "SETUPFILE"))
- (find-file-other-window
-(org-remove-double-quotes
- (car (org-split-string (org-element-property :value element)
+ (org-open-link-from-string
+ (format "[[%s]]"
+ (expand-file-name
+ (org-remove-double-quotes
+ (car (org-split-string (org-element-property :value element)))
(user-error "No special environment to edit here")))
(table
(if (eq (org-element-property :type element) 'table.el)
diff --git a/lisp/ox.el b/lisp/ox.el
index f01f951..f5b8fcc 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -1,5 +1,4 @@
;;; ox.el --- Generic Export Engine for Org Mode
-
;; Copyright (C) 2012-2014 Free Software Foundation, Inc.
;; Aut
Re: [O] Formal description of Org files
Hi again list. There was a discussion many years back about a formal description of Org files [1]. In some way that might be achieved now in org-elements, but that still is heavily bound to elisp. So my question is; have there been more discussions of constructing such a formal grammar? Maybe in EBNF form. I suspect getting every aspect of Org mode into such a description would be difficult. But imagine the possibilities. Tools such as ANTLR and similar would straight away have a way of parsing Org mode. Org mode source files could be parsed in many other languages, simplifying the process of expanding Org mode to other platforms ( Android & iOS, web ). Further rant; To me Org mode should be less about Emacs and more about the source file format. Let Emacs be the main carrier, but let Org mode also expand into other domains. One way to simplify this might be to provide the formal description so that other tools might be easier to develop based on this grammar. (For me, the biggest limitation of Org mode is lacking tools to utilize it on the run. The aim of this is thus to feed thoughts on how to simplify processes that can expand Org mode into those "more mobile" domains). Best regards Gustav [1] http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01282.html > Hi Jambunathan, > > Jambunathan K writes: > > > A simple worg page that "collects" the low hanging fruits to begin > > with will be a good but firm first step in this direction. > > Indeed. > > It's on my todo list, but not with a high priority for now. > > If you feel like starting it, please go ahead! > > -- > Bastien
Re: [O] Formal description of Org files
Hello, Gustav Wikström writes: > There was a discussion many years back about a formal description of > Org files [1]. In some way that might be achieved now in org-elements, > but that still is heavily bound to elisp. > > So my question is; have there been more discussions of constructing > such a formal grammar? Maybe in EBNF form. I suspect getting every > aspect of Org mode into such a description would be difficult. But > imagine the possibilities. Tools such as ANTLR and similar would > straight away have a way of parsing Org mode. Org mode source files > could be parsed in many other languages, simplifying the process of > expanding Org mode to other platforms ( Android & iOS, web ). > > Further rant; To me Org mode should be less about Emacs and more about > the source file format. Let Emacs be the main carrier, but let Org > mode also expand into other domains. One way to simplify this might be > to provide the formal description so that other tools might be easier > to develop based on this grammar. > > (For me, the biggest limitation of Org mode is lacking tools to > utilize it on the run. The aim of this is thus to feed thoughts on how > to simplify processes that can expand Org mode into those "more > mobile" domains). See (info "(org) Org syntax") Regards, -- Nicolas Goaziou
Re: [O] [patch, ox] Unnumbered headlines
Hello, Rasmus writes: > I'm happy to finally be able to send an updated version of this patch > that touches most backends in lisp/, but not the manual. I have been > moving over the summer etc. Thanks for that work. Some comments follow. > You now specify unnumbered headlines with properties. I think this is > better since being unnumbered it's a pretty permanent state. It's > pretty hard to discover though, other than by looking at the output. > > So this works as expected: > > * Some headline > :PROPERTIES: > :UNNUMBERED: t > :END: > > There's no :NUMBERED property and :UNNUMBERED is hardcoded. Sounds good. > I introduce a new function `org-export-get-headline-id` which returns > the first non-nil from the following list. There's a caveat: > CUSTOM_ID is ensured to be unique! Did I open the famous can of worm? > > 1. The CUSTOM_ID property. > 2. A relative level number if the headline is numbered. > 3. The ID property > 4. A new generated unique ID. I think we should keep separated CUSTOM_ID and ID on the one hand, and internal reference on the other hand. There's no guarantee that CUSTOM_ID will be unique, and, even if you check it out, there's no guarantee either that its value can be used as-is in the generated docstring (think about ":CUSTOM_ID: 100%" in LaTeX export). CUSTOM_ID is a human readable reference to an Org headline. This headline should be referred to internally with a more specific id. To a lesser extent, I think this also applied to org-id. Also `org-export-headline-internal-id' (or some such, to avoid confusion with other IDs) may return a value simpler than what `org-id-new' returns (e.g. a dumb counter). If it is possible, the output will be easier to read. > Anyhow, `org-export-get-headline-id' ensures that we can refer to > unnumbered headlines, which was not possible before. This is untrue. > Of course, in LaTeX such ref to a \section* will be nonsense, so we > could introduce a \pageref here. At the moment, referring to an unnumbered section displays its name. > I'm unsure about whether this conflicts `org-latex-custom-id-as-label' > which I had never seen until today (also notes on this in patch). This variable has its use if custom-id and internal representation are separated. > PS: Not knowing or caring much about md, the links generated by it to > headlines seem wrong. Referring to headline 1 it only prints "1". > Should it be something like "[LABEL](1)"? There is probably something to do here, but that would be in another patch. > * ox-odt.el (org-odt-headline, org-odt-link, > org-odt-link--infer-description): Support unnumbered > headline. > * ox-md.el (org-md-headline, org-md-link): Support > unnumbered headlines. > * ox-latex.el (org-latex-headline, org.latex-link): Support > unnumbered headlines. > * ox-html.el (org-html-headline, org-html-link): Support > unnumbered headlines. > * ox-ascii.el (org-ascii-link): Support ununbered headlines. You can also write "Support unnumbered headlines" just once. > + (when (equal 'headline (org-element-type destination)) Comparing symbols with `equal' is a sin beyond redemption. Use `eq'. > + (format "[%s]" (org-export-data (org-export-get-alt-title > destination info) info) alt title is for table of contents only. > (t >(if (not (org-string-nw-p desc)) (format "[%s]" raw-link) > (concat (format "[%s]" desc) > diff --git a/lisp/ox-html.el b/lisp/ox-html.el > index 1d424cc..94cee20 100644 > --- a/lisp/ox-html.el > +++ b/lisp/ox-html.el > @@ -2321,7 +2321,7 @@ holding contextual information." >(unless (org-element-property :footnote-section-p headline) > (let* ((numberedp (org-export-numbered-headline-p headline info)) > (numbers (org-export-get-headline-number headline info)) > - (section-number (mapconcat #'number-to-string numbers "-")) > + (section-number (when numbers (mapconcat #'number-to-string > numbers "-"))) Nitpick: I suggest `and' instead of `when' since there's no side-effect. > +(when section-number (concat "sec-" > section-number)) Ditto. > + (unless (org-export-get-node-property :UNNUMBERED headline t) Actually, this test is fragile. In the following example * H1 :PROPERTIES: :UNNUMBERED: t :END: ** H2 :PROPERTIES: :UNNUMBERED: nil :END: *** H3 H3 should clearly be unnumbered even though inheritance disagrees. This is a bit stronger than inheritance: if there is a single non-nil UNNUMBERED property among ancestors (or the headline itself), it cannot be numbered. Regards, -- Nicolas Goaziou
Re: [O] resize multiple image within a row or paragraph
Wow. Thanks for your reply. I will stop googling and worg-ing for a solution. I will rather dig into your suggestion. As I understood, there is some hackery involved here .. :) Thanks again. ~Alban Bernard On Saturday, September 20, 2014 2:08 PM, Nicolas Goaziou wrote: Hello, alban bernard writes: > My wife and I use the marvelous org-mode to design a complete set > of student courses. These courses are first written in org-mode then > exported to html to ease distribution to students (and save some paper). > > We wonder what is the correct way to resize multiple images those links > are within a single paragraph: > > "This is a phrase with [[./image1.png]] and [[./image2.png]] inline images." > > With the following, the only first image is resized (as expected): > > #+ATTR_HTML: :width 50% > This is a phrase with [[./image1.png]] and [[./image2.png]] inline images. > > The tutorial about caption in a row shows what is possible while working > only with > images > http://orgmode.org/worg/org-tutorials/images-and-xhtml-export.html#sec-5-2: > > #+HTML_HEAD: > #+HTML_HEAD: > #+HTML_HEAD: > > #+CAPTION: > #+ATTR_HTML: :width 10% > [[./image1.png]] > #+CAPTION: > #+ATTR_HTML: :width 10% > [[./image2.png]] > > Here, image1 and image2 are displayed and resized in a single row. > But we don't know how to mix text within this block so that all is > displayed as a single paragraph with resized images. This is not possible out of the box. You might use some Babel code to generate the needed HTML but I guess it wouldn't be particularly easy. Nevertheless, there's a solution. `html' back-end can redefine what a paragraph is, instead of following Org's own definition. More explicitly, an HTML paragraph can be defined as a cluster of elements not separated by any blank line and containing at least an Org paragraph. Hence: #+attr_html: :width 10% [[./img1.png]] Paragraph #+attr_html: :width 10% [[./img2.png]] consists of two paragraphs in Org, but would be seen as a single paragraph by HTML, and exported as such. Implementation is simple using pseudo-elements. `latex' back-ends does it already for tables and math snippets. However, I'm no HTML specialist, so there may be drawbacks I cannot foresee. Regards, -- Nicolas Goaziou
Re: [O] meaningfull names for org-src buffers
On Thu, Sep 11, 2014 at 5:05 PM, Adriaan Sticker wrote: > I was wondering if it's somehow possible to give named org src buffer the > name they were give in their #+NAME tag? Now there are just called something > like: > *Org Src test.org[ R ]* > > But if you have multiple org-src buffers opened at the same time, its hard > to find the correct one back. Excellent idea. I've got so many small source blocks that it is too difficult to make sense of keeping multiple source block edit buffers open and limit them to one at a time eg , | (setq org-src-window-setup 'current-window) ` How have you come upon your workflow of keeping multiple open and what are some of the pros and cons that you've found with it? -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] [patch, ox] #+INCLUDE resolves links
Hello,
Rasmus writes:
> Rasmus writes:
>
>> This patch allows INCLUDE to have intuitive links as resolved by
>> `org-link'-search'. A couple of examples:
Thanks for the patch. Some comments follow.
>> #+INCLUDE: file.org::#custom_id :noheadline :lines "3-"
Is it `:only-contents' or `:no-headline'? Also ":kwd1 :kbd2 value" is
usually a shortcut for ":kwd1 nil :kbd2 value" (at least in export
attributes). Your example is thus confusing, you should include the
expected value.
#+INCLUDE: "file.org::#custom_id" :only-contents t :lines "3-"
> +elements.}. If the keyword @code{:only-contents} is used, only the contents
> +of the element in included. For headlines, drawers and properties
^^
> +assumed to be in Org mode format and will be processed normally. File-links
> +will be interpret as well:
^
> ;;; ox.el --- Generic Export Engine for Org Mode
> -
> ;; Copyright (C) 2012-2014 Free Software Foundation, Inc.
You can remove this chunk.
> + (only-contents
> + (and (string-match
> +
> ":\\(only-?contents?[[:space:]]*\\(?:'t\\|true\\|yes\\)?\\)" value)
This should be ":only-contents t" or ":only-contents nil".
":only-contents" alone can be tolerated as a shortcut for
":only-contents nil", but that's all.
> +(prog1 t
> + (setq value (replace-match "" nil nil value)
Since `replace-match' cannot return nil here, you can remove
(prog1 t ...)
wrapper. If you insist on ONLY-CONTENTS being t, then
(progn (setq ...) t)
is better.
> + (org-export--prepare-file-contents file location
> only-contents lines
Couldn't location, only-contents and lines be merged into a single
argument? At the moment, you are either short-circuiting or breaking
guard against circular inclusions (which relies on a combination of
file-name and lines).
IOW, each include keyword could be defined as a triplet of file name,
beginning and ending global positions. You could implement a helper
function to translate FILE LOCATION and ONLY-CONTENTS into this triplet,
which would then be passed to `org-export--prepare-file-contents'.
> -(defun org-export--prepare-file-contents (file &optional lines ind minlevel
> id)
> +(defun org-export--prepare-file-contents (file &optional location
> only-contents lines ind minlevel id)
>"Prepare the contents of FILE for inclusion and return them as a string.
>
> +When optional argument LOCATION is a string the matching element
> +identified using `org-link-search' is returned. Note that
> +`org-link-search-must-match-exact-headline' is locally set to
> +non-nil. When ONLY-CONTENTS is non-nil only the contents of the
> +matched element in included. If LOCATION is a headline and
> +ONLY-CONTENTS is non-nil, drawers and property-drawers
> +immediately following the first headline are also removed.
> +
> When optional argument LINES is a string specifying a range of
> lines, include only those lines.
>
> @@ -3420,6 +3437,26 @@ This is useful to avoid conflicts when more than one
> Org file
> with footnotes is included in a document."
>(with-temp-buffer
> (insert-file-contents file)
> +(org-mode)
You cannot enforce `org-mode' as the current major mode since you can
include other file types.
> +(when location
> + (condition-case err
> + ;; enforce consistency in search.
> + (let ((org-link-search-must-match-exact-headline t))
> + (org-link-search location))
> + ;; helpful error messages
> + (error (error (format "%s for %s::%s"
> + (error-message-string err) file location
> + (narrow-to-region
> + (org-element-property
> + (if only-contents :contents-begin :begin) (org-element-at-point))
> + (org-element-property (if only-contents :contents-end :end)
> (org-element-at-point)))
> + ;; get rid of drawers and properties
> + (when only-contents
> + (let ((element (org-element-at-point)))
> + (while (member (org-element-type element) '(drawer property-drawer))
> + (delete-region (org-element-property :begin element)
> +(org-element-property :end element))
> + (setq element (org-element-at-point))
This could be handled when building the triplet. However, please do not
skip drawers (property drawers are fine), as you cannot tell what the
contents are.
> (when lines
>(let* ((lines (split-string lines "-"))
>(lbeg (string-to-number (car lines)))
> @@ -3495,7 +3532,7 @@ with footnotes is included in a document."
> (org-element-normalize-string (buffer-string
>
> (defun org-export-execute-babel-code ()
> - "Execute every Babel code in the visible part of current buffer."
> + "ExecUte every Babel code in the visible part of current buffer."
You can remove this chunk too.
Regards,
--
Nicolas Goaziou
Re: [O] Emacs Lisp Depth
On Tue, Sep 16, 2014 at 8:01 AM, Fabrice Popineau wrote: > Curious to hear about other reports. My primary document has 8051 lines in it so I set max-specpdl-size to 2600 "just in case". That was before I realized that in *my* case, all the bugs were introduced by me into the document itself. It was a good opportunity to learn more about how =org= really works though. -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] State-of-the-art in linking org items to places in source files?
On Wed, Sep 17, 2014 at 2:37 AM, Thorsten Jolitz wrote: > Wasn't there even a library to support this kind of workflow? > I would appreciate any hint that updates me on this topic. Did your research yield any further results? -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] [Feature request] org-babel-tangle-file add an option to tangle if target-file is older than file.
On Thu, Sep 18, 2014 at 5:27 AM, Thorsten Jolitz wrote: > Marcin Antczak writes: > >> As in topic. >> >> I think that if both parameters 'file' and 'target-file' are set and >> target-file' exists, 'org-babel-tangle-file' should tangle only if >> target-file' is older. > > I think the Org based Emacs Starter Kit does this conditional tangling, > you might have a look there > (http://eschulte.github.io/emacs24-starter-kit/) to see how it is done. Martin what did you end up using to obtain your desired functionality? -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] State-of-the-art in linking org items to places in source files?
Grant Rettke writes: > On Wed, Sep 17, 2014 at 2:37 AM, Thorsten Jolitz wrote: >> Wasn't there even a library to support this kind of workflow? >> I would appreciate any hint that updates me on this topic. > > Did your research yield any further results? Not really, but I vaguely remember that somebody on this list had a pretty sophisticated implementation of this idea ... -- cheers, Thorsten
Re: [O] [patch, ox] Unnumbered headlines
Hi,
Thanks for the comments. Let's give it another try, shand't we.
Nicolas Goaziou writes:
>> I introduce a new function `org-export-get-headline-id` which returns
>> the first non-nil from the following list. There's a caveat:
>> CUSTOM_ID is ensured to be unique! Did I open the famous can of worm?
>>
>> 1. The CUSTOM_ID property.
>> 2. A relative level number if the headline is numbered.
>> 3. The ID property
>> 4. A new generated unique ID.
>
> I think we should keep separated CUSTOM_ID and ID on the one hand, and
> internal reference on the other hand.
>
> There's no guarantee that CUSTOM_ID will be unique, and, even if you
> check it out, there's no guarantee either that its value can be used
> as-is in the generated docstring (think about ":CUSTOM_ID: 100%" in
> LaTeX export).
>
> CUSTOM_ID is a human readable reference to an Org headline. This
> headline should be referred to internally with a more specific id. To
> a lesser extent, I think this also applied to org-id.
>
> Also `org-export-headline-internal-id' (or some such, to avoid confusion
> with other IDs) may return a value simpler than what `org-id-new'
> returns (e.g. a dumb counter). If it is possible, the output will be
> easier to read.
Okay, I returned to my first hack (which never made it to this list).
Basically, I ID everything. Unnumbered sections get the id
"unnumbered-sec-COUNTER" and numbered sections get the id
"sec-COUNTER".
Perhaps you will find it too much of a hack.
The other easy alternative, which I find less pleasing, would have on
incremental counter, but it makes it harder to read.
A third alternative is give the numbers like in this patch, but store
the numbers for unnumbered section somewhere else
than :headline-numbering.
>> Anyhow, `org-export-get-headline-id' ensures that we can refer to
>> unnumbered headlines, which was not possible before.
>
> This is untrue.
>
>> Of course, in LaTeX such ref to a \section* will be nonsense, so we
>> could introduce a \pageref here.
>
> At the moment, referring to an unnumbered section displays its name.
In some modes, yes. In LaTeX it produces a \ref{·} that LaTeX will
laugh at.
If you have a better idea than using the title I'm all ears!
>> +(when (equal 'headline (org-element-type destination))
>
> Comparing symbols with `equal' is a sin beyond redemption. Use `eq'.
Shiiit. . .
Why, out of curiosity? I though equal was like the meaner, tougher
eq, that gets shit right, but is a bit more expensive.
>> + (format "[%s]" (org-export-data (org-export-get-alt-title
>> destination info) info)
>
> alt title is for table of contents only.
Yeah, but I though, conditional on using title for ref when nothing
better exists, it would be nicer to have something shorter. Anyway, I
changed it to plain title now.
> Nitpick: I suggest `and' instead of `when' since there's no side-effect.
OK, I think I got 'em all.
>> + (unless (org-export-get-node-property :UNNUMBERED headline t)
>
> Actually, this test is fragile. In the following example
>
> * H1
> :PROPERTIES:
> :UNNUMBERED: t
> :END:
> ** H2
> :PROPERTIES:
> :UNNUMBERED: nil
> :END:
> *** H3
Fixed.
Thanks,
Rasmus
--
Don't panic!!!
Re: [O] [patch, ox] #+INCLUDE resolves links
Hi, A short comment. Nicolas Goaziou writes: >> + (org-export--prepare-file-contents file location >> only-contents lines > > Couldn't location, only-contents and lines be merged into a single > argument? At the moment, you are either short-circuiting or breaking > guard against circular inclusions (which relies on a combination of > file-name and lines). Yeah, you are right. I will look into that. >> @@ -3420,6 +3437,26 @@ This is useful to avoid conflicts when more than one >> Org file >> with footnotes is included in a document." >>(with-temp-buffer >> (insert-file-contents file) >> +(org-mode) > > You cannot enforce `org-mode' as the current major mode since you can > include other file types. But then I can't use org-element-at-point: (with-temp-buffer (text-mode) (insert "* test\nmy txt") (goto-char (point-min)) (org-element-at-point)) (with-temp-buffer (org-mode) (insert "* test\nmy txt") (goto-char (point-min)) (org-element-at-point)) Thanks, Rasmus -- Send from my Emacs
Re: [O] meaningfull names for org-src buffers
Well, I ussually just try to live with this limitation. :) I try to C-c ' in and out src block whenever possible so my my list with buffer names doesnt get to cluttered. Im also thinking about investigating the usefullness of polymode ( https://github.com/vitoshka/polymode) So I dont have to go to a different buffer all the time. Do you have any experience with this? Greetings 2014-09-21 15:49 GMT+02:00 Grant Rettke : > On Thu, Sep 11, 2014 at 5:05 PM, Adriaan Sticker > wrote: > > I was wondering if it's somehow possible to give named org src buffer the > > name they were give in their #+NAME tag? Now there are just called > something > > like: > > *Org Src test.org[ R ]* > > > > But if you have multiple org-src buffers opened at the same time, its > hard > > to find the correct one back. > > Excellent idea. I've got so many small source blocks that it is too > difficult to make sense of > keeping multiple source block edit buffers open and limit them to one > at a time eg > > , > | (setq org-src-window-setup 'current-window) > ` > > How have you come upon your workflow of keeping multiple open and what > are some of the pros and > cons that you've found with it? > > -- > Grant Rettke > g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ > “Wisdom begins in wonder.” --Socrates > ((λ (x) (x x)) (λ (x) (x x))) > “Life has become immeasurably better since I have been forced to stop > taking it seriously.” --Thompson >
Re: [O] meaningfull names for org-src buffers
On Sun, Sep 21, 2014 at 10:07 AM, Adriaan Sticker wrote: > Im also thinking about investigating the usefullness of polymode > (https://github.com/vitoshka/polymode) > So I dont have to go to a different buffer all the time. Do you have any > experience with this? No and it is on my TODO list because you may use it for .Rmd files so it is a must-learn.
Re: [O] resize multiple image within a row or paragraph
Hi,
Here's a simple CSS workaround that might or might not work well for
you, and won't work for non-HTML backends, but at least requires minimal
hacking:
Wrap the sentence in a DIV element and define a class for it to force
child paragraphs to display as inline instead of blocks.
You can set up the style sheets in various ways, but by way of
demonstration, add the style definition with HTML_HEAD export keyword:
#+HTML_HEAD: .inlineparas p {display: inline;}
Then you can do things like this:
#+html:
This is a phrase with
#+ATTR_HTML: :width 50%
[[./image1.png]]
and
#+ATTR_HTML: :width 50%
[[./image2.png]]
inline images.
#+end_inlineparas
#+html:
The generic #+begin_{block} syntax lets you do this in a more org-like
and less cluttered way:
#+begin_inlineparas
This is a phrase with
#+ATTR_HTML: :width 50%
[[./image1.png]]
and
#+ATTR_HTML: :width 50%
[[./image2.png]]
inline images.
#+end_inlineparas
Yours,
Christian
alban bernard writes:
> Wow. Thanks for your reply. I will stop googling and worg-ing for a solution.
> I will rather dig into your suggestion. As I understood, there is some
> hackery involved here .. :)
>
> Thanks again.
>
> ~Alban Bernard
>
>
> On Saturday, September 20, 2014 2:08 PM, Nicolas Goaziou
> wrote:
> Hello,
>
>
> alban bernard writes:
>
>
>> (...)
>> We wonder what is the correct way to resize multiple images those links
>> are within a single paragraph:
>>
>> "This is a phrase with [[./image1.png]] and [[./image2.png]] inline images."
>>
>> With the following, the only first image is resized (as expected):
>>
>> #+ATTR_HTML: :width 50%
>> This is a phrase with [[./image1.png]] and [[./image2.png]] inline images.
>>
>> (...)
>> But we don't know how to mix text within this block so that all is
>> displayed as a single paragraph with resized images.
>
>
> This is not possible out of the box. You might use some Babel code to
> generate the needed HTML but I guess it wouldn't be particularly easy.
>
> Nevertheless, there's a solution. `html' back-end can redefine what
> a paragraph is, instead of following Org's own definition.
> (...)
Re: [O] resize multiple image within a row or paragraph
I will test this workaround pronto. For other backends, that's not a problem as
I render pdf from html through phantomjs and I don't use neither latex nor odt
for the moment.
Big thanks to you both.
~Alban Bernard.
On Sunday, September 21, 2014 8:07 PM, Christian Moe
wrote:
Hi,
Here's a simple CSS workaround that might or might not work well for
you, and won't work for non-HTML backends, but at least requires minimal
hacking:
Wrap the sentence in a DIV element and define a class for it to force
child paragraphs to display as inline instead of blocks.
You can set up the style sheets in various ways, but by way of
demonstration, add the style definition with HTML_HEAD export keyword:
#+HTML_HEAD: .inlineparas p {display: inline;}
Then you can do things like this:
#+html:
This is a phrase with
#+ATTR_HTML: :width 50%
[[./image1.png]]
and
#+ATTR_HTML: :width 50%
[[./image2.png]]
inline images.
#+end_inlineparas
#+html:
The generic #+begin_{block} syntax lets you do this in a more org-like
and less cluttered way:
#+begin_inlineparas
This is a phrase with
#+ATTR_HTML: :width 50%
[[./image1.png]]
and
#+ATTR_HTML: :width 50%
[[./image2.png]]
inline images.
#+end_inlineparas
Yours,
Christian
alban bernard writes:
> Wow. Thanks for your reply. I will stop googling and worg-ing for a solution.
> I will rather dig into your suggestion. As I understood, there is some
> hackery involved here .. :)
>
> Thanks again.
>
> ~Alban Bernard
>
>
> On Saturday, September 20, 2014 2:08 PM, Nicolas Goaziou
> wrote:
> Hello,
>
>
> alban bernard writes:
>
>
>> (...)
>> We wonder what is the correct way to resize multiple images those links
>> are within a single paragraph:
>>
>> "This is a phrase with [[./image1.png]] and [[./image2.png]] inline images."
>>
>> With the following, the only first image is resized (as expected):
>>
>> #+ATTR_HTML: :width 50%
>> This is a phrase with [[./image1.png]] and [[./image2.png]] inline images.
>>
>> (...)
>> But we don't know how to mix text within this block so that all is
>> displayed as a single paragraph with resized images.
>
>
> This is not possible out of the box. You might use some Babel code to
> generate the needed HTML but I guess it wouldn't be particularly easy.
>
> Nevertheless, there's a solution. `html' back-end can redefine what
> a paragraph is, instead of following Org's own definition.
> (...)
Re: [O] [patch, ox] Unnumbered headlines
Rasmus writes:
> Thanks for the comments. Let's give it another try, shand't we.
There we go.
> Okay, I returned to my first hack (which never made it to this list).
> Basically, I ID everything. Unnumbered sections get the id
> "unnumbered-sec-COUNTER" and numbered sections get the id
> "sec-COUNTER".
>
> Perhaps you will find it too much of a hack.
I don't think it is a hack. I am just pointing out that how we refer
internally to headlines has an effect on output clarity. I let you
strike a balance between clarity and easiness of implementation. Note
that the internal reference can be a bit cryptic (e.g. num-1-1 and
nonum-2).
>> At the moment, referring to an unnumbered section displays its name.
>
> In some modes, yes. In LaTeX it produces a \ref{·} that LaTeX will
> laugh at.
This is incorrect.
#+options: num:nil
* Headline
:PROPERTIES:
:CUSTOM_ID: test
:END:
This is a link to [[#test]].
will produce
\section*{Headline}
\label{sec-1}
This is a link to \hyperref[sec-1]{Headline}.
> If you have a better idea than using the title I'm all ears!
On the contrary, using the title is what is usually done. I'm all for
it.
>> Comparing symbols with `equal' is a sin beyond redemption. Use `eq'.
>
> Why, out of curiosity? I though equal was like the meaner, tougher
> eq, that gets shit right, but is a bit more expensive.
This is about using the right tool for the job. Unless you mess with the
obarray, two symbols with the same name are guaranteed to be `eq'.
There's really no reason to use anything else.
Regards,
--
Nicolas Goaziou
Re: [O] [patch, ox] #+INCLUDE resolves links
Rasmus writes: >> You cannot enforce `org-mode' as the current major mode since you can >> include other file types. > > But then I can't use org-element-at-point: > > (with-temp-buffer > (text-mode) (insert "* test\nmy txt") (goto-char (point-min)) > (org-element-at-point)) > > (with-temp-buffer > (org-mode) (insert "* test\nmy txt") (goto-char (point-min)) > (org-element-at-point)) `org-export--prepare-file-contents' is not called with the same number of arguments when it is an Org file. You can activate `org-mode' if you are in this situation (look for (when ind ...) and (when minlevel ...) in the function). Regards, -- Nicolas Goaziou
Re: [O] CV in orgmode for export to pdf (and html?)
Hello, Nicolas Goaziou writes: > Brady Trainor writes: > >> And I did have a decent export to LaTeX resume from org, but after >> discovering moderncv, I've switched, though I will be curious to read >> others' methods of org-to-moderncv export. > > One option could be to define a specialized latex back-end dedicated to > moderncv class, much like "ox-koma-letter.el" does for "scrlttr2". I did actually make a start on this, I'll dig it out and put it somewhere accessible, soon. Myles
Re: [O] [patch, ox] Unnumbered headlines
Hi Nicolas,
Thanks for the comments.
Nicolas Goaziou writes:
>> Okay, I returned to my first hack (which never made it to this list).
>> Basically, I ID everything. Unnumbered sections get the id
>> "unnumbered-sec-COUNTER" and numbered sections get the id
>> "sec-COUNTER".
>>
>> Perhaps you will find it too much of a hack.
>
> I don't think it is a hack. I am just pointing out that how we refer
> internally to headlines has an effect on output clarity. I let you
> strike a balance between clarity and easiness of implementation. Note
> that the internal reference can be a bit cryptic (e.g. num-1-1 and
> nonum-2).
With the last patch it gets weird when you have mixed trees, like this:
* numbered
** unnumbered
:PROPERTIES:
:UNNUMBERED: t
:END:
The LaTeX output is:
\section{numbered}
\label{sec-1}
\subsection*{unnumbered}
\label{unnumbered-sec-0-1}
Perhaps it would be nicer to use a single counter rather than two?
Right now, this
* numbered1
* unnumbered2
:PROPERTIES:
:UNNUMBERED: t
:END:
* numbered2
* unnumbered2
:PROPERTIES:
:UNNUMBERED: t
:END:
produces
\section{numbered1}
\label{sec-1}
\section*{unnumbered2}
\label{unnumbered-sec-1}
\section{numbered2}
\label{sec-2}
\section*{unnumbered2}
\label{unnumbered-sec-2}
But perhaps this is nicer?
\label{sec-1}
\label{unnumbered-sec-2}
\label{sec-3}
\label{unnumbered-sec-4}
In particular for mixed, nested trees.
>>> At the moment, referring to an unnumbered section displays its name.
>>
>> In some modes, yes. In LaTeX it produces a \ref{·} that LaTeX will
>> laugh at.
>
> This is incorrect.
>
> #+options: num:nil
>
> * Headline
> :PROPERTIES:
> :CUSTOM_ID: test
> :END:
> This is a link to [[#test]].
>
> will produce
>
> \section*{Headline}
> \label{sec-1}
> This is a link to \hyperref[sec-1]{Headline}.
Is *my statement* incorrect or is the current *output* incorrect?
On my PC, when I refer to an unnumbered headline I get
\ref{UNNUMBERED}, but since it's after a \section* it will produce
nothing or a subsequent element. But I *did* forget to try the patch
with emacs -q and maybe that's why I'm not seeing \hyperref's. . .
>> If you have a better idea than using the title I'm all ears!
>
> On the contrary, using the title is what is usually done. I'm all for
> it.
To be clear: you are happy if it uses the \hyperref[·]{·} in LaTeX,
but not \ref{·} for unnumbered?
>>> Comparing symbols with `equal' is a sin beyond redemption. Use `eq'.
>>
>> Why, out of curiosity? I though equal was like the meaner, tougher
>> eq, that gets shit right, but is a bit more expensive.
>
> This is about using the right tool for the job. Unless you mess with the
> obarray, two symbols with the same name are guaranteed to be `eq'.
> There's really no reason to use anything else.
OK.
Thanks,
Rasmus
--
And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] filter for src-block export question
To followup on this, I believe there is either a bug or an inconsistency in the export engine with regards to getting the parameters of a src-block. Below, I show why it appears there is a bug. * Bug report for org-mode Here is a named table #+tblname: tbl-data | x | y | |---+---| | 1 | 1 | | 2 | 4 | | 3 | 9 | Here is a named src-block with a defined var #+name: print-table #+BEGIN_SRC python :var data=tbl-data :results value return data #+END_SRC #+RESULTS: print-table | 1 | 1 | | 2 | 4 | | 3 | 9 | Now, we illustrate that the src-block does have :parameters. #+name: get-properties #+BEGIN_SRC emacs-lisp (save-excursion (re-search-backward "#\\+name: print-table") (org-element-property :parameters (org-element-at-point))) #+END_SRC #+RESULTS: get-properties : :var data=tbl-data :results value In the export machinery, though it appears the src-block does not. #+BEGIN_SRC emacs-lisp :results output (defun my-src-block (src-block contents info) (princ (concat (format "[language: %s]\n" (org-element-property :language src-block)) (format "name: %s\n" (org-element-property :name src-block)) (format "parameters: %s\n\n" (org-element-property :parameters src-block (org-export-format-code-default src-block info)) (org-export-define-derived-backend 'my-html 'html :translate-alist '((src-block . my-src-block))) (org-export-to-file 'my-html "custom-src-table-export.html") #+END_SRC #+RESULTS: #+begin_example [language: python] name: print-table parameters: nil [language: emacs-lisp] name: get-properties parameters: nil [language: emacs-lisp] name: nil parameters: nil #+end_example You can see the parameters are nil in each case, even though we know the print-table block does have parameters. I do not know where the parameters get lost, so I am reporting the issue here. John Kitchin writes: > I have noticed that when code blocks have input variables, e.g. > > #+tblname: tbl-data > | x | y | > > |---+---| > | 1 | 1 | > | 2 | 4 | > | 3 | 9 | > > #+BEGIN_SRC python :var data=tbl-data > print data > #+END_SRC > > > #+RESULTS: > : [[1, 1], [2, 4], [3, 9]] > > When I export this, the codeblock shows no indication of what "data" is, > or where it came from. I had hoped to develop a filter that would allow > me to put something like: > > language=python > parameters: :var data=tbl-data > > in front of the block for an html export. I tried following the example > here: http://orgmode.org/manual/Advanced-configuration.html at the end, > by defining a derived mode. However, it does not appear that the > information is kept in the parse tree. > > (src-block (:language python :switches nil :parameters nil :begin 536 > :end 578 :number-lines nil :preserve-indent t :retain-labels t > :use-labels t :label-fmt nil :hiddenp nil :value print data > :post-blank 2 :post-affiliated 536 :parent #4)) > > although if I look at the element at point, it seems to be there: > > (src-block (:language python :switches nil :parameters :var > data=tbl-data :begin 536 :end 629 :number-lines nil :preserve-indent t > :retain-labels t :use-labels t :label-fmt nil :hiddenp nil :value print > data (princ (org-element-at-point)) > > I am not sure why the :end values are not the same though. > > Here is what I was trying to use: > > #+BEGIN_SRC emacs-lisp > (defun my-src-block (src-block contents info) > (message "start-block\n\n%s\n\nend-block" info) > (concat "" >(format "[language: %s]" (org-element-property :language src-block)) >(format "\nparameters: %s" (org-element-property :parameters src-block)) >"" > (org-export-format-code-default src-block info))) > > (org-export-define-derived-backend 'my-html 'html > :translate-alist '((src-block . my-src-block))) > > (org-export-to-file 'my-html "custom-src-table-export.html") > (browse-url "custom-src-table-export.html") > #+END_SRC > > There are two issues with this block: > > 1. All parameters are listed as nil > 2. the code is not syntax highlighted in html at all. > > Any suggestions on how to achieve this? I also want to insert > tablenames, and if the src-block is named to put the name above the > block (for extra gravy, a hyperlink from :var to the source ;). > > thanks, -- --- John Kitchin Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu
[O] update on missing :parameters in code blocks
I did some more digging on the missing :parameters during export, and it seems that the src block itself is different during export than in the buffer. Below illustrates what I mean. In the buffer, if I look at the contents of the code block using output from org-element-at-point, it looks as I expect, with the complete header. But, using the same method in the export, it is clear that the header args are not there. I have not figured out where they disappear yet. * Bug report 2 for org-mode Here is a named table #+tblname: tbl-data | x | y | |---+---| | 1 | 1 | | 2 | 4 | | 3 | 9 | Here is a named src-block with a defined var #+name: print-table #+BEGIN_SRC python :var data=tbl-data :results value return data #+END_SRC Now, we illustrate that the src-block does have :parameters. #+name: get-properties #+BEGIN_SRC emacs-lisp (save-excursion (re-search-backward "#\\+name: print-table") (buffer-substring (org-element-property :begin (org-element-at-point)) (org-element-property :end (org-element-at-point #+END_SRC #+RESULTS: get-properties : #+name: print-table : #+BEGIN_SRC python :var data=tbl-data :results value : return data : #+END_SRC : : In the export machinery, though it appears the src-block is not the same. #+BEGIN_SRC emacs-lisp :results output :exports none (defun my-src-block (src-block contents info) (princ (buffer-substring (org-element-property :begin src-block) (org-element-property :end src-block))) (org-export-format-code-default src-block info)) (org-export-define-derived-backend 'my-html 'html :translate-alist '((src-block . my-src-block))) (org-export-to-file 'my-html "custom-src-table-export.html") #+END_SRC #+RESULTS: #+begin_example #+name: print-table #+BEGIN_SRC python return data #+END_SRC #+name: get-properties #+BEGIN_SRC emacs-lisp (save-excursion (re-search-backward "#\\+name: print-table") (buffer-substring (org-element-property :begin (org-element-at-point)) (org-element-property :end (org-element-at-point #+END_SRC #+end_example The parameters seem to be gone in the python block. -- --- John Kitchin http://kitchingroup.cheme.cmu.edu
[O] [BUG] Macro Argument Truncation
I am making heavy use of latex strikeout for a report I'm preparing in org
mode. I defined a macro for the necessary latex snippet, but the argument
gets truncated on export.
MWE:
* Section
{{{stk(The argument for this macro is several lines long. It seems
that after a certain length, the macro argument gets truncated, as the
tex output from exporting this org buffer contains a properly
terminated strikeout block with only part of this text.)}}}
#+MACRO: stk @@latex:\sout{$1}@@
C-c C-e l L produces:
\sout{The argument for this macro is several lines long. It seems
that after a certain length}
% Emacs 24.3.1 (Org mode 8.2.7c)
I see no mention of any reason for this in the macro node of the manual or
on list archives. Am I doing something wrong or is it a bug?
Note:
org-plus-contrib is an installed package.
Status: Installed in `.../.emacs.d/elpa/org-plus-contrib-20140901/'.
Version: 20140901
Re: [O] [BUG] Macro Argument Truncation
Aloha Jacob,
Jacob Gerlach writes:
> I am making heavy use of latex strikeout for a report I'm preparing in org
> mode. I defined a macro for the necessary latex snippet, but the argument
> gets truncated on export.
>
> MWE:
>
> * Section
> {{{stk(The argument for this macro is several lines long. It seems
> that after a certain length, the macro argument gets truncated, as the
> tex output from exporting this org buffer contains a properly
> terminated strikeout block with only part of this text.)}}}
> #+MACRO: stk @@latex:\sout{$1}@@
>
>
> C-c C-e l L produces:
>
>
> \sout{The argument for this macro is several lines long. It seems
> that after a certain length}
> % Emacs 24.3.1 (Org mode 8.2.7c)
>
>
> I see no mention of any reason for this in the macro node of the manual or
> on list archives. Am I doing something wrong or is it a bug?
Arguments to the macro are separated by commas. Your text gets
truncated at the first comma.
>From the manual:
/\
| You can define text snippets with |
||
| #+MACRO: name replacement text $1, $2 are arguments |
||
| which can be referenced {{{name(arg1, arg2)}}}.|
\/
hth,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [BUG] Macro Argument Truncation
Ah, of course. Right under my nose, but since I "knew" I only had one
argument, I didn't even think about it.
Thanks for the quick reply.
On Sun, Sep 21, 2014 at 9:40 PM, Thomas S. Dye wrote:
> Aloha Jacob,
>
> Jacob Gerlach writes:
>
> > I am making heavy use of latex strikeout for a report I'm preparing in
> org
> > mode. I defined a macro for the necessary latex snippet, but the argument
> > gets truncated on export.
> >
> > MWE:
> >
> > * Section
> > {{{stk(The argument for this macro is several lines long. It seems
> > that after a certain length, the macro argument gets truncated, as the
> > tex output from exporting this org buffer contains a properly
> > terminated strikeout block with only part of this text.)}}}
> > #+MACRO: stk @@latex:\sout{$1}@@
> >
> >
> > C-c C-e l L produces:
> >
> >
> > \sout{The argument for this macro is several lines long. It seems
> > that after a certain length}
> > % Emacs 24.3.1 (Org mode 8.2.7c)
> >
> >
> > I see no mention of any reason for this in the macro node of the manual
> or
> > on list archives. Am I doing something wrong or is it a bug?
>
> Arguments to the macro are separated by commas. Your text gets
> truncated at the first comma.
>
> From the manual:
>
> /\
> | You can define text snippets with |
> ||
> | #+MACRO: name replacement text $1, $2 are arguments |
> ||
> | which can be referenced {{{name(arg1, arg2)}}}.|
> \/
>
> hth,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>
[O] Toggling Macro Definition
After writing a detailed report in org-mode and submitting it via
latex/pdf, I've found out that for the next version of the report, I am
required to use "track changes" in MS Word.
I thought my best way to approximate this is to submit two versions: one
with removed text in strikeout and new text in red (hence my previous post
where I learned to RTFM on Macro arguments).
The best hack I could think of to generate a "final" pdf was to change the
macro definition so that struckout text isn't included in the output and
new text is no longer red.
i.e.
#+MACRO: stk @@latex:\sout{$1}@@
becomes
#+MACRO: stk
This works for body text, but leaves an empty headline, and in general I
don't really like it. Do any experienced org-folk have recommendations on a
better way to do this?
Re: [O] update on missing :parameters in code blocks
John Kitchin andrew.cmu.edu> writes: > > I did some more digging on the missing :parameters during export, and it > seems that the src block itself is different during export than in the > buffer. Below illustrates what I mean. In the buffer, if I look at the > contents of the code block using output from org-element-at-point, it > looks as I expect, with the complete header. But, using the same method > in the export, it is clear that the header args are not there. > > I have not figured out where they disappear yet. > [snip] Instrument org-export-as. Then step thru it. Before this line: (org-export-execute-babel-code) the buffer copy ( my-buffer<2>, say ) will show the parameters/headers. After that line is executed, they are gone. You can work around this by `advicing' various babel functions and inserting things you want to save as attributes, but it would be nice not to need to do that. HTH, Chuck
Re: [O] update on missing :parameters in code blocks
Hi John, Look at the functions ‘org-babel-exp-src-block’ which calls ‘org-babel-exp-do-export’, which calls ‘org-babel-exp-code’. The tl;dr version is that indeed the babel export machinery does change the code block in substantial ways, including the removal of parts of it. This plays merry hell with the cache mechanism, as you might imagine (different header args at different points -> the sha1 hash changes). A year or more ago I worked on a patch to overhaul this system. I got partway through before giving up, because it turned into a massive undertaking and because it became clear that the cache mechanism would not be very reliable/useful for my needs anyway. But IMHO it remains an imperfection in the interface between babel and the new parser, and it might be possible to avoid the necessity of doing this sort of destructive modification during export. Along the way simplification of the code might also be possible. Let me know if you’re interested; I may be able to dig the old half-patch out of a disused git branch somewhere. It may have bitrotted some, but it may also be useful. -- Aaron Ecay
Re: [O] Toggling Macro Definition
Aloha Jacob, Jacob Gerlach writes: > After writing a detailed report in org-mode and submitting it via > latex/pdf, I've found out that for the next version of the report, I am > required to use "track changes" in MS Word. If this means you are required to submit a pdf file that looks like it is the output from "track changes" in Word, then the latexdiff utility might work for you. You pass it the old .tex file and the new .tex file and it creates a third .tex file that tracks the changes. hth, Tom -- Thomas S. Dye http://www.tsdye.com
