[Orgmode] Publishing configuration
Hi all, Is there a way to tell org-publish-org-to-html something like: "If you find a link to a file outside the base-directory, copy that file as an attachment to publishing-directory/attachments" in org-publish-project-alist? I have PDFs that need to remain distributed throughout the file system (i.e., not in a single location I can set as a base-directory) but that I would like to also publish as attachments on my Org-maintained Web site. I can't find anything in the documentation that gives me a hint about how to do this, or if there's a better solution that I haven't thought of. Any help (included pointers to documentation that I have thick-headedly missed) would be much appreciated! Thanks! Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Bug: ordered lists after unordered
Hello all, I think I've found a bug with the way org-meta-return behaves. I occasionally need to follow an unordered list by an ordered list, without any intervening text. For example: * Some heading - unordered - unordered - unordered 1) ordered I normally use M- (org-meta-return) to add a new item to a list. But in this kind of situation, using M- to insert the next ordered list item displays the message "Not in an item" and modifies the above lists to look like this: * Some heading 1 - unordered - unordered - unordered 1) ordered 1) And point ends up after the first "1", before the first "-" in the unordered list. (If the ordered and unordered lists are reversed, M- doesn't act quite so strangely, though it does convert any items in the unordered list into ordered list items. This might be a feature; but it's not the behavior I personally would prefer.) I am using Org version 7.01trans. Thanks! Best, Richard Lawrence ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Bug: ordered lists after unordered
Hi Nicolas, Thanks for getting back to me. >> I think I've found a bug with the way org-meta-return behaves. I >> occasionally need to follow an unordered list by an ordered list, >> without any intervening text. For example: > >> * Some heading >> - unordered >> - unordered >> - unordered >> >> 1) ordered > >> I am using Org version 7.01trans. > > This behavior has been fixed in development version of Org mode. You > may upgrade. Great! Pulling from git fixed this issue for me. > By the way, please note that, by default, you now need to insert two > blank lines to separate lists (that is unless you set > `org-empty-line-terminates-plain-lists' to t). Thanks for the tip! Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Latex export: Differing behavior for symbols in headlines
Dear Orgsters, I am seeing differing behavior for how special symbols that appear in a headline are exported to LaTeX, depending on whether I export an entire Org document or just the current subtree. I have, for example, a file that looks like this: * Headline 1 ** Headline 2, concerning $\alpha$ and $\beta$ If I export the whole document, the $'s around \alpha and \beta are properly interpreted as math-mode delimiters, and Headline 2 becomes a section title that looks exactly as I would expect. If I export just Headline 2, however, the $'s are escaped, and show up as literal '$' characters in the title of the exported document. (I can't remove the $'s, because I am actually using some custom LaTeX commands, not special symbols like \alpha and \beta that Org would recognize as needing to be put in math mode.) So, two questions: 1) Is this difference between whole-document vs. current-subtree export the expected behavior? 2) If so, what's the right way to work around it? If not, where should I look to try and fix it? (I am running the latest development version of Org.) Thanks! Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Bug: Re: Latex export: Differing behavior for symbols in headlines
Nick Dokos writes: >> 1) Is this difference between whole-document vs. current-subtree export >> the expected behavior? >> > Looks like a bug to me. I can reproduce it too. Was my original email enough to constitute a bug report? >> 2) If so, what's the right way to work around it? If not, where should >> I look to try and fix it? >> I'm still wondering about the latter question here. This is important enough to me that I am willing to take a stab at fixing it, but my Elisp experience is basically limited to init file customizations. Can anyone who knows the ins and outs of the LaTeX export code give me a few pointers about where to start? Thanks, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bug: Re: Latex export: Differing behavior for symbols in headlines
Richard Lawrence responds to himself:
>>> 2) If so, what's the right way to work around it? If not, where should
>>> I look to try and fix it?
>>>
>
> I'm still wondering about the latter question here. This is important
> enough to me that I am willing to take a stab at fixing it, but my Elisp
> experience is basically limited to init file customizations. Can anyone
> who knows the ins and outs of the LaTeX export code give me a few
> pointers about where to start?
OK, I've been reading the code in org-latex.el for a while now, and I
have at least come to understand why $'s in a headline are escaped when
the export is restricted to a subtree.
The explanation is this: within org-export-as-latex, the headline is
bound to `title', and passed to org-export-latex-make-header, which in
turn passes the value into org-export-latex-content, thusly:
;; org-latex.el, line 1283
(format
"\n\n\\title{%s}\n"
;; convert the title
(org-export-latex-content
title '(lists tables fixed-width keywords)))
org-export-latex-content works by performing a series of mutations on a
temporary buffer. One of these mutations,
org-export-latex-special-chars, replaces "$" with "\$". So that's
where the replacement is happening when the headline of a subtree is
used as the title for a LaTeX export.
(Actually, this begs the question: how should one export an Org file to
LaTeX if part of the title should be in math mode? Is escaping $'s in
the document title really the best behavior? My guess would be that
people need math mode in their document titles far more often than they
need a literal "$".)
Here's what I don't understand yet: when the entire Org file is
exported, rather than just a subtree, the headlines (which eventually
become the section titles in the output) are apparently *not* processed
this way, because then the $'s in such headlines pass through unescaped.
I'm not sure if this is because they never pass through
org-export-latex-content, or because $'s have had the org-protected
property set by the time they *do* pass through it.
Guidance would be much appreciated!
Best,
Richard
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Preserve math environments in title when exporting to LaTeX
Hi all,
This patch fixes the issue I originally described here:
http://article.gmane.org/gmane.emacs.orgmode/32281
It preserves math-mode delimiters (e.g. "$" and "\(") in the document
title when exporting to LaTeX. (That is, it prevents them from being
escaped, by running the title through org-export-preprocess-string,
which marks them with the org-protected property.) It should work
regardless of whether the title is pulled from a headline, from the text
before the first headline, or from an explicit #+TITLE declaration.
(This is my first time contributing a patch to a Free Software project
-- so please, let me know what you think!)
Best,
Richard
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 4fcbbb7..f97436c 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -727,13 +727,33 @@ when PUB-DIR is set, use this as the publishing directory."
(org-current-export-file buffer-file-name)
(title (or (and subtree-p (org-export-get-title-from-subtree))
(plist-get opt-plist :title)
- (and (not
- (plist-get opt-plist :skip-before-1st-heading))
- (org-export-grab-title-from-buffer))
+ (unless (plist-get opt-plist :skip-before-1st-heading)
+ (let ((pt (org-export-grab-title-from-buffer)))
+ (remove-text-properties 0 (length pt)
+ '(:org-license-to-kill t) pt)
+ pt))
(and buffer-file-name
(file-name-sans-extension
(file-name-nondirectory buffer-file-name)))
"No Title"))
+ ; Preprocessing preserves math environments in title
+ (title
+ (and title (string-match "\\S-" title)
+ (org-export-preprocess-string
+ title
+ :emph-multiline t
+ :for-LaTeX t
+ :comments nil
+ :tags (plist-get opt-plist :tags)
+ :priority (plist-get opt-plist :priority)
+ :footnotes (plist-get opt-plist :footnotes)
+ :drawers (plist-get opt-plist :drawers)
+ :timestamps (plist-get opt-plist :timestamps)
+ :todo-keywords (plist-get opt-plist :todo-keywords)
+ :add-text nil
+ :select-tags nil
+ :exclude-tags nil
+ :LaTeX-fragments nil)))
(filename
(and (not to-buffer)
(concat
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: General question on dealing with Latex to word conversion
Hi Marvin, > Org mode is now a part of my daily work-flow, not only do I use it for > teaching, scheduling my time, but I also use it to store my research notes. > The only snag is several of my collaborators is tied to microsoft word, and > thus my only work around is to export my notes and draft from Org to plain > text and then reformat everything in word, which real time sync., especially > when I have to retype equations in Mathtype. Hmm. Given that at least one person in your team must adapt to the others, might I ask why that person has to be you? Is there a reason that your collaborators can't use Org mode and/or LaTeX? (Or at least export their work to plain text, so you can incorporate it in your Org files?) I'm not trying to be antagonistic, or insensitive to your particular situation. But since no one else has said it, I just wanted to point out that it might be easier or more efficient, in terms of overall person-hours, to convert from Word to Org, rather than the other way around. (I don't know anything about MathType, but it would seem within the realm of possibility to *automatically* convert a Word document containing MathType that has been exported as plain text into something Org and/or LaTeX can understand. This site, for example, makes it look like MathType can export to TeX and LaTeX, so maybe that gets you most of the way there: http://www.dessci.com/en/products/mathtype/features.htm) Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: General question on dealing with Latex to word conversion
Jeff Horn writes: >> I'm not trying to be antagonistic, or insensitive to your particular >> situation. But since no one else has said it, I just wanted to point >> out that it might be easier or more efficient, in terms of overall >> person-hours, to convert from Word to Org, rather than the other way >> around. > > If they're stuck in word and the OP is using org, he may be the only > person on his team capable of changing his workflow. In that case, > person hours are saved if he switches and doesn't have to educate > everyone else (or they educate themselves), though *his* man hours are > not economized. Well, doesn't that depend on how long it would take to educate everyone else, vs. how many hours he will eventually spend doing manual conversion to Word? Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Umlauts in LaTeX export
Hi all,
I don't think this is a bug so much as an unfortunate consequence of
expected behavior, but I wanted to document it here for the sake of
future mailing list searches, because I didn't find anything about it
myself. (If someone has a better solution than the one I propose,
please clue me in!)
To add an umlaut/trema/diaeresis to a letter in LaTeX, I use the \"
command, as in:
G\"{o}del
Unfortunately, due to the fact that Org export treats both `{}' and `"'
specially, this will be exported to LaTeX as:
G\''\{o\}del
It isn't sufficient to surround the \"{o} with math mode delimiters, e.g.,
G\(\"{o}\)del
even though this will prevent Org from escaping the brackets and
converting the double-quote, because the command doesn't seem to produce
output in math mode. (The compiled file will read "Gdel".)
So, the work-around I've come up with is to use an \mbox inside math
mode, which prevents Org from doing the escapes/conversions:
G\(\mbox{\"{o}}\)del
A bit ugly, but it produces the correct output.
Hope that helps someone! And again, if there's a better way, please let
me know!
Best,
Richard
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Umlauts in LaTeX export
Thanks to all for your suggestions! >>> you could define some shortcut to insert the appropriate Unicode >>> character into your text (as your keyboard probably does not feature >>> a "ö" key), or copy/paste the Umlauts from another Emacs file as >>> necessary. >>> But there is a nice emacs solution to enter umlauts: >>> =C-x RET C-\ german-postfix RET= This enables an input method which >>> allows you to enter all german umlauts: ä ü ö Ä Ü Ö and ß. >> Even better, for the OP, is to switch to the tex input method (M-x >> set-input-method RET tex RET)! In this case, you can type \"o to get ö. >> Almost all TeX and LaTeX sequences are understood (e.g. \forall to get >> ∀, \exists for ∃, \alpha for α, \leftrightharpoons for ⇋, and so on.) >> You can see all the characters with =describe-input-method=. One concern I have with all of these solutions is that, if I use them in a file that is encoded in ASCII, Emacs will switch the encoding to Unicode, and that could have unexpected consequences (e.g., with version control). But I have also noticed that many of my Org files (though not the one I originally encountered this problem in) are already encoded in UTF-8, and I haven't had any Unicode-related problems. Are these fears misplaced? Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Differences in headline exports [was: Umlauts in LaTeX export]
Nick Dokos writes:
> Nevertheless that does not absolve org from dealing with \" properly. In
> fact, it deals with it correctly in a heading but not in the text:
>
> * G\"odel
>
> G\"odel
>
> gives:
>
> ...
> \section{G\"odel}
> \label{sec-1}
>
>
> G\''odel
>
>
> However, surrounding the o with braces breaks things in both places.
>
> I think part of the problem is that headings and text go through
> different processing: e.g. text goes through org-export-latex-content,
> whereas headings don't. So fixing a problem like this in one place is
> not enough.
I was recently crawling through the LaTeX export code, because I was
getting different results for how a heading was exported depending on
whether it was simply a section title or whether it was the title for
the whole document. (See: [1]) It was quite a chore for me to understand
the different code paths that a headline can go through.
I still don't fully understand why things are this way; shouldn't all
text that's exported to LaTeX be processed in the same way, regardless
of where it appears (with the exception, of course, of text between
delimiters that mark it as literal LaTeX input)?
I sent a patch [2] that basically dealt with my problem by sending
headlines that become document titles down the same code path that
headlines and content are sent through (namely,
org-export-preprocess-string), but I haven't received any response. Is
that because there's some important reason to treat these contexts
differently? Am I missing something?
Best,
Richard
[1] http://article.gmane.org/gmane.emacs.orgmode/32281/
[2] http://article.gmane.org/gmane.emacs.orgmode/32540/
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Beeminder/Kibotzer
Hi all, I just came across this site, which looks really interesting: http://beeminder.com/about They provide a service for tracking progress toward (quanitifiable) goals, and they show you a graph that includes: - your actual data - a trend line/zone for your actual data - an ideal trend line for progress toward your goal - an ideal trend zone (the "Yellow brick road") Seems like a pretty neat tool for dealing with procrastination. Does anyone use Org to do anything like this? Between Org tables and calling out to R or Gnuplot (both features I haven't used) it seems like it shouldn't be too hard to do something similar. I'm curious if others think this would be a valuable add-on to have around. Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [PATCH] Preserve math environments in title when exporting to LaTeX
Carsten Dominik writes: > On Nov 21, 2010, at 9:54 AM, Carsten Dominik wrote: > >> Hi Richard, >> >> I have now applied this patch. I am not entirely sure it will have >> no adverse effects, so please, people who do export to LaTeX, check >> after the next pull if you see any problems. > > Actually, I think I have just found a better way to solve this issue, > in a way that will also solve it for figure captions. > > Please, LaTeX export users, test the current git version. Hi Carsten, I've just tried the latest version, and it works for me, at least on the case I was having trouble with before. Thanks! Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Generate list of all tags in use?
Hi Uriel, > Is there a way to generate a list of all tags in use in all agenda files? > I'm thinking of something like a tag cloud. Would org-get-buffer-tags help you out? Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: LaTeX export of lists
Hi Tom,
> Is there an easy way to keep text following a list with the list, i.e,
> without a blank line following the list, during export?
>
> * List
> 1. First item
> 2. Second item
> Following text.
>
> Gets exported as:
>
> \section{List}
> \label{sec-1}
>
> \begin{enumerate}
> \item First item
> \item Second item
> \end{enumerate}
>
> Following text.
>
> I don't want a blank line between \end{enumerate} and "Following text."
Is this because you don't want to start a new paragraph in LaTeX? I
have used \noindent on the occasions when I have run into this issue.
* List
1. First item
2. Second item
\noindent
Following text
Not necessarily pretty, but it works, if you're just looking to prevent
indentation.
Best,
Richard
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Blockquotes in lists?
Dear Orgsters,
Is it possible to embed blockquotes inside list items, so that (e.g.)
they are indented beyond the enclosing list item in LaTeX exports?
So, for example, the following Org list:
* Some headline
- list item 1
#+BEGIN_QUOTE
A great thing was said!
#+END_QUOTE
- list item 2
will export to LaTeX as:
% ...
\begin{itemize}
\item list item 1
\end{itemize}
\begin{quote}
A great thing was said!
\end{quote}
\begin{itemize}
\item list item 2
\end{itemize}
% ...
but what I would like is:
% ...
\begin{itemize}
\item list item 1
\begin{quote}
A great thing was said!
\end{quote}
\item list item 2
\end{itemize}
% ...
Is this possible? If so, what am I missing something? If not, should
there be a way to get this behavior?
Thanks!
Best,
Richard
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Blockquotes in lists?
Hi Nicolas, >> Is it possible to embed blockquotes inside list items, so that >> (e.g.) they are indented beyond the enclosing list item in LaTeX >> exports? > > This is a work in progress. There should be a testing phase related to > it soon. Great, thanks! Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Another LaTeX export corner case...
This evening, I noticed that the footnote syntax breaks if you use LaTeX
commands with an optional argument inside a footnote, e.g.:
* Some headline
Blah blah blah blah[fn:: This enlightened message brought to you by
\cite[p. 100]{SomeBibKey}]
The internal square brackets in the \cite command cause the whole
footnote to be escaped/exported literally (i.e., "[fn:: ..." appears in
the text of the document).
Is this a bug, or something that I must learn an Org incantation to work
around?
Thanks!
Richard
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Another LaTeX export corner case...
Scot Becker writes:
> I use the
> somewhat ugly workaround of just switching to LaTeX \footnote{} commands
> just for those footnotes where I need optional arguments. But I'd be
> glad
> not to have to mix footnote commands.
Ah, I hadn't thought of that. Thanks!
Richard
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Export LaTeX file to different directory?
Hi Joost,
> If I export (part of) an org-mode file to LaTeX, the LaTeX file is created in
> the same directory as the org-mode file. Is there a way to specify the file
> should go somewhere else? Googling and looking through the manual didn't give
> me
> anything concrete. There is apparently a property EXPORT_FILE_NAME, but
> setting
> this doesn't seem to have any effect. (Though I may be using it wrong, there
> wasn't any description or example of it in the manual... Plus, I'd like to be
> able to specify just the export directory, not necessarily the file name as
> well.)
As far as I know (though others may know better) this isn't possible
using per-file configuration with the simple export functions (C-c C-e l
and friends). It *is* possible through the publishing framework,
though.
When you define a publishing target in org-publish-project-alist, you
can specify both the :base-directory and :publishing-directory options.
For example:
(setq org-publish-project-alist
'(("orgfiles"
:base-directory "~/org"
:publishing-directory "~/tmp"
:publishing-function org-publish-org-to-html
:base-extension "org$")))
See the documentation for "Publishing."
This approach, however, requires you to do some Elisp customization, and
it requires you to statically define your source and destination
directories. You may need something more flexible or configurable on a
per-file (or per-export, even) basis. The only solution I know of there
is to export to a temporary buffer, then save that buffer in the
location you want -- though of course this requires interaction from
you.
If others know of a middle road between using the publishing framework
and just doing C-c C-e L C-x C-s every time, I would be interested in
hearing about it too. (If there isn't a middle road, consider this my +1
on adding this feature.)
Best,
Richard
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Export LaTeX file to different directory?
Jeff Horn writes: > If you want to publish a single project, one that dumps all the files > in the tmp directory, it would publish all files in the source > directory (definitely not what the OP had in mind, I think). If you > publish "only this file," it might work. Yes, there is a "Publish current file" option in the export dispatcher, though I've never used it myself. Using this option with the right combination of :base-directory, :publishing-directory, and :exclude/:include in org-publish-project-alist might do the trick, depending on the OP's exact scenario. Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: How can i share a single org-default-notes-file between multiple instances of emacs?
Eric Holbrook writes: > At work i typically need to have at least 2 emacs running: 1 for the > project i'm working on at the moment; 1 for notes, email, ~/.bashrc, > ~/.alias, etc. > > I often have more than 1 project going at a time, so i end up with 3 > or 4 emacs running, sometimes more. > > I'd like to be able to do 'org-capture from any emacs, and have them > all dump into the same org-default-notes-file, which i have creatively > named notes.org. > > How can i do this? I thought of possibly setting a defadvice tied to > notes.org that tells all running emacs to unceremoniously revert that > buffer before doing anything else to it, and to save it when done with > it. I really don't know if this would help you out in your particular scenario, but have you thought about using the Emacs server[1]? If, for example, you start the server from within your "home" Emacs, but then visit project files from the command line using emacsclient, those emacsclient instances will see your notes buffer in its current state, even if it's unsaved, and changes you make there will be visible in your home Emacs. I think the server requires Emacs 23, so if you have that at work, it might be worth looking into. Richard [1] http://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] time-up/down in org-agenda-sorting-strategy seems to have no effect?
Hi everyone,
I've just started using custom agenda views in earnest, and I would like
to be able to control how several custom views are sorted. I have tried
to set org-agenda-sorting-strategy to reflect what I want, but it seems
to have no effect on how items are sorted. I'm wondering if I'm missing
something.
Specifically, I see no difference in how the items in todo, tags, and
tags-todo agenda views are sorted when I set time-down or time-up as the
first (or only) sorting criterion. (tag-up/down and category-up/down
seem to work alright; I haven't tested the other sorting criteria.)
Here's how I'm expressing the setup I want:
#+BEGIN_SRC emacs-lisp
(setq org-agenda-sorting-strategy
'((agenda habit-down time-up priority-down category-keep)
(todo time-down priority-down category-keep)
(tags time-down priority-down category-keep)
(search time-up priority-down todo-state-up)))
(setq org-agenda-custom-commands
'(("r" "Reading list" tags-todo "+reading")
("S" . "STUDY context searches")
("Sf" todo "FIND")
("Sp" todo "PRINT")
("Sr" todo "READ")
("Sn" todo "NOTES")
("St" tags-todo "+STUDY")
("D" tags-todo "+COMPUTER")
("H" tags-todo "+HOME")
("E" tags-todo "+ERRAND")
("F" tags "+FREETIME")))
#+END_SRC
Any insight you can provide will be very much appreciated. Thanks!
Best,
Richard Lawrence
[Orgmode] [OT] Importing plain text attachments into Org
Dear Orgsters, I'm hoping I can solicit a little advice about pulling email attachments into Org (via Gnus), since some of the folks on this list seem to have experience interacting with Gnus from Org. I realize that the meat of my question may be better asked on the Gnus list, but if anyone here has knowledge and/or a similar setup that you'd be willing to share, I would very much appreciate hearing about it. The background: I am about to begin teaching a writing-intensive course. Students will email me their papers every week. I have no desire to download, print, and read a bunch of .doc files by hand every week. (This is a pain, and requires proprietary software I don't have; and I find 12pt double-spaced Times New Roman much more difficult to read than a LaTeX article anyway.) So I am considering asking my students to email their papers in plain text. I would like to then apply some automated processing on my end that would: 1) Download each student's paper into a file in my "teaching" directory. 2) Apply some *very* simple transformations, like adding #+TITLE before their title, replacing Windows `smart quote' characters with ASCII ` and ', and generally making the files play nice with Org on a GNU box. I might also like to do things like run a word count at this stage to make sure they are within the guidelines for the course. 3) Use Org's export abilities to compile each paper into a PDF (or perhaps a single PDF for the whole week's submissions). 4) [Not necessary, but would be cool:] Automatically insert TODO items into my agenda for each paper I have to read; automatically grade students who don't turn in papers on time; etc. Does anyone have any ideas about how I might go about this, and whether it's worth the effort to automate it? (I will have about 100 papers to read this semester.) Thanks so much! Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Call org-map-entries just on children?
Hi all, I'm sure I'm just being thick here, but any help would be appreciated... I want to call org-map-entries in a way that calls a function at each *child* of the current tree, but not at the current tree itself. That is, for some function f, if my Org file looks like this: * Paper 1 ** Student 1 ** Student 2 ... I want to call f at "Student 1", "Student 2", etc. but not at "Paper 1". But if point is positioned at "Paper 1", then (org-map-entries 'f nil 'tree) first calls f at the "Paper 1" entry, not the "Student 1" entry. How can I apply f just to the *children* of "Paper 1"? (The reason I need to do this is that f needs to enforce that each of the children has a value for a certain property, but the parent entry should not have this property.) Thanks! Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Call org-map-entries just on children?
Hi Bastien, >> How can I apply f just to the *children* of "Paper 1"? > > You can simply add > > (setq org-map-continue-from (outline-next-heading)) > > at the very beginning of your `f' function. Ah, very good. Thanks so much! Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: ePub and Org mode
"Eric Schulte" writes: >> The only thing missing is a function to export all (not excluded) >> subtrees one by one and honor the properties slapped onto each subtree. >> > > `org-map-entries' should satisfy this need. -- Eric I have been doing something similar with LaTeX export. Here is my (pretty hacky) code; it should be easy to adapt to HTML export. It does the following: 1) export each subtree of the current tree as a separate PDF (there's some validation here, to make sure each of these trees has properties that I need to produce the output I want) 2) concatenates the resulting PDFs into a single PDF for printing (this requires the pdftk package) Good luck! Richard (defun org-export-individual-pdfs-and-concat () (interactive) (setq export-files nil pdf-files nil ; point must be in main tree to be exported (not a subtree) concat-pdf-name (get-property-or-fail (point) "CONCATENATED_PDF_NAME")) (progn (org-map-entries (lambda () (setq org-map-continue-from (outline-next-heading)) (org-mark-subtree) ; org-map-entries positions point at the beginning of each subtree (let ((org-trust-scanner-tags t)) (push (get-property-or-fail (point) "EXPORT_FILE_NAME") export-files)) (org-export-as-pdf nil)) nil 'tree) (concat-pdfs (nreverse (mapcar 'tex-name-to-pdf-name export-files)) concat-pdf-name))) (defun get-property-or-fail (pom property) (or ; probably some opportunity for optimization here...see function ; documentation for org-map-entries (org-entry-get pom property) (error (format "Entry at %s does not define property %s" (org-heading-components) property (defun tex-name-to-pdf-name (filename) (concat (file-name-sans-extension filename) ".pdf")) (defun concat-pdfs (in-files out-file) (shell-command (format "pdftk %s cat output %s" (mapconcat (lambda (s) s) in-files " ") ; join pdf names with spaces out-file))) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: question about capture templates
Sébastien Vauban writes: > "Filippo A. Salustri" wrote: >> I would really like to be able to vary the file into which a captured item >> goes. Specifically, I'd like to insert the item into whatever file I was >> visiting when I started the capture. > You have to use backquotes so that expressions are considered as code to > execute, instead of data. See Emacs manual. I'm not sure that backquotes will do what the OP wants. Backquotes will allow the OP to compute the value of a target file at the time the (setq org-capture templates ...) form is evaluated. The OP needs a way to determine the target file at the time of capture (right?), not at the time the variable is set. Unfortunately, I don't have any suggestions on how to hack that. If the target of most captures can be determined based on their type, maybe you can just use the refile mechanism (C-c C-w instead of C-c C-c) to manually handle the exceptions. If not, maybe look into wrapping or replacing org-capture-refile somehow. Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: question about capture templates
"Filippo A. Salustri" writes: > org-capture clearly has the original buffer handy (for %a > stuff) yet I can't get it out of there without hacking the org code, which I > am loathe to do. I too was in a situation just today where I was calling org-capture programatically, and needed access to stuff in the calling environment. My solution (which may not be very good, and may not work for you) is to dynamically scope the calling environment stuff that I need into the org-capture call, like so: #+begin_src emacs-lisp ; in the calling code, I scope some val I need into `foo...' (let ((foo some-val-I-need)) (org-capture nil "tm")) #+end_src Then, in the template identified by "tm", I have S-expression expansion that operates on foo, even though it wasn't explicitly passed as a parameter, e.g.: * My capture template The car of foo is %(car foo). The cdr of foo is %(cdr foo). %a etc. ... This works well enough for me, though it may feel kind of icky, since from the template writer's perspective, `foo' looks like a global variable whose value could be coming from anywhere. Accordingly, then, this solution is mostly useful if you know that you're going to be using the template via custom Elisp calls to org-capture, and not via the usual capture interface, so that you can guarantee that `foo' has a useful value when the template is expanded. One gotcha: S-expressions in templates are apparently always evaluated as function calls -- you can't just directly access a string value, like %(foo). Hope that's helpful! Richard P.S. Since you say you have Scheme experience: note that this solution would NOT work in Scheme, since Scheme, unlike Emacs Lisp, is lexically scoped. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: question about capture templates
Carsten Dominik writes: > I do love dynamic scoping, this give a lot of power in Emacs. > Org-mode internals use that power often. This is venturing a bit far afield, at least for this thread, but I'm curious if anyone knows: does the recent work on supporting Elisp in Guile mean that Elisp applications are eventually expected to be ported to Scheme? And if so, what does that mean for Org development? >> One gotcha: S-expressions in templates are apparently always evaluated >> as function calls -- you can't just directly access a string value, like >> %(foo). > > I guess you mean a variable value? Right, yes, a variable with a string value. I guess my point is more properly stated by saying there doesn't seem to be a way to evaluate an atomic S-expression in a template. But this seems like a fair trade for not having to write a second set of parentheses around every non-atomic expression. > The shortest form may be %(symbol-value foo) if you want to access the > value of a variable in a template. That's handy -- thanks! Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] org-map-entries and org-map-continue-from
Hi all,
Bastien had advised me [1] to use
(setq org-map-continue-from (outline-next-heading))
in a function called by org-map-entries in order to map that function
across just the /children/ of the current entry (i.e., to exclude the
current `parent' entry itself). This works great, but I have now found
that it has a weird side-effect: it calls the function twice on the last
child.
For a simple example, suppose I write:
#+BEGIN_SRC emacs-lisp
(defun get-export-filenames ()
(interactive)
(setq export-files '())
(progn
(org-map-entries
(lambda ()
(setq org-map-continue-from (outline-next-heading))
(let ((org-trust-scanner-tags t))
(push (org-entry-get (point) "EXPORT_FILE_NAME") export-files)))
nil 'tree)
(message export-files))) ; errors, but lets me see the list of collected
values
#+END_SRC
And I call this function from a buffer that looks like:
* Top
** One
:PROPERTIES:
:EXPORT_FILE_NAME: one
:END:
** Two
:PROPERTIES:
:EXPORT_FILE_NAME: two
:END:
** Three
:PROPERTIES:
:EXPORT_FILE_NAME: three
:END:
** Four
:PROPERTIES:
:EXPORT_FILE_NAME: four
:END:
Then the list that I get back (the value of export-files) looks like:
("four" "four" "three" "two" "one")
Whereas I would like it to be just:
("four" "three" "two" "one")
Can anyone see what I need to do to achieve that? [Apart from just using
(cdr export-files), I mean -- I'd like to know the /right/ way.] I'm
puzzled because outline-next-heading, if called interactively from the
last child, does indeed put point at the end of that child or at the
next (parent-level) heading, so it doesn't seem that the problem is that
it somehow loops back when there is no next child-level entry.
Many thanks if you catch something I've missed!
Best,
Richard
[1] http://article.gmane.org/gmane.emacs.orgmode/37244/
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [O] org-map-entries and org-map-continue-from
Nick Dokos writes: > The problem is that org-entry-get does not just look forward: it looks > *around* and finds the property when point is both at the beginning > and at the end of the headline "Four", so you get "four" twice. Ah, so that's the culprit. Thanks! > Maybe this? > > #+BEGIN_SRC emacs-lisp > (defun get-export-filenames () > (interactive) > (setq export-files '()) > (progn > (org-map-entries >(lambda () > (setq org-map-continue-from (outline-next-heading)) > (if org-map-continue-from > (let ((org-trust-scanner-tags t)) >(push (org-entry-get (point) "EXPORT_FILE_NAME") > export-files > nil 'tree) >(message export-files))) ; errors, but lets me see the list of > collected values > > #+END_SRC Indeed, that does seem to work: outline-next-heading returns nil if it doesn't find a next heading, and a buffer location otherwise (at least that's the way it looks based on some tests; the documentation doesn't say, and I didn't crack open the code). So wrapping the rest of the lambda body in (if org-map-continue-from ...) prevents it from executing that one last time. Thanks for your help, Nick! Best, Richard ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [O] Delete in emacs on OS X
John Hendy writes: > I can't figure out what key combo provides "delete." Fn+delete behaves > like backspace. In my searching, I found reference to C-?, but that > comes up as unrecognized. > > How do I delete? Try C-d. If that doesn't work, look at the help for delete-char (C-h f delete-char ), which should tell which key it's bound to. Best, Richard
Re: [O] Something like 'org-clock-in-at-time'?
John Hendy writes: > Could someone fill me in on your process for clocking in things after > the fact? I've been trying to get into to clocking, but, especially at > home, I don't return to my computer in between every different thing. > Instead, I stop at it when I get a pause and try to fill in what I've > been doing. So far, this has been something akin to: > > - create a new sub-headline and call it what I was doing > - C-c C-c to tag it > - C-c C-x C-i followed by C-c C-x C-o to create a clocked time stamps > - Manually edit the times > - C-c C-c to update the count Not sure if this is entirely relevant here, but I have a similar problem. I often find I need to mark recurring tasks as "done" that I completed on the previous day or even earlier. For most tasks, it doesn't matter when I mark them as done; but if the task uses org-habits, it means I have to manually edit the timestamp so that it doesn't mess up the habit log going forward. If there's a better way to deal with situations like this, I'd love to hear about it. If not, I just wanted to point out another use case for anyone thinking about implementing "retroactive timestamp editing" functions. Thanks! Richard
Re: [O] Email -> Org-mode: charset problem
> At Mon, 27 Jun 2011 10:30:06 +0200,
> Karl Voit wrote:
>> Is there somebody who managed to develop an email to Org-mode bridge
>> without having charset problems? (No, I do not use Emacs as a
>> MUA[4])
David Maus writes:
> I do use an Emacs base mua (Wanderlust) and recently started to file
> reference notes for certain messages. Because in cases I want to keept
> the message (e.g. an interesting usenet post) I save the raw message
> to a temporary file and add it as an attachment. This works nice,
> although I'd really like to have an automated way of save+attache when
> capturing.
>
> So, what about org-capture? You could use a script that serializes the
> raw message to disk and -- somehow -- calls capture with a reference
> to this file. Emacs opens the mail file and extracts information
> required for the template using the build-in MIME libaries (mml-*
> IIRC) which are capable of correctly parsing and if necessary decoding
> (e.g. quoted printable encoded letters in the subject). After
> extracting the information Emacs creates the appropriate capture
> entry, somehow adds the message file as attachment and finishes the
> capture process.
I do something like this, though I also use Emacs as an MUA (Gnus).
My approach was to write a little parser that binds the various parts of
a message in a pre-determined format to variables that I grab in an Org
capture template, and dynamically scope those variables into a call to
org-capture. I have included my code below.
But to address your original question: unfortunately, I do not have a
solution to the encoding problem. Despite my "pre-determined format",
the emails I got (student paper submissions) were often in strange
encodings that I ended up fixing by hand during the capture process.
However, as David points out, I believe that it would be possible to use
Emacs' MIME libraries to do the dirty work. I just haven't had time (or
desire, honestly) to figure out how. If you figure it out, though, I'd
love to hear about it!
My (quite simplistic) code is below. I hope you find it useful if you
decide to go this route!
Best,
Richard
simple working example: Gnus side
; handling paper submissions
(defun capture-paper-part ()
"Call parse-paper and capture the result using org-capture"
(interactive)
(let ((paper (parse-paper *phil100-paper-header-re*)))
(if paper
(org-capture nil "ap") ; "ap" is Org-capture key combo for template
shown below
(message "No paper found in this part"
(if (not (boundp 'gnus-mime-action-alist))
(setq gnus-mime-action-alist '()))
(add-to-list 'gnus-mime-action-alist '("capture paper" . capture-paper-part))
(defconst *phil100-paper-header-re*
"^\\(?1:.*\\)\n\\(?2:.*\\)\n\\(?3:[Pp]aper *\\(?31:[0-9]+\\).*\\)")
(defun parse-paper (header-re)
"Return an alist representing a paper, by parsing the buffer using header-re"
(save-excursion
(goto-char (point-min))
(if (re-search-forward header-re nil t)
(list `(header . ,(or (match-string 0) ""))
`(author . ,(or (match-string 2) ""))
`(title . ,(or (match-string 1) ""))
`(date . ,(or (match-string 3) ""))
`(num . ,(or (match-string 31) ""))
`(body . ,(buffer-substring (match-end 0) (point-max
nil)))
(defun paper-property (key)
; paper is dynamically scoped in by capture-paper-part
(or (cdr (assoc key paper)) ""))
(defun string-replace-downcase (from to in)
"Replace FROM with TO in string IN, and also downcase the result"
(with-temp-buffer
(insert in)
(goto-char (point-min))
(while (search-forward from nil t)
(replace-match to nil t))
(downcase-region (point-min) (point-max))
(buffer-substring (point-min) (point-max
simple working example: Org capture template
** %(paper-property 'author)
:PROPERTIES:
:EXPORT_TITLE: %(paper-property 'title)
:EXPORT_AUTHOR: %(paper-property 'author)
:EXPORT_DATE: Paper %(paper-property 'num)
:EXPORT_FILE_NAME: %(concat (paper-property 'num) "-"
(string-replace-downcase " " "-" (paper-property 'author)) ".tex")
:END:
%(paper-property 'body)
Re: [O] can I force all-caps in part of a headline in a capture template?
Hi Chris,
Try this: in your .emacs, add the following code:
(defun prompt-for-lastname-and-upcase ()
(upcase (read-string "Last name: ")))
This defines a function that will prompt the user to type a last name
into the minibuffer, converts the result into uppercase, and returns it
as a string.
Then, in your capture template, change "%^{LASTNAME}" to
"%(prompt-for-lastname-and-upcase)".
Best,
Richard
Re: [O] can I force all-caps in part of a headline in a capture template?
Richard Lawrence writes:
> Try this: in your .emacs, add the following code:
>
> (defun prompt-for-lastname-and-upcase ()
> (upcase (read-string "Last name: ")))
>
> This defines a function that will prompt the user to type a last name
> into the minibuffer, converts the result into uppercase, and returns it
> as a string.
>
> Then, in your capture template, change "%^{LASTNAME}" to
> "%(prompt-for-lastname-and-upcase)".
By the way, if you need to do the same thing for other fields, you can
do something like this instead:
(defun prompt-and-upcase (prompt-str)
(upcase (read-string prompt-str)))
This generalizes the original function I gave you; you can pass in a
prompt string.
Then, in your capture template, wherever you need an uppercase field:
%(prompt-and-upcase "Whatever prompt you need: ")
e.g.,
%(prompt-and-upcase "Last name: ")
Best,
Richard
[O] Using Org for a dissertation
Hi all,
I am a graduate student in philosophy, and I am about to begin writing
my dissertation. I am wondering about whether I should write it in Org,
or stick to plain LaTeX.
This question has been asked before:
http://article.gmane.org/gmane.emacs.orgmode/22756
But that was two years ago; Org has changed a fair bit, and I'm
wondering if there are any updates to the advice given there. Moreover,
I'm wondering if anyone has written a dissertation or other long
documents in Org in the meantime, and what their experiences have been.
(Henri-Paul, do you still read this list?)
I have used Org to write most of the shorter papers I have so far
written as a graduate student, and been very happy with the results. I
prefer most of Org's editing features and conventions to bare LaTeX. I
haven't previously had much of a need to mix TODO items and writing, but
imagine I will with a dissertation. I *have* been relying on Org's
to-do list features for my reading: I enter new readings as TODO items
via capture, and include the bibliographic fields that make them
suitable to export via org-bibtex when it comes time to reference them.
None of the writing I've done so far has had strict formatting
requirements, however, and I have run into enough small formatting
issues in the past that I want to avoid having them grow into large
issues in the context of a dissertation.
Since I am not in the sciences, I doubt that I will have many figures or
complex tables, which I know can lead to headaches. Here are a few of
the things I *am* worried about. I'm sure most of them can be dealt
with; I am guessing that most of these issues reflect my ignorance or
outdated knowledge of Org features. I'd be grateful for pointers or
workarounds for them:
1) Section labels and other in-document references. It's nice that Org
generates these on export, but I need to be able to assign and use
labels that will not change if the document is reordered. I know I can
simply add such labels via a \label command, but I am worried that using
them in addition to Org's autogenerated labels might cause numbering
problems in LaTeX.
2) Escaping/unrecognized commands. I have occassionally run into
annoyances where Org escapes characters or commands that I intend to be
exported literally ("~" and "$" are perennial offenders). Export also
tends to break when fill-paragraph breaks a LaTeX command across a line,
like:
some preceding text up to the end of the line \cite{SomeAuthorReference,
AnotherReference}.
3) Indentation around #+BEGIN_*/#+END_* environments. (I most often use
QUOTE.) I usually have to explicitly control indentation in a way that
I wouldn't have to in LaTeX, because Org inserts blank lines around them
during export.
4) Inline footnotes. I usually prefer to use inline footnotes, but I
think I have found in the past that Org's syntax for inline footnotes
([fn:: ...]) interacts badly with LaTeX commands, especially anything
requiring a "]" in the footnote text.
5) Bibtex and bibliographies. I love keeping my reading list as Org
TODO entries, but would like a more automated way to export (just) the
entries I need for a particular document to a .bib file. I would also
like to have more control over the bibliography as a section of my
document. The \bibliography command must live under some Org heading or
other, and as far I as know it can't live under its own without
generating an extraneous heading, so I have to be careful that it ends
up at the end of the last section.
Are there other issues that people have run into when using Org to write
a longer document with strict formatting requirements? Again, any and
all advice is greatly appreciated!
Thanks,
Richard
Re: [O] Using Org for a dissertation
Hi Eric, Eric Schulte wrote: > I am currently writing my dissertation (proposal) in Org-mode. So far > it is working very well for me, I can export to both PDF for more formal > submissions to my adviser and to HTML for less formal posting to a web > page. I keep *all* of my reading notes as Org-bibtex headlines in a > single large reading.org file. I have a (somewhat complex) system > whereby I am able to reference these bibtex entries from the > dissertation and automatically generate the required .bib file as part > of my document export process. One nice side effect of this setup has > been the ability to do a fun graphical export of my references [1]. > > My entire dissertation directory is in a public git repository [2], you > may find my Makefile [3] useful (although again I should warn you that > my particular setup may be needlessly complex). Thanks for your helpful advice! Your org-bibtex setup in particular looks like exactly what I need. (Your dissertation proposal looks very interesting, too!) I think what I will do is stick with Org for now, and try to be smarter about a few things (like the #+LABEL command...which I must have read about at some point but forgotten) so that, if I ever need to drop down to straight LaTeX, it will be easy to make the switch. You've given me a helpful example to follow. Best, Richard
Re: [O] Using Org for a dissertation
Thomas S. Dye wrote: > The current Org-mode LaTeX exporter is nifty, but it was designed to > export notes and not dissertations. It can be configured to do that, > but the extra translation step adds some complexity and potentially > introduces problems. In my work this potential downside is more than > made up for by the reproducible research facilities of Org-mode. When I > don't need these, I typically write in LaTeX. The AucTeX environment is > a terrific help to the author of a LaTeX document and in many ways it is > ideal for a dissertation writer. Thanks for your advice. This has been my experience so far as well. > That said, the new LaTeX exporter in Org-mode is being designed to > overcome some of the limitations of the old exporter, so it will > probably be the case that the translation step from Org-mode to LaTeX > will get easier. It would be good to have someone write a dissertation > using the new exporter because it might stretch the exporter in ways > that smaller, simpler documents do not. But I doubt if this will be the > path of least resistance to the finished dissertation. I have seen mention of the new exporter on this list a bit, but I don't read the list enough to know where to find it. How can I try it, if I want to see how it compares to the current exporter? Is it in a public branch somewhere? Would feedback from me be helpful? > I'm using ebib to manage BibTeX data now and I really like it. It works > well with both LaTeX and Org-mode, so I don't have to switch gears > completely to move from one authoring environment to the other. Hmm, I hadn't heard of ebib, but I will have a look at it. Thanks for the tip! Best, Richard
Re: [O] Using Org for a dissertation
Tom and Nicolas, Thanks! I will give the new exporter a shot when I have a chance and let you know how it goes. Best, Richard
Re: [O] Using Org for a dissertation
Hi Suvayu, suvayu ali wrote: > In case you are interested, I'm attaching some relevant bits. It has > examples on how to put in tables (with short and long captions), > figures, latex snippets and finally how I included a bibliography and > appendices. > > Hope this will help. Thanks! This is definitely helpful. The ignoreheading tag is a nice hack -- fixes one of those niggling issues I've had with LaTeX export. Best, Richard
Re: [O] Using Org for a dissertation
Hi Markus, Thanks for your advice. I figure that, like you, I may eventually need to switch to LaTeX, but will stick with Org for now, at least until my document structure is quite settled. Can you elaborate a bit on the following? Markus Grebenstein wrote: > What I disliked/ preferred in auctex: > - missing footnote folding in stable version Stable version of Org, or Auctex? What exactly is missing? > - footnotes frequently lead to trouble with overlapping latex groups. What is a Latex group? How they could overlap? (I would especially like to be aware of potential footnote problems ahead of time.) > - reference handling in especial w.r.t headings (if you change the > heading you use the reference) Do you mean you prefer \label and \ref in Latex over Org's abstraction? Thanks! Best, Richard
Re: [O] Automatically Increasing Priority
Hi Esben, Esben Stien writes: > Does there exist such a concept of automatically increasing priority > after a while? I'm not aware of any way of automatically changing the priority of a headline, though if you really need this, it looks like it would be fairly simple to do it in Elisp using the `org-map-entries' and `org-priority' functions. I have the same problem you do: the priorities feature does not really map well onto my work. I used to capture a priority with every item, but I've recently stopped doing that because I found it didn't make sense for me. I think it makes more sense to assign priorities manually, when you're in a context of figuring out which tasks to work on, rather than in a context of recording tasks to be done in the future. I suggest that, if you aren't doing this already, you put deadlines on your TODO items, rather than priorities, and then sort the agenda by deadline. This has the advantage that it `prioritizes' all your tasks in a natural way in the agenda: anything due soon (or past due) comes up before things that are due later on. So if you assign every task an initial deadline, its `priority' will go up automatically, as time passes. When it comes due, you can always readjust the deadline if your initial estimate didn't work out. It's also useful, I think, to make one of your tasks a recurring weekly review: go through all your other tasks, make sure you still want to do them, adjust deadlines as necessary, etc. If you find you still want priority cookies in addition to deadlines, you could assign them during this review for tasks due in the upcoming week. At that point, you'll be in a context where assigning priorities to these items makes more sense, since you'll be looking at the other tasks each task competes with. Hope that helps! Best, Richard (If possible, please encrypt your reply to me using my PGP key: Key ID: CF6FA646 Fingerprint: 9969 43E1 CF6F A646. See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] How to programmatically use/edit data provided on capture
Hi Marcin,
Marcin Antczak writes:
> I got capture template with prompts to collect some properties:
>
> #+BEGIN_SRC
> * TODO %\1 / Some task description
>:PROPERTIES:
>:NAME: %^{NAME}
>:END:
> #+END_SRC
>
> My question is: How to get information on user input data to transform
> this data before capture finalize.
I too have wanted to do something like this, but I am not sure that it
is possible without hacking org-capture, because I don't think you can
hook into the template processing at an arbitrary point.
Is it really important that you transform the data *before* capture
finalize? If not, I think you could do this *during* capture finalize
by replacing, say, a pre-determined string "PUT-NAME-HERE" with the value of
(custom-dashify-function (org-entry-get (point) "NAME"))
You could do that from org-capture-prepare-finalize-hook, maybe. Would
that work for you? It has some limitations:
- it's only easy to recover data that was entered as properties or tags, not
arbitrary strings
- you can't continue to edit the capture buffer after doing this
processing, since the hook will only be called after you start
finalization
If you come up with a better solution, I'd like to hear about it! I
have scratched my head about this several times before, but I've never
come up with a satisfactory solution.
Good luck!
Best,
Richard
[O] [PATCH] ox-latex: fix lost export option latex-custom-id-labels
Hi everyone, I recently pulled from master and noticed that an option in the LaTeX export backend that I rely on had gotten lost in the shuffle. (I didn't check the history, but I believe it must have been removed accidentally, since the code that checks this option is still there.) Here is a patch to re-introduce it. Thanks! Best, Richard >From 0b351bfc2e494bb010a4c27768a5ccd2ae846367 Mon Sep 17 00:00:00 2001 From: Richard Lawrence Date: Wed, 20 Aug 2014 16:55:50 -0700 Subject: [PATCH] ox-latex: fix lost export option * lisp/ox-latex.el (latex): reintroduce `latex-custom-id-labels' option in backend TINYCHANGE --- lisp/ox-latex.el |1 + 1 file changed, 1 insertion(+) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 6ea35c5..c14d6dc 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -110,6 +110,7 @@ ;; Other variables. (:latex-active-timestamp-format nil nil org-latex-active-timestamp-format) (:latex-classes nil nil org-latex-classes) +(:latex-custom-id-labels nil nil org-latex-custom-id-as-label) (:latex-default-figure-position nil nil org-latex-default-figure-position) (:latex-default-table-environment nil nil org-latex-default-table-environment) (:latex-default-table-mode nil nil org-latex-default-table-mode) -- 1.7.10.4
[O] Bug?/performance issue in org-icalendar-export-current-agenda
Hi all,
I pulled from master recently (for the first time since the spring), and
since the update, I have noticed a performance/lockup issue. The
problem occurs when exporting an agenda view to iCalendar format.
My Emacs version is 23.4.1 and my Org version is "8.3beta" (I am
currently on commit 767895...)
I have traced the problem down to a call to
`org-icalendar-export-current-agenda', though I don't know if the
problem is in this function or in another function called by it.
Somewhere during the execution of this function, Emacs goes to 100% CPU
usage (on one core) and memory usage starts growing until I kill the
process.
Here's what my setup looks like. I have just one entry in
`org-agenda-custom-commands' that defines the files field. It looks
like:
("Z" "Export to iCalendar file" tags "+event|+appointment" nil
("~/Documents/website/public_html/lib/attachments/calendar.ics")
I normally only call this command via a cron job that exports my agenda
files to .ics, which until recently was working fine. But I have
noticed I can reproduce the lockup interactively by building an agenda
view with this command, and then calling
`org-icalendar-export-current-agenda' on it (which is also what happens,
a few steps down the call chain, during the cron job).
I have run some tests by manually setting org-agenda-files, then
building this agenda and eval'ing
(org-icalendar-export-current-agenda "/tmp/agenda.ics")
in the agenda buffer. The results:
1) Using just a simple three-entry test file, the export completes quickly
and I don't see the lockup.
2) Using an agenda file which contains plenty of real data
(about 1000 lines) but no headlines tagged "event" or "appointment"
(i.e., a file for which this agenda view is empty), the call to
`org-icalendar-export-current-agenda' takes about 5 seconds to
complete, even though there are no entries to export. During those
5 seconds, the Emacs process goes to 100% CPU usage.
3) Using a different agenda file (of about 4000 lines) which contains
about 75 matching headlines, the call to
`org-icalendar-export-current-agenda' does not complete within
several minutes, during which time I see 100% CPU usage and rapid
memory usage growth.
So it looks to me like maybe some part of the export process uses
exponentially more time and memory, depending on the input, since a
minimal test case does not produce the problem.
What's the next step for debugging this? Please let me know if I can
provide more information.
Thanks!
--
Best,
Richard
Re: [O] Bug?/performance issue in org-icalendar-export-current-agenda
Nicolas Goaziou writes: > Interestingly, I introduced a patch that should speed up this function > yesterday. You may want to update Org (the patch landed after 767895) > and try again. Indeed! I just pulled again and the problem is gone. The export runs much more reasonably now, completing in a few seconds even with all my agenda files in the mix. Thanks! Best, Richard
Re: [O] Getting lots of Emacs crashes
Hi Noah, Noah Slater writes: > I'm getting a lot of Emacs crashes recently using Org. Is there any > way I can help to debug why this is happening? What version of Org are you using? What happens when Emacs crashes? Best, Richard
Re: [O] Custom formatting during export
Hi Gabe, Gabe Becker writes: > * section title > > Here is some text, but I want [specialthing: this bit here] to be formatted > differently than [newanddifferent: this other big over here]. > > > Where I would have defined specific custom formatting rules for > "specialthing" and "newanddifferent" type entities. > > Is there a way to do this in orgmode? If not, it seems like it would be a > very useful feature (at least to me:) ). Note: I don't care about the > syntax as long as the result is the same. Based on the syntax you chose for your example, you might be looking for custom link types; see the documentation for the org-add-link-type function: -- (org-add-link-type TYPE &optional FOLLOW EXPORT) Add TYPE to the list of `org-link-types'. Re-compute all regular expressions depending on `org-link-types' FOLLOW and EXPORT are two functions. FOLLOW should take the link path as the single argument and do whatever is necessary to follow the link, for example find a file or display a mail message. EXPORT should format the link path for export to one of the export formats. It should be a function accepting three arguments: paththe path of the link, the text after the prefix (like "http:") descthe description of the link, if any, or a description added by org-export-normalize-links if there is none format the export format, a symbol like `html' or `latex' or `ascii'.. The function may use the FORMAT information to return different values depending on the format. The return value will be put literally into the exported file. If the return value is nil, this means Org should do what it normally does with links which do not have EXPORT defined. -- You could define a custom link type for "specialthing", and then use the export parameter to provide a function that will export the path of the link in a backend-specific way. Then you would write blah blah [[specialthing:whatever-path]] blah blah I'm sure there are good examples of how to do this on Worg, but I cannot seem to find them at the moment... If you need to do something more complicated than what custom link types allow, Thorsten's suggestions are the place to start: Org has a lot of ways to customize export output. Best, Richard
Re: [O] capture template, filename
Hi Michael,
Michael Welle writes:
> I have a capture template like this:
>
> ("j" "Journal" plain
>(file (capture-report-data-file "~/org"))
>"%^{Heading}\n#tags %^{Tags}\nmeta-creation_date: %(format-time-string
> \"%m/%d/%Y %H:%M:%S\")\n\n%?")
>
> In capture-report-data-file I want to calculate the filename for the org
> file. The filename should be constructed with information from the
> heading's value.
If I understand correctly, you are trying to choose the file in which to
save the captured data dynamically, at capture time, based on the value
of the headline...right?
I think you will not be able to do this by setting a target in
org-capture-templates, as you are trying to do. The reason is that the
target for the capture is expanded and determined before any data is
captured. (If you can calculate the filename without using the heading
value, you could use (function ...) or (file+function ...) rather than
(file ...) in org-capture-templates to set the target location.)
I think what you probably want to do is *refile* the captured entry to
the desired location after the template is filled out. I think you can
do this from one of the org-capture-{prepare,before,after}-finalize
hooks -- probably org-capture-prepare-finalize-hook. You could there
add something like
(lambda ()
(org-back-to-heading)
(let ((target (get-target-from-heading)))
(org-refile nil nil target))
where get-target-from-heading should return a refile location based on
the heading. I'm not sure about all the arguments to org-refile
(particularly the second, `default-buffer'). Also if you have other
capture templates where you don't want to dynamically refile based on
the heading, you need to insert a test in there to only do the refile in
the cases you want.
I should say this is not tested and you may need to play around with
some things to get it to work for you. Someone else may have better
advice. But I hope that points you in the right direction!
Best,
Richard
[O] Bug? Or new behavior? Paragraphs in HTML
Hi everyone, After updating this morning, I notice that when #+BEGIN_SRC org * My headline Some text here. #+END_SRC is exported to HTML, the paragraph below the headline is no longer wrapped in a paragraph tag: #+BEGIN_SRC html 1 My headline Some text here. #+END_SRC Whereas if there is more than one paragraph below the headline, they are: #+BEGIN_SRC org * My headline Some text here. What about here? Or here? #+END_SRC becomes #+BEGIN_SRC html 1 My headline Some text here. What about here? Or here? #+END_SRC I am guessing this is the result of commit 9a34a13c077f592c5528d95c155ecdf2d655937e. Is this now the expected behavior for paragraphs, even *outside* of lists? Personally I find this a bit unexpected. It broke my CSS, and I am not sure what the best way to fix it is. What should I do if I want to style all the blocks of text on a page, since some will be wrapped in tags and others won't be, depending on whether there are other paragraphs in the same div? Best, Richard
Re: [O] Changed behaviours of LaTeX exporter in version 8.0+
Hi Joseph, "Kyeong Soo (Joseph) Kim" writes: > I just found out that, if I close Emacs and relaunch it, all variables for > filter (i.e., 'org-export-filter-*') are not defined. As a result, the > following elisp codes for the workaround based on both your suggestion and > the filter example in the manual causes void variable error (i.e., > "Symbol's value as variable is void: > org-export-filter-special-block-function"): Try adding: (require 'ox) before your filter definition. Best, Richard
Re: [O] Changed behaviours of LaTeX exporter in version 8.0+
Hi Joseph,
"Kyeong Soo (Joseph) Kim" writes:
> Sorry for asking another question; this time it is for the
> cross-referencing in LaTeX export, which existed before (e.g., Sec. 16 of
> manual for <8.0) but is gone now.
> ...
> Now with 8.2.7c and the following org internal link to a section
>
> ... described in Sec. [[*SectionOne][SectionOne]] ...
>
> LaTeX export generates the following code:
>
> ... described in Sec. \texttt{SectionOne}, ...
I think the problem here is that you don't have a link type, and the new
LaTeX exporter doesn't convert links it doesn't understand into
references.
I use a series of custom link types to make references to document
parts in my dissertation. Here's the code I use; you will probably want
to adapt it to your use case:
#+BEGIN_SRC elisp
;; use CUSTOM_ID properties to generate labels
(setq org-latex-custom-id-as-label t)
(defun org-find-headline-by-custom-id (prefix path)
"Find a headline in the current buffer by CUSTOM_ID value PREFIX:PATH."
(save-excursion
(goto-char (point-min))
(and
; borrowed from org.el; there doesn't seem to be a function that searches
; for a headline with a specific property value
(re-search-forward
(concat "^[ \t]*:CUSTOM_ID:[ \t]+" prefix ":" path "[ \t]*$") nil t)
(setq pos (match-beginning 0
(if pos
(progn
(goto-char pos)
(org-back-to-heading t))
(message (format "Headline with CUSTOM_ID %s:%s not found." prefix path
(defun org-export-dissertation-link (prefix path desc format)
"Export a link to a dissertation section, etc.
In LaTeX, the exported link will look like:
DESC~\\ref{PREFIX:PATH}
"
(when (member format '(latex linguistics))
(format "%s~\\ref{%s:%s}" desc prefix path)))
; Parts:
(org-add-link-type
"part"
(lambda (path)
(org-find-headline-by-custom-id "part" path))
(lambda (path desc format)
(org-export-dissertation-link "part" path (or desc "Part") format)))
; Chapters:
(org-add-link-type
"chap"
(lambda (path)
(org-find-headline-by-custom-id "chap" path))
(lambda (path desc format)
(org-export-dissertation-link "chap" path (or desc "Chapter") format)))
; Sections:
(org-add-link-type
"sec"
(lambda (path)
(org-find-headline-by-custom-id "sec" path))
(lambda (path desc format)
(org-export-dissertation-link "sec" path (or desc "Section") format)))
; Tables:
(org-add-link-type
"tab"
(lambda (path) (org-link-search (concat "tab:" path)))
(lambda (path desc format)
(org-export-dissertation-link "tab" path (or desc "Table") format)))
#+END_SRC
So a link like "[[sec:foo]]" renders as "Section~\ref{sec:foo}",
"[[chap:foo]]" renders as "Chapter~\ref{chap:foo}", etc. when exported
to LateX, and you can follow links to jump to the appropriate document
headline.
Note that this works by giving my document sections fixed labels by
setting the CUSTOM_ID property. I give headlines a descriptive name in
this property, using the LaTeX convention of prefixing "sec:", etc. to
keep my labels straight; Org then generates \label commands for document
parts using the CUSTOM_ID property. This requires setting
org-latex-custom-id-as-label. For example, a headline like
*** Another interesting section
:PROPERTIES:
:CUSTOM_ID: sec:interesting
:END:
is exported as
\section{Another interesting section}
\label{sec:interesting}
(The prefixes are important, since they function both as link types and
as parts of label/ref keys. As you'll notice, the
org-export-dissertation-link function adds them back in to the key.)
I find this setup keeps things working well across revisions,
re-ordering and re-naming of sections, etc.
Hope that helps!
Best,
Richard
Re: [O] Changed behaviours of LaTeX exporter in version 8.0+
Hi Joseph, "Kyeong Soo (Joseph) Kim" writes: > Great thanks for your answering my two questions, especially sharing your > experience for cross-referencing in LaTeX export. > > Though your suggestion for cross-referencing is an excellent workaround, I > wonder whether there is any benefit using org-mode in writing papers in > this case; for instance, manual setting of CUSTOM_ID would be a hassle, > considering that it can be easily & automatically done in LaTeX with > AUCTeX/RefTeX's label function. Don't you need to make sure that your sections have a consistent label in order to refer to them? At any rate, one of the reasons I use this solution is that I want to be able to easily use plain LaTeX at points where I discover that I can't make Org do everything I want. One of the cases I was worried about, for example, is having a section reference inside an embedded LaTeX block. If you don't know the label ahead of time, you can't use a raw \ref command inside #+BEGIN_LATEX...#+END_LATEX. So I like being able to set the labels via CUSTOM_ID on an as-needed basis. (I don't do it for every section.) You might be able to get away with less; it looks to me like the [[*Foo][Section Foo]] still produces a link to a headline in LaTeX output. Does that not work for you? > I still don't know why the new export engine has brought so many > compatibility issues in its behavior. It seems that I'd better go > back to the prior version (7.X) in order to focus on my research. The new export engine was a complete re-write, and came with an attempt to define and standardize Org syntax. Some of the incompatibilities are due to that standardization: the old LaTeX and HTML exporters might treat some text differently, for example, or not deal with some corner case, so in writing a new export engine, it was necessary to define the correct behavior. Other incompatibilities are just bugs that come with any new piece of software; the exporter is under heavy development and those are constantly getting fixed. The new exporter really is a *lot* better, and in my experience it is worth the effort to upgrade. I found myself bumping into the limitations of the pre-8.0 exporter very frequently. If you don't, you can wait, but I think you'll find the new exporter a lot easier to work with and to get help with. Best, Richard OpenPGP Key ID: CF6FA646 Fingerprint: 9969 43E1 CF6F A646 (See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
[O] Fwd: Enforcing newlines in plain text export
Hi Kaushal, I am forwarding your message to the Org mode list; you only sent it to me and Nicolas... Kaushal writes: > I came across > https://lists.gnu.org/archive/html/emacs-orgmode/2014-09/msg00466.html > through this emacs SE page: > http://emacs.stackexchange.com/questions/255/new-line-in-title-of-an-org-mode-exported-html-document > > The question I had asked on stackexchange was: How to export a mid-line > newline consistently in all formats. In paragraphs, all you need to do is end a line with "\\" to force a line break. This works for LaTeX, HTML, and plain text export, at least. This doesn't work in other kinds of syntax, like headlines, but you may not need it there. > But I couldn't figure out how to convey a newline character when exporting > to plain text (ascii). > > I tried, > > #+MACRO: NEWLINE @@latex:\\@@ @@html:@@ @@ascii:\n@@ > > But that simply puts out "\n" verbatim in the exported txt file. I don't know the answer to this specific issue---you might need to create a custom export filter---but hopefully you can just use "\\" instead of a macro like this. Do you need to enforce line breaks *outside of* a paragraph in plain text export? If so, what case are you worried about specifically? Best, Richard OpenPGP Key ID: CF6FA646 Fingerprint: 9969 43E1 CF6F A646 (See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] Enforcing newlines in plain text export
Kaushal writes:
> Interesting thing is that `\\` work fine at the end of the lines.
Yes, this is the behavior documented in the manual.
> I need to force line breaks in cases like these
>
> -
> For example, to execute the =example_1= test and run in the {{{NEWLINE}}}
>
> =/some/long/path/that/wouldn't/fit/along/with/the/above/line/in/the/same/line=
> directory,
> do the following..
> -
>
> In the above example, org-export will not wrap the text between the
> verbatim formatting characters "=".
> To ensure that the exported formats (html/pdf/ascii) look clean, I have to
> force a newline character just before that long string.
>
> Now using "\\" here instead of {{{NEWLINE}}} works but then I have to
> ensure that I place the "\\" character at the very end. If they are placed
> mid-line then they will be interpreted as newline by latex but simply "\\"
> character by html exporter.
As you say, "\\" at the end of the line works fine in this case. So it
seems you do not have a need for another solution.
> For consistency, the {{{NEWLINE}}} approach looks better; hoping that
> org-mode will support a special newline character for ascii exports at some
> time:
>
> -
> #+MACRO: NEWLINE @@latex:\\@@ @@html:@@ @@ascii:NEWLINE_CHARACTERS_
> FOR_ASCII_EXPORT@@
> -
This would really not be a great solution, and I don't think you should
expect Org mode to support it. If you really need something like this,
you could write an export filter for yourself (e.g., one that replaces
the string "ASCII_NEWLINE_CHARACTER" with "\n" in the exported buffer).
See the "Advanced configuration" section of the Exporting chapter in the
manual.
A better and more general solution, I think, would be to allow "\\" to
be used in other contexts, such as in headlines, title/author/date
declarations, etc. But that is a change to the currently documented
syntax, and it is probably a fair amount of work to implement, so it
probably isn't going to happen unless a variety of users really need it
and the maintainers think it would be an improvement to Org.
Best,
Richard
Re: [O] Enforcing newlines in plain text export
Hi Kaushal, Kaushal writes: > I am requesting a consistent solution. > > If "//" at the end of a line inserts newline when exporting in all formats, > then it should do the same when used in between a line too for ALL export > formats. > > Example: #+TITLE: Line one // Line two > > I am simply trying to explain why we need another solution for the sake of > consistency across all org exported formats. Like I said, I agree that something like this would be useful; I occasionally would like "\\" to have more general behavior, too. Anyway, it seems worth discussing. My point is that this would be a new feature, which is technically *inconsistent* with the currently-documented behavior. Implementing it would take some work and would involve breaking backward compatibility. (At least in theory -- I don't know if anyone out there relies on "\\" *not* being translated when it does not appear at the end of a line, but someone might be.) So it's not something to be taken lightly. Does anyone know why the behavior of "\\" is presently restricted to appearing at the end of the line in a paragraph? Does anyone need it to be exported literally when it appears elsewhere? Best, Richard
Re: [O] Help exporting to-do list as LaTeX/PDF
Hi Andreas, Andreas Yankopolus writes: > ... > kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 > ecbx1200 > > kpathsea: Running mktexfmt mf.base > mktexpk: Mismatched mode ljfour and resolution 600; ignoring mode. > mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; > nonstopmode; input ecbx1200 > This is METAFONT, Version 2.718281 (Web2C 2013) > > kpathsea: Running mktexfmt mf.base > I can't find the base file `mf.base'! > It took a while to get to this point, and I had to install a number of > font packages from the pkgsrc tex-* collection. I do have tex-ec-1.0 > and tex-eco-1.3 installed. But it seems like the problem is more with > metafont, which is completely beyond me. Yeah, this looks to me like your setup is attempting to load (or build??) a font as part of the compilation process. As far as I know, that is not something that should be required when compiling an Org document exported to LaTeX with the default options. What are the values of your org-latex-default-packages-alist org-latex-packages-alist org-latex-pdf-process variables? And what does the header of the exported .tex file look like? I guess the way to debug this is to remove the packages that are loaded in the exported .tex file, one at a time, until you discover the one that is at fault here. (If it's not some particular package, but rather TeX/LaTeX itself that's trying to use METAFONT, I think you're in deeper waters...) Best, Richard
Re: [O] math in parentheses
Hi Andreas, Andreas Leha writes: > I encounter a problem using $..$ expressions when they are enclosed > in parentheses. > This $T$ works, but ($T$) this does not. > > Is that expected behaviour? > > (Note that \(...\) expressions work.) Yes, that is the expected behavior. Org is much pickier about when "$" can be a math delimiter than "\( ... \)". The reason is that "$" can also be used as a regular symbol in Org documents; when it is, it should be *not* be exported as a math delimiter to LaTeX, and distinguishing non-math-delimiting from math-delimiting uses of "$" is not a trivial matter. Thus, when in doubt, use "\( ... \)". Best, Richard
[O] Bug: Agenda filtering by DEADLINE, SCHEDULED broken [8.3beta (release_8.3beta-575-g1dfa77 @ /home/rwl/src/org-mode/lisp/)]
Hi all,
I'm on master, and after updating recently (to a version after the
switch to the new property drawer syntax), some of my agenda views seem
to be broken.
Specifically, I cannot get any agenda views that compare a timestamp
with the SCHEDULED and DEADLINE properties to work. My complete config
is below, but the relevant agenda commands are:
("Rw" "School: next 7 days" tags-todo "reading-life&DEADLINE<=\"<+1w>\"")
("X." "Today's exercise" tags-todo "EXERCISE&SCHEDULED=\"\"")
("X+" "Tomorrow's exercise" tags-todo "EXERCISE&SCHEDULED=\"\"")
These all use relative timestamps, but it also seems to be broken if I
try to build an agenda using an absolute timestamp, e.g. via
C-c a m SCHEDULED="<2014-11-17>"
I don't see any error when running these agenda commands, but the
commands are fairly slow, and the resulting agenda view is always empty.
(Also, I did run the org-repair-property-drawers function in
etc/ORG-NEWS on my agenda files, so all the property drawers in my
agenda files should conform to the new syntax.)
I just updated again to the most recent master and I'm still seeing this
behavior. Any ideas?
Thanks!
Best,
Richard
Emacs : GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10)
of 2012-09-08 on trouble, modified by Debian
Package: Org-mode version 8.3beta (release_8.3beta-575-g1dfa77 @
/home/rwl/src/org-mode/lisp/)
current state:
==
(setq
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-todo-keyword-faces '(("WAITING" . "orange"))
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-agenda-custom-commands '(("." "Just today" agenda*) ("W" . "Writing")
("Wt" "Todo list" tags-todo
"+writing-life-FREETIME")
("R" . "Reading")
("Rw" "School: next 7 days" tags-todo
"reading-life&DEADLINE<=\"<+1w>\"")
("Rd" "School: research only" tags-todo
"+reading-life-teaching-FREETIME")
("Rt" "School: teaching only" tags-todo
"+reading+teaching")
("Rs" "School: all" tags-todo "+reading-life")
("Rl" "Life" tags-todo
"+reading-school-dissertation-ERRAND")
("E" . "Teaching") ("Er" "Reading" tags-todo
"+teaching+reading")
("Ep" "Prep" tags-todo "+teaching+prep")
("Ea" "Appointments" tags "+teaching+appointment")
("Et" "Other +teaching TODOs" tags-todo
"+teaching-reading-appointment")
("A" . "Administrative") ("A#" "Phone calls"
tags-todo "+PHONE")
("Am" "Emails" tags-todo "+mail-programming")
("F" . "Free/unstructured time")
("Fs" "School" tags-todo "+FREETIME-life-MAYBE")
("Fl" "Life/other" tags-todo
"+FREETIME+life-MAYBE")
("Fc" "Computing projects" tags-todo
"+FREETIME+COMPUTER")
("Fw" "Weekend projects" tags-todo "+WEEKEND")
("P" . "Campus")
("Pf" "Find" todo "FIND") ("Pp" "Print" todo
"PRINT")
("Po" "Other +CAMPUS TODOs" tags-todo "+CAMPUS")
("X" . "Exercise")
("X." "Today's exercise" tags-todo
"EXERCISE&SCHEDULED=\"\"")
("X+" "Tomorrow's exercise" tags-todo
"EXERCISE&SCHEDULED=\"\"")
("Xt" "All exercise entries" tags "EXERCISE")
("$" . "Money stuff")
("$b" "Things to buy soon" tags-todo "+BUY-MAYBE")
("$p" "Bills to pay soon" tags-todo "+money+bill")
("$w" "Wishlist/things to buy later" tags-todo
"+BUY+MAYBE")
("%" . "Maintenance")
("%M" "MAYBE items" tags
"MAYBE&TODO<>\"DONE\"&TODO<>\"CANCELED\"")
("%W" "WAITING items" todo "WAITING")
("%r" "Full reading list" tags-todo "+reading")
("Z" "Export to iCalendar file" tags
"+event|+appointment" nil
("~/Documents/website/public_html/lib/attachments/calendar.ics"))
)
org-agenda-files '("~/Documents/philosophy/dissertation/tasks.org"
"~/Documents/philosophy/reading/readings.org"
"~/org/school.org"
"~/org/life.org" "~/org/beer.org" "~/org/food.org")
org-metaup-hook '(org-babel-load-in-session-maybe)
org-capture-templ
Re: [O] Bug: Agenda filtering by DEADLINE, SCHEDULED broken [8.3beta (release_8.3beta-575-g1dfa77 @ /home/rwl/src/org-mode/lisp/)]
Hi Nicolas, Nicolas Goaziou writes: > This should be fixed. Thank you for reporting it. I confirm that it is fixed. Thanks so much! -- Best, Richard OpenPGP Key ID: CF6FA646 Fingerprint: 9969 43E1 CF6F A646 (See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] How to get "remember" working properly?
Hi Sharon,
Sharon Kimble writes:
> #+BEGIN_SRC emacs-lisp
> (setq org-remember-templates
> '(("Todo" ?t "* TODO %^{Brief Description} %^g\n%?\nAdded: %U"
> "~/.emacs.d/org/remember.org" "Tasks")
> ("Journal" ?j "** %^{Head Line} %U %^g\n%i%?"
> "~/.emacs.d/org/journal.org")
> ("Clipboard" ?c "** %^{Head Line} %U %^g\n%c\n%?"
> "~/.emacs.d/org/remember.org")
> ("Receipt" ?r "** %^{BriefDesc} %U %^g\n%?"
> "~/.emacs.d/org/finances.org")
> ("Book" ?b "** %^{Book Title} %t :BOOK:
> \n%[~/.emacs.d/.book_template.txt]\n"
> "~/org/journal.org")
> ("Film" ?f "** %^{Film Title} %t :FILM:
> \n%[~/.emacs.d/.film_template.txt]\n"
> "~/org/journal.org")
> ("Someday" ?s "** %^{Someday Heading} %U\n%?\n"
> "~/.emacs.d/org/someday.org")
> ("Private" ?p "\n* %^{topic} %T \n%i%?\n"
> "~/.emacs.d/org/privnotes.org")
> ("Contact" ?o "\n* %^{Name} :CONTACT:\n% ~/.emacs.d/org/contact.txt]\n"
>"~/org/privnotes.org")
> )
>)
> #+END_SRC
> With everything that I "remember" it shows it as, example only -
>
> * peace [2014-11-18 Tue 11:30]
>
> i.e. headline before the date. How do I get it the other way round
> please, meaning "date - headline"?
I think all you need to do here is move the "%U" in your templates
before the "%^{ ... }" that represents where you type in the headline.
For example, the "Journal" template becomes:
("Journal" ?j "** %U %^{Head Line} %^g\n%i%?"
"~/.emacs.d/org/journal.org")
See the section on Template Expansion in the Capture section of the
manual for an explanation of what's going on here.
> Also you close the entry by "C-c C-c" which, in my case, calls
> "Tags" again. How can I get it working right in this case please?
Not sure about this -- I don't use remember -- but a good place to start
is to do C-h k C-c C-c in your capture buffer; this will tell you which
function is bound to C-c C-c. If it's not what you expect, the next
step is to figure out what it should be bound to and set the appropriate
function in the relevant keymap.
Best,
Richard
Re: [O] Custom export backend based on HTML: how to implement own blocks?
Hi Marcin, Marcin Borkowski writes: > 1. How can I know (in org-html-underline, for instance) whether I am in > a MYBLOCK or not? I don't know whether this is the best approach, but given an element, you can walk up its parents in the parse tree until you either reach a MYBLOCK (in which case, you are in such a block) or the top of the tree (in which case, you aren't). Here's an approach I use in a custom backend[1] to do something similar. The following function is used to identify paragraphs (or other elements) that are within lists which have an #+ATTR_LINGUISTICS declaration specifying a :package property. (Because it recursively walks up the parse tree, this works even for paragraphs in arbitrarily-nested sublists.) #+BEGIN_SRC emacs-lisp (defun org-linguistics-find-enclosing-pkg (element) "Find the enclosing linguistics package of a (list) element during export." (let ((pkg (org-export-read-attribute :attr_linguistics element :package)) (parent (org-export-get-parent element))) (cond ; return if we found a :package attribute on element (pkg pkg) ; recurse on the parent if element has a parent but we found no ; :package attribute (parent (org-linguistics-find-enclosing-pkg parent)) ; otherwise, no :package attribute was found (t nil #+END_SRC (In your case, a similar function might only need to return a boolean value that indicates whether an element is inside a MYBLOCK, rather than returning a string, as this function does.) Then, in other code, I can treat paragraphs differentially based on whether they are in a list with this :package attribute set, e.g. #+BEGIN_SRC emacs-lisp (defun some-function-that-handles-paragraphs (paragraph) (let* ((enclosing-pkg (org-linguistics-find-enclosing-pkg paragraph)) ; ... ) ; (cond ((string= enclosing-pkg "gb4e") ; do something for paragraphs in lists with :package gb4e ... ) ((string= enclosing-pkg "linguex") ; do something for paragraphs in lists with :package linguex ... ) (t ; do a default thing for paragraphs that are not in such lists #+END_SRC Hope that's helpful! Best, Richard [1] The backend is ox-linguistics, a package for writing linguistics-style examples in Org: https://github.com/wyleyr/ox-linguistics
Re: [O] How to view everything DONE today?
Hi Sascha, Sascha Ziemann writes: > I tried to get a list of all items done today. I tried to open the agenda > view but is does not show anything. What is the right command to see the > items done today? If you use logging, one way to do this is to press "l" in the agenda, to turn on "log mode". This will show you all the tasks you worked on, including the ones that you marked done. I'm not sure if this is possible without logging, since your org files won't record when tasks were marked done. You can turn on logging with a line like #+STARTUP: logdone in the preamble of an org file to turn logging on for that file, or (setq org-log-done 'time) in your .emacs, to turn it on globally. To keep things neat, you might also want to use #+STARTUP: logdrawer or (setq org-log-into-drawer t) so your logs go in a LOGBOOK drawer. Hope that helps! Best, Richard
Re: [O] Large LaTeX project in single file or using publishing
Hi Jake, Jacob Gerlach writes: > I'm starting writing my thesis, for which I hope to remain in org-mode > rather than regular LaTeX. Others have already given you good advice, but since I am also writing my thesis in Org, I thought I would chime in. Like you, I felt a bit of trepidation when I was deciding whether to write in Org or LaTeX; I ultimately went with Org because (1) I find it much more pleasant to use 98% of the time; (2) I felt pretty confident I could plug the gaps in the other 2% with help from Org's awesome community; and (3) I wanted the option to export to other formats like HTML (though I haven't used this much so far). > I am working on adapting a thesis LaTeX template into org-mode. The > template is set up with a main.tex having several individual files > (chapters, appendices, etc) \include'd. > > I believe that I could parallel this using org's publishing mechanism. An > alternate approach would be to use one single file, since I can simply fold > chapters to focus my workflow. Like others, I would recommend the one-file approach. One advantage is that it makes it easier to compile parts of your document by themselves, since exporting a subtree from Org will inherit any #+LATEX_HEADER: declarations that apply to the whole document (unless you override them by setting the EXPORT_LATEX_HEADER property on the subtree). > My first concern is losing the ability to use internal links if I use > separate files. Another thought is compilation time if I use one file and > must always run pdflatex over the entire document. I'm sure there are > pitfalls either way that I'm not yet aware of. If you decide you need to go the multiple-files route, you can probably find a way to convert internal links into external ones. I half-recall someone posting code on this list to do this at some point... Here are a couple of other things to think about. When I decided to go with Org, I took a few steps to ensure that if I ever need to switch to pure LaTeX, I will be able to do so with minimal pain, just by exporting my Org document to .tex and going from there. (The big sticking point here for me was making sure I could produce human-readable, stable labels and refs for things like sections. See the variable org-latex-custom-id-as-label, which was introduced by a patch I wrote.) If you're worried about ever having to make the switch, I would recommend thinking ahead about each of the Org features you rely on and seeing how they get exported to LaTeX. If the default output is not something you'd want to edit by hand, consider either limiting your use of that feature, or customizing it so that it produces better output for you. Org provides a lot of ways to do the latter, from tweaking variables to export filters to custom export backends. Another thing to think ahead about is how you want to deal with your bibliography. People on this list use different approaches. I personally keep my reading tasks and notes in Org, then generate a .bib file from this as needed during compilation of my thesis. Others keep bibliographic information directly in .bib. I think you'll find there are good tools for either approach, but one or the other will probably fit better into your workflow, and may affect how easily you can export to other formats. Hope that's helpful! Best, Richard
Re: [O] Large LaTeX project in single file or using publishing
Marcin Borkowski writes: > Also, Richard's post made me realize why I prefer to stay with LaTeX: I > know it way better than Elisp (even though I'm making progress), and in > case of troubles, I can more easily deal with them in LaTeX (though > vertical positioning of things on the page - especially trying to > typeset on a grid - still beats me). Yes, that's a good point: if you already know LaTeX well, but are less comfortable hacking on Org, that would probably change my advice. I have accumulated about 600 lines of custom Elisp that is required to export my thesis from Org to LaTeX and PDF. (The bulk of this, 471 lines, is a custom export backend derived from the latex backend. It deals with exporting certain Org lists as non-standard LaTeX environments. Most of the rest deals with exporting my reading list to .bib and defining various custom link types, etc. to make the Org side more pleasant.) By contrast, I have only written about 100 lines in custom LaTeX style files (so far -- I might need to do more of this when it comes time to get the final styling right for filing my dissertation). I also rely on other packages from CTAN, but I don't have to maintain those myself. I'm no Elisp wizard, but I am now pretty familiar with Org exporter and I'm comfortable with Lisp in general. On the other hand, I tend to shy away from anything more complicated that \newcommand in the (La)TeX world. Best, Richard
Re: [O] Large LaTeX project in single file or using publishing
Jacob Gerlach writes: > On Fri, Nov 28, 2014 at 12:40 PM, Richard Lawrence > wrote: >> (The big sticking point here for me was making sure I could produce >> human-readable, stable labels and refs for things like sections. See >> the variable org-latex-custom-id-as-label, which was introduced by a >> patch I wrote.) > > This sounds helpful. I'm using ELPA (tracking maint?) and don't see > this variable. Was your patch applied to master? It was. I just checked -- sorry, I guess it's not in maint, even though it was applied a while ago. Looks like it will land in Org 8.3. Best, Richard OpenPGP Key ID: CF6FA646 Fingerprint: 9969 43E1 CF6F A646 (See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] Wrapping sections in html not possible
Hi Henry, Henry Hirsch writes: > So how can org mode support wrapping sections in html? > Especially for more complex cases where a section or > multiple sections will be wrapped in multiple divs. You can do this with an export filter or filters. See the "Advanced Configuration" section in the "Exporting" chapter of the manual. Here is a simple example to get you started: #+BEGIN_SRC elisp (defun my-html-headline-wrap-filter (text backend info) "Wrap headlines in div.jumbotron during export." (when (org-export-derived-backend-p backend 'html) (concat "" text ""))) (add-to-list 'org-export-filter-headline-functions 'my-html-headline-wrap-filter) #+END_SRC As written, this will wrap *all* sections (including their headline) in divs with the jumbotron class during HTML export. You probably want to do this for just some headlines, in just some documents. So, you'll need to add a test in my-html-headline-wrap-filter so that it only wraps the relevant headlines, and leaves others unchanged. Perhaps you can do this based on the title of the headline, or the presence of some tag or property. If you need help with this, just ask! Best, Richard
Re: [O] How do I set a class for a paragraph in HTML export?
Hi Marcin, Marcin Borkowski writes: > > I'd like to get something like this: > > Hello world > > What should I write in the Org file? Looking at org-html-paragraph, I'm > afraid that it's currently impossible. This works for me: -- #+ATTR_HTML: :class myclass This is a paragraph. -- That produces -- This is a paragraph. -- in the exported HTML. Best, Richard OpenPGP Key ID: CF6FA646 Fingerprint: 9969 43E1 CF6F A646 (See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)
Re: [O] Is it possible to use org-babel to deal with bibtex?
Hi Feng, Feng Shu writes: > I want to deal with my bibtex like this, is it possible? I'm not entirely sure what you're asking to do here. Your example looks like you want to store bibliography information in Org, and generate citations using Org syntax. This is possible, and plenty of people do it. See the org-bibtex library (included in the main Org distribution) for storing your bibliographic data in Org trees; see the ox-bibtex library (in contrib) for one way of generating citations using Org syntax. Here's my setup (which uses org-bibtex but not ox-bibtex): http://article.gmane.org/gmane.emacs.orgmode/86033/ You might also look into John Kitchin's org-ref library: https://github.com/jkitchin/jmax/blob/master/org/org-ref.org None of these options involve Babel, though; I'm not sure if you specifically wanted a Babel-based solution. Is there something more specific you're trying to do? Best, Richard
Re: [O] exporting zotxt or orgref links to HTML and ODF
Rasmus writes: > IMO we /need/ to add proper citation support to Org, preferably with a > real syntax rather than these link-"solutions" and with good backend > support (bibtex & Zotero for starters, I guess). > ... > /Proper/ citation support (not links) is, IMO, the last thing that is > missing for good academic publishing support. Although my home-baked solution presently works for me, I am inclined to agree. I've just had a glance at: http://pandoc.org/README.html#citations It looks to me like Pandoc has a quite general solution, and it also looks like Org could use Pandoc's citation syntax as-is. I would suggest borrowing this syntax as a starting point for building citation support into Org. #+BEGIN_QUOTE Citations go inside square brackets and are separated by semicolons. Each citation must have a key, composed of ‘@’ + the citation identifier from the database, and may optionally have a prefix, a locator, and a suffix. The citation key must begin with a letter or _, and may contain alphanumerics, _, and internal punctuation characters (:.#$%&-+?<>~/). Here are some examples: Blah blah [see @doe99, pp. 33-35; also @smith04, ch. 1]. Blah blah [@doe99, pp. 33-35, 38-39 and *passim*]. Blah blah [@smith04; @doe99]. A minus sign (-) before the @ will suppress mention of the author in the citation. This can be useful when the author is already mentioned in the text: Smith says blah [-@smith04]. You can also write an in-text citation, as follows: @smith04 says blah. @smith04 [p. 33] says blah. #+END_QUOTE Org does use single brackets and `@'-signs for other things (footnote markers, priorities, statistics cookies, inactive timestamps, list counters, inline export snippets -- I think that's it). But these should all be pretty easy to tell apart from citations using regular expressions, so I wouldn't expect parsing this syntax to present any difficulties. Does anyone have citation needs that this syntax doesn't cover? Using this syntax would also have the advantage that Pandoc can already parse it, which would reduce friction for Org users who convert their documents with Pandoc (and Pandoc users who need to deal with Org inputs). Since this seems like a significant contingent of Org users, that's something to consider. The bigger question is whether, in addition to a citation *syntax*, it would be a lot of work to add support for the various citation database formats, as well as the various output styles, and which ones to support. Best, Richard
Re: [O] exporting zotxt or orgref links to HTML and ODF
Rasmus writes: > BTW: Org has an almost-agnostic format for storing citation data via > org-bibtex.el. So perhaps it's easier to go from whatever to > org-bibtex-format and from there to ox-backend-format. I think that's how > pandoc does it as well. Well, that would certainly suit me, as I already store my citation data in org-bibtex format, and generate a .bib file as needed from it. I think Pandoc does something similar with YAML, either in-file or in a separate bibliography file. I do not know if the org-bibtex format will play nicely with non-BibTeX citation databases, though; can anyone speak to that? Best, Richard
[O] Citations, continued
Hi all, I wanted to continue the discussion that began in this thread about adding citation support to Org: http://thread.gmane.org/gmane.emacs.orgmode/94352/focus=94412 Here are some thoughts I have after reviewing that discussion: 1) Lots of people seem to need/want better support for citations in Org documents. Other projects (Pandoc among them) already have support for citations which is good enough that at least some people are using them to fill this perceived gap in Org's support. 2) There are at least several different backend reference database formats (BibTeX, Zotero, etc.) used by Orgsters. Not all such databases use human-readable keys. Org also has a nice internal format for storing reference information: org-bibtex. 3) There are also several different frontend solutions for making citations in Org documents (org-ref, various `home-brewed' solutions, raw LaTeX \cite commands, etc.). The variety here is at least in part due to our different requirements for the format of exported documents: e.g., some people only care about exporting to LaTeX, others need something that will work for HTML or ODT; some people need to specify pre- and post-text for citations; some people need to specify citation types. 4) Because individual Orgsters have widely varying needs, there is some disagreement about what `proper' citation support should look like. (Do we need new syntax, or can existing syntax be used? Which features need to be supported by Org, and which can be provided by external tools? etc.) It seems there are three distinct but related problems: - representing citations in Org documents - exporting citations in an Org document to a backend document format like LaTeX, ODT, or HTML - searching for and manipulating keys in a reference database from within Org, and otherwise fostering good communication between such a database and citations in Org documents Here's my personal opinion about how we might solve them. As for the first problem, I think a good case can be made for adding new syntax to Org to represent citations, instead of repurposing/extending existing syntax (most notably, the link syntax). Here's why. Citations are complicated, and it's clear that some sort of new syntax is needed to represent them. Even link-based solutions introduce new syntax `inside' the link syntax, such as using `::' to separate pre-text and post-text in a link description, as org-ref does. Thus, the issue is not *whether* there should be additional syntax, but just *how constrained* it should be. In particular, the question is whether we want to make citation syntax a subset of link syntax, or whether citations and links should be distinct types of syntactic elements. It seems to me that the needs of citation users are wide enough and complicated enough that it is worth shedding the constraints imposed by the link syntax. Eventually, packing all the representations we need for a general solution (citation type, pre- and post-text, suppressing author name, etc. etc.) into the link syntax will tend to make citations unreadable. Moreover, citations are not really links, even though it is often useful to treat them (or parts of them) as links. For example, a link can only point to one target; yet a single citation often points to multiple sources. And what if you need different pre- or post-text for different sources within the same citation, like ``See @Doe1999 for an overview; a more extensive discussion is in @Foobar2000''? Finally, it seems to me that Org strives to be a document format which is usable independently of any particular export format. This counts in favor of having citation syntax as a first-class citizen in Org; at present, Org documents can only contain citations through a combination of extensions and external tools. For these reasons, I would support a separate citation syntax, but one that can behave like a link when useful. For example, suppose we borrowed the Pandoc [ ... @key1 ...; ... @key2 ...] syntax. When point is on `@key1', C-c C-o could be bound to find the key in the reference database, or another useful action, depending on the reference database format. As I mentioned in the earlier thread, I think the Pandoc syntax is a good place to start, and I think it would be valuable to have the two syntaxes be compatible. But even Pandoc's citation syntax might not be general enough to satisfy everyone's needs, so the first step for introducing citation syntax to Org should be compiling a list of all the things such a syntax should represent. The other problems, I think, must wait until a stable citation syntax emerges -- export support in particular. (Using an existing syntax from another project could help ease the transition here: if people can export citations using an existing tool, they'll be able to switch to that syntax immediately, and use the external tool in the meantime while Org-internal support for it catches up.) I hope this
Re: [O] Citations, continued
Nicolas Goaziou writes: > Richard Lawrence writes: > >> ...so the first step for introducing citation syntax to Org should be >> compiling a list of all the things such a syntax should represent. > > See also > > <http://permalink.gmane.org/gmane.emacs.orgmode/72446> I reviewed that discussion, and also took a (relatively quick) look at the citation features provided by BibLaTeX and Citation Style Language processors. Here's what I've come up with for an initial list of requirements for citation syntax: A citation is a textual reference to one or more individual works, together with other information about those works, grouped together in a single place. Within a citation, each reference to an individual work needs to be capable of containing: 1) a database key that references the cited work 2) prefix / pre-text 3) suffix / post-text 4) references to page/chapter/section/whatever numbers and ranges. This is likely part of the prefix or suffix, but might be worth parsing separately for localization or link-following behavior. 5) a way of indicating backend-agnostic formatting properties. Examples of some properties users might want to specify are: - displaying only some fields (or suppressing some fields) from a reference record (e.g., journal, date, author) - indicating that the referenced works should *only* appear in the bibliography of the exported document (equivalent of LaTeX \nocite) Citations as a whole also need: 6) [@6] a way of indicating formatting properties for specific export backends. Examples of some properties that users might want to specify are: - a citation command to use for each individual reference (LaTeX; others?) - a multi-cite command to apply to all references together (LaTeX) - CSS or other styling class (HTML and derived backends; also ODT?) - properties describing how to treat emphasis and other formatting that cannot appear in plain text (ASCII and other plain text backends) In addition to the syntax of citations themselves, the Org document would also need to represent the following metadata to support citations: 7) [@7] a pointer to one or more backend reference databases, including in-document databases in org-bibtex format 8) a reference to a citation style or style file 9) a reference to a locale file 10) an indication of where the bibliography should be found in the exported document (equivalent to \printbibliography, etc. in LaTeX) I would like to know if others can think of anything else that should go on this list. I am particularly interested in hearing from people who use (or want to use) citations with non-LaTeX export backends, since I am least familiar with how citations work in those types of documents. I have also been working on a proposal for citation syntax that I think will meet these requirements, which I will post separately. Best, Richard
Re: [O] Citations, continued
Hi John and all, John Kitchin writes: >> As for the first problem, I think a good case can be made for adding new >> syntax to Org to represent citations, instead of repurposing/extending >> existing syntax (most notably, the link syntax). >> > > I think links are remarkable flexible, and solve most of the pre/post text > issue. You can use literal links if you don't want to see them collapsed. I agree; links *are* remarkably flexible. But I think that's actually sort of the problem in this case. It's easy to use the link syntax to implement a solution for citations that is `good enough' for 80+% of the use cases. That becomes a barrier to adopting something which better advances the goals of Org and its users. If I was implementing a citations solution just for my own Org documents, I would do it exactly the way org-ref does: use the link syntax, and put the pre- and post-text in the description, with a separator that's easy to remember, like [[cite:Doe1999][See::for an overview]] or more realistically: [[cite:Doe1999][Cf. a recent discussion in::, on sluicing.]] Does this work? Yes. Is it easy to implement on top of the existing features? Yes. Again, for my own personal use, this is exactly what I would do. But I would not want to see this syntax canonized as the official Org citation syntax. It feels like a hack, not a proper solution, and it definitely strikes me as less readable than [Cf. a recent discussion in @Doe1999, on sluicing.] especially if you have the default setup, where the URLS of links that have a description part are hidden. My point is not that the link syntax *can't* do enough. Rather, my point is that citations are conceptually distinct from links, and if we are going to adopt an official syntax for them, that syntax should reflect this conceptual distinction. This is better for document authors, because it is less work for us. It gives us the right tool for this particular job, instead of re-purposing a tool that, despite its power, is designed for a different job. It is thus better for the Org community as a whole. >> Moreover, citations are not really links, even though it is often useful >> to treat them (or parts of them) as links. For example, a link can only >> point to one target; yet a single citation often points to multiple >> sources. And what if you need different pre- or post-text for different >> sources within the same citation, like ``See @Doe1999 for an overview; a >> more extensive discussion is in @Foobar2000''? >> > > An org link can point to many targets. An org-mode link executes code, > which can give you many options to consider. In your example, I would > consider that two citations. Even a single cite link in org-ref considers > each comma-separated key a separate clickable entity; the code figures out > which key you clicked on, and gives you several options of what to do with > it, like open the entry, the pdf, etc... which it figures out how to do > based on the key. This is a good example of how extending the link syntax to citations will end up obscuring important conceptual distinctions, which makes more work for the user. Normally, when you click on a link (or follow it with C-c C-o), you don't have to pay attention to /where/ on the link you click. By making citation keys significant sub-parts of a link, you force the user to always pay attention to this for every link, at least until he or she determines whether the link is a citation link or a `real' link. (If that doesn't seem like a big deal, consider how it would affect someone who edits Org documents using a screen reader.) A link has two significant parts: a URL, and a description. A citation potentially has at least three significant parts for each work it references (key, pre-text and post-text). I am certainly not opposed to having parts of citations exhibit link-like behavior, though. I think it would be great if one could `follow' each reference key within a citation to do something useful with it, as org-ref does. I just think the link syntax is not the right underlying syntax to express this. It does not contain enough significant parts -- and giving it more significant parts makes links into something else. > How does the pandoc syntax handle different link types. e.g. the 40ish > different types supported by biblatex? Links manage this easily, and with > the export framework, you can convert them to all kinds of other formats. > It looks to me like the pandoc syntax is too simple for that. > ... > I think you need a citation type for the backend, because you often need > more than one type in a document, e.g. the regular citations, sometimes a > citation number, author or year. Yes, I agree here. As far as I can tell, the Pandoc syntax does not handle different types of citations within the same document, except in a limited way, via the distinctions between Smith says blah [@Smith99, p. 3]. @Smith99 [p. 3] say blah. Smith once thought
Re: [O] Citations, continued
t...@tsdye.com (Thomas S. Dye) writes: > You and others are advocating a separate syntax for links and citations, > which might indeed be the way to go. I can see it being much nicer than > the current state of affairs with Org mode links. The downside is that > it will mean learning another set of rules, in addition to the existing > rules for links. Yes, I agree, and I see the import of this concern. Links and citations have enough similarities that some more generalized syntax could probably cover them both, as you suggest below. The main upside, as I see it, of adopting a totally different syntax for citations is that we have the option to adopt a syntax that is already known to be good enough (for some set of uses) and to work with other tools (like Pandoc). But this is a `merely practical' concern and maybe does not outweight the considerations above. > Several years ago, Samuel Wales suggested an extensible syntax example > using link features > (https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html). > At the time it seemed to me that this was a Lisp-y approach because it > solved particular problems by generalizing or abstracting a language > feature to include particulars that had previously fallen outside its > ken. I wanted something like this while I was working on implementing > citation links for export to LaTeX. > > Would it be feasible to generalize Org mode's link syntax, or make it > extensible, so the overlap of link with citation is complete? This is an interesting idea! I think the minimal change that would be necessary would be to allow the new extended links (call them `elinks' for short) to be defined in such a way that they can have varying numbers of significant parts, depending on the type. An elink definition for a given type would specify a number and order of parts. All elinks would use the same syntax to delimit the parts. To keep things simple and more or less consistent with the existing syntax, we could just surround each part with square brackets, and assume that only the first part is required. Thus, the relevant definitions could look like: href: URL DESCRIPTION cite: KEY PRE-TEXT POST-TEXT with examples like: [href: [http://www.google.com]] [href: [http://www.google.com][Evil search engine]] [cite: [Smith99]] [cite: [Smith99][Cf.]] [cite: [Smith99][Cf.][for a discussion]] though this doesn't quite solve the readability problem with having optional pre and post text appear after the key. In theory, this syntax could even allow complicated nestings: multi-cite: CITE-ELINK ... [multi-cite: [cite: [Smith99]] [cite: [Doe2000]] [cite: [Foobar2014][a summary appears in]] [cite: [Baz2014][][which is available at [href: [http://baz.org though that might quickly get unwieldy (especially for non-Lispers). :) Link handlers would become functions that accept one argument plus a &rest list, and the choice of link handler would dispatch on the type. An alternative to the brackets would be to use something like plist syntax for the optional arguments (as Samuel originally suggested and Rasmus has echoed). Links would really just start to look like Lisp function calls. I'm just spitballing here; not sure I'd ultimately endorse something like this, but I think it's worthwhile to explore the question of how link and citation syntax could usefully be generalized. Best, Richard
Re: [O] Citations, continued
Hi Rasmus and all,
Rasmus writes:
> Richard Lawrence writes:
>> Within a citation, each reference to an individual work needs to be
>> capable of containing:
>> 1) a database key that references the cited work
>> 2) prefix / pre-text
>> 3) suffix / post-text
>> 4) references to page/chapter/section/whatever numbers and ranges.
>> This is likely part of the prefix or suffix, but might be worth
>> parsing separately for localization or link-following behavior.
>> 5) a way of indicating backend-agnostic formatting properties.
>> Examples of some properties users might want to specify are:
>
>> - displaying only some fields (or suppressing some fields) from a
>>reference record (e.g., journal, date, author)
>
> Would this not be properties of the bibliography and not the citation?
No, I mean things that can vary from one citation to the next -- like
what you'd write in LaTeX as
\citet{Doe99} once thought foo, but in his \citeyear{Doe2014}, he
revises his position to bar.
The second citation should only display the year, since the author's
name has already been mentioned in the sentence. This type of
formatting information would be nice to represent regardless of export
backend.
>> Citations as a whole also need:
>> 6) [@6] a way of indicating formatting properties for specific export
>> backends.
>
> I think the idea would be /not/ to have to consider specific backends. If
> you want special properties (say bold) for HTML could it not be solved by
> a macro or a filter? Probably I'm misunderstanding.
I agree that we should probably want to minimize and segregate
backend-specific formatting information, but it is inevitable that
someone will need this ability; and I'm a `provide reasonable defaults,
but also an escape hatch when you need it' kind of guy.
The things I have in mind are things like telling the LaTeX backend to
use a particular citation command for this citation, or the HTML backend
to use/add a particular CSS class. Maybe this could be done with macros
or filters, but I think that would prove complicated for all but the
simplest cases, since citations have argument structure that filters
might not necessarily `see'.
>> In addition to the syntax of citations themselves, the Org document
>> would also need to represent the following metadata to support
>> citations:
>> 7) [@7] a pointer to one or more backend reference databases,
>> including in-document databases in org-bibtex format
>
> This would be a huge win.
>
>> 8) a reference to a citation style or style file
>
> How does this work outside of LaTeX?
Well, Pandoc for example processes citations using the citeproc-hs
implementation of the Citation Style Language, which is an XML format
that allows describing how citations and bibliographies should be
formatted. Thus, for example, you could tell Pandoc to process your
citations in APA style, or any of the other styles in this repo:
https://www.zotero.org/styles
CSL is an XML format, and I shudder to think about implementing it in
Elisp, but that's how its done. In fact, Pandoc uses this even for
LaTeX output, rather than trying to map citations to the various \cite
commands.
>> 9) a reference to a locale file
>
> There's already a #+BIBLIOGRAPHY or #+REFERENCES in ox-bibtex.el. But
> it's quite limited.
Yes, I think we should leverage this but modify its syntax a bit.
Best,
Richard
Re: [O] Citations, continued
Hi all,
Here is the citation syntax proposal I have mentioned in a couple of
posts now. I have attached it as an Org document for better
readability, and also reproduced the text below. Let me know what you
think!
Best,
Richard
#+TITLE: A Proposal for Org citation syntax
#+AUTHOR: Richard Lawrence
* Introduction
In brief, the proposal is:
1. Use the Pandoc syntax for basic, inline citations.
2. Extend the Pandoc syntax modestly to accommodate backend-agnostic
formatting of inline citations.
3. Also allow non-inline citation definitions, with a syntax
comparable to non-inline footnotes, to accommodate
backend-specific formatting.
Basing this proposal on the Pandoc syntax is a `merely practical'
choice. It might not be the most Org-like, and it might produce too
much conceptual divergence between citations and links. But it is a
syntax that is already well-tested and known to work elsewhere, and
which has easily-scriptable tools for processing it (namely, Pandoc's
own), which Org users could rely on in the meantime, while Org's own
implementation of this syntax catches up.
Beyond the features provided by the basic Pandoc syntax, I have tried
to ensure that the other features are as Org-like as possible, are
already in use in Org documents, and (I hope) could be implemented
with minimal work.
* Citation syntax
(I repeat the list of requirements I posted earlier here, for easy
reference; so far, I don't think anyone has suggested we need any
others.)
A citation is a textual reference to one or more individual works,
together with other information about those works, grouped together in
a single place.
Within a citation, each reference to an individual work needs to be
capable of containing:
1. a database key that references the cited work
2. prefix / pre-text
3. suffix / post-text
4. references to page/chapter/section/whatever numbers and ranges.
This is likely part of the prefix or suffix, but might be worth
parsing separately for localization or link-following behavior.
5. a way of indicating backend-agnostic formatting properties.
Examples of some properties users might want to specify are:
- displaying only some fields (or suppressing some fields) from a
reference record (e.g., journal, date, author)
- indicating that the referenced works should *only* appear in
the bibliography of the exported document (equivalent of LaTeX
\nocite)
Citations as a whole also need:
6. [@6] a way of indicating formatting properties for specific export
backends. Examples of some properties that users might want to
specify are:
- a citation command to use for each individual reference (LaTeX;
others?)
- a multi-cite command to apply to all references together
(LaTeX)
- CSS or other styling class (HTML and derived backends; also
ODT?)
- properties describing how to treat emphasis and other
formatting that cannot appear in plain text (ASCII and other
plain text backends)
** Starting point
I assume, to start, the basic Pandoc [ ... @key1 ...; ... @key2 ...]
syntax for inline citations, documented
[[http://pandoc.org/README.html#citations][here]]. This defines a syntax
for inline citations that allows grouping multiple individual
references together between brackets, with semicolons as separators.
Previous discussions have suggested beginning citation definitions
with a tag, like [cite: ...] or [citation: ...], by analogy with
footnotes and links. As far as I can see, the tag doesn't really
provide any advantages for inline citations, and is just unnecessary
markup. This is because the syntax of citations is (or should be)
more constrained than footnotes or links; a citation is already
recognizable, and parseable as such, by the required presence of a
reference key. The tag would also immediately break compatibility
with the basic Pandoc syntax if it were required for inline citation
definitions, a result which I am trying to avoid in this proposal.
A syntax for /non-inline/ citation definitions, however, comparable to
the syntax for footnotes, would make good use of such a tag. This is
what I propose below.
** Backend-agnostic formatting properties
*** Selecting specific fields
Selecting specific fields to display could be done by appending field
names to cite keys after colons, much like Org tags:
#+BEGIN_QUOTE
[See @Doe99, pp. 34--45; also @Doe00:year, section 6]
[See their article in @Doe99:journal:year.]
#+END_QUOTE
Note that this would make for an extension of Pandoc syntax. This
extension is not a strict superset, since Pandoc allows internal `:'
characters in cite keys, and thus would treat `@Doe99:journal:year' as
a single key, rather than treating the key as ending at the first
colon, with other data afterward. (More compatible but uglier
alternatives for the field selector include `!', `{', `}', and `^'.
If an alternative is desired, I suggest `@Doe
Re: [O] Citations, continued
Hi Rasmus and all, Thanks for your comments! Rasmus writes: >> ** Backend-agnostic formatting properties >> *** Selecting specific fields >> Selecting specific fields to display could be done by appending field >> names to cite keys after colons, much like Org tags: >> #+BEGIN_QUOTE >> [See @Doe99, pp. 34--45; also @Doe00:year, section 6] >> >> [See their article in @Doe99:journal:year.] >> #+END_QUOTE > > First, I think we should use @key for inline and (@key) for parenthesis > expressions. This give us two short keys. [@Key ⋯] can be reserved for > complicated references. That sounds fine to me. I think you may be using `inline' differently than me, though: do you mean `author's name appears in the text (not in parentheses)'? (I was using it to talk about where the citation definition appears in the document, not where the author's name appears relative to parentheses.) > I don't like "@Doe99:journal:year". It's too unlike existing syntax. I agree it's a little clunky, but I think most of the time there would just be one selector. I was thinking of this on analogy with heading properties and tags...is there a better existing syntax to refer to a property value? > Rather, I'd just introduce types as hinted previously, [@Doe99 :type > my-journal-year-type]. Org can provide as many predefined :type as we > care for, and let the user define the rest as necessary. I don't like this, because it seems like a lot more work for me as a user to achieve something that should be simple, and it trades specifying /what/ data I want for describing it more indirectly. Suppose I'm writing a document, and I know I just want to reference the journal and year of a particular publication, in that order. Being a studious keeper of my org-bibtex database, I already know that these fields are called "journal" and "year". But if, in addition to reference database field names, I have to remember names for /types/ of /combinations/ of field names, that's too much. I'll end up taking endless trips to the manual to figure out which type I need in this case. Do I need :type journal-before-year? :type journal-and-year? etc. This feels a bit too much like having to remember (or look up) all the different LaTeX citation commands. I expect that many of the common cases would have the same name, but then I still have to remember which of my uses are `common'. And [@Doe99:year] is less verbose than [@Doe99 :type year]. What about just separating the field names off, as keys? Like: [See Doe's review @Doe99 :journal :year] >> When specific fields are requested, ONLY data from those fields should >> appear in the exported document. Backends would choose how to export >> these citations based on the selected fields. > > What happens when a field is undefined? I guess I would suggest the same thing as happens in LaTeX: you get a nice, bold "??" in the output where the missing data should be. >> *** Non-cited works that should appear in the bibliography >> A special field selector `:nocite' would be one way to achieve >> citations that, for whatever reason, should appear in the Org source >> and in the exported bibliography, but should not appear in the >> exported text where they are placed. This would allow referencing >> them at relevant places in the document, like: >> #+BEGIN_QUOTE >> Smith said a lot of things, but no one can remember what they >> were. [@Smith79:nocite] >> #+END_QUOTE > > I think R-markdown uses something like [-@Smith79]. Again, I don't like > the [@key:nocite]. Doesn't [-@Smith79] mean something different, namely, "cite @Smith79 without the author name"? It produces output like: "(1979)". The idea is that the :nocite selector produces no output, like LaTeX's \nocite. I don't know how important it is to have this, though. >> *** Backend-specific formatting >> In general, it would be nice to avoid formatting properties which are >> specific to a particular export backend when a backend-agnostic >> solution is available, but some backend-specific formatting needs are >> probably inevitable, so we need a syntax for specifying them. >> >> Another advantage of the non-inline citation syntax is that it would >> allow using the existing #+ATTR_BACKEND syntax to specify >> backend-specific formatting properties, since the citation definitions >> would be block-level elements: >> #+BEGIN_QUOTE >> * Citations >> >> #+ATTR_LATEX: :command citet >> #+ATTR_HTML: :class my-citation >> [cite:1] See @Doe99, pp. 34--45; @Foobar2000, ch.1. >> #+END_QUOTE > > Why not. Since footnote-definition is a greater element it /does/ take > affiliated keywords, but I have never seen this used. Right, that's the point here...(were you disagreeing?) > For inline maybe something like this: > [@Key :type_html my-citation :type_latex citet] Actually, this is a lot like the syntax I was thinking about for the inline case, but in the end I thought it was too complicated and new to be worth
Re: [O] Citations, continued
Hi Erik and all, Erik Hetzner writes: > I am really, really glad to see people discussing citations in > org-mode. But I have some concerns about this proposal. > > Before extensions are proposed to the pandoc format, I think it is > important to understand how flexible the combination of pandoc, and > what citeproc provides. I believe that pandoc can cover most of what > you want. > I also believe it would be a mistake to start from the idea of a > pandoc-style citation syntax that deviates from pandoc. Better instead > to start from what pandoc does now and find out what isn’t working for > org-mode users before extending pandoc, especially in ways that are > not compatible with pandoc. Actually, I totally agree. For my own use, I would be completely happy with just using the Pandoc syntax for citations in Org, without any modifications. The only reason I proposed anything else was that it seemed like other people already know that they need more than the Pandoc syntax provides. I think the main realistic cases are those where, in LaTeX, you'd use commands like \citetitle, \citedate, or \citejournal -- citation commands that pull in just a particular field from the reference, because that is what the context around the citation requires. I don't see a way to do that in the Pandoc syntax. (But am I missing something?) Hence my proposed field-selectors extension. Personally, I need commands like these so little that I am happy to do without them. So maybe my proposal was a bit hasty. Could we hear from other people about how badly they need what such commands provide? > And if extensions are proposed, it would be best to propose them on > the pandoc-discuss mailing list. It would be wonderful for users if > the syntax in pandoc-markdown and org-mode could stay aligned. Yes, I again totally agree. If people here settle on a syntax that is close, but not quite the same as, Pandoc's, I will certainly do that. Best, Richard
Re: [O] Citations, continued
Hi Erik and all, Erik Hetzner writes: > On Mon, 2 Feb 2015 at 20:41:06 PST, > Richard Lawrence wrote: >> The only reason I proposed anything else was that it seemed like other >> people already know that they need more than the Pandoc syntax provides. >> I think the main realistic cases are those where, in LaTeX, you'd use >> commands like \citetitle, \citedate, or \citejournal -- citation >> commands that pull in just a particular field from the reference, >> because that is what the context around the citation requires. I don't >> see a way to do that in the Pandoc syntax. (But am I missing >> something?) Hence my proposed field-selectors extension. > > If this is needed (and I still have a hard time seeing the use cases, > but I am not an academic) perhaps it could mimic the -@doe (suppress > author) syntax already used in pandoc (e.g. +title@doe). But > citeproc-js/hs only support suppress author or author only, so these > would not work in a pandoc export, nor any other that might depend on > citeproc-js. Yes. I'll have to take a look at the Pandoc citeproc code and see how easy it would be to add support for something like this. If there are Org people that need citation types that select specific fields, I imagine there are Pandoc people who do as well. The ideal would be if citeproc would take care of proper formatting of all such citation types, given just an ordered list of the fields that should appear. I don't know if CSL supports this, though; do you? The +title@doe syntax would work, but I don't personally think that's any easier to read (or parse) than @doe:title, or @doe+title (which actually is another option I had thought of, given the +/- syntax for tag matching in Org). > Again, this is great. I really do appreciate your getting this > proposal out there. I hope that I can finish porting my pandoc parser > to elisp within a week or so, so we can have an implementation to > start with. Thanks for taking the first step on this! I had a brief look at your parser code when you posted it the other day. I don't know if you are familiar with Org's parser, in org-element.el. The important thing will be to have a parser for citations return a data structure in the format used by org-element. In the language of org-element, I think a citation is an object (as opposed to an element). I am somewhat (but not super-) familiar with org-element and Elisp, so if you want some help with this, let me know. Best, Richard
Re: [O] Citations, continued
Hi Eric and all, Eric S Fraga writes: > On Tuesday, 3 Feb 2015 at 11:35, Rasmus wrote: > I'm enjoying following this thread. I look forward to the community > converging on some solution. Me too! > For me, any solution will likely do just fine as my use of citations is > quite straightforward. I seldom, if ever, have pre or post text but I > do use a couple of alternative citation types (author, year; year only). Just to clarify: these are only `alternative' citation types if you're not using a citation style where they are the default types, like Chicago, right? I assume you are using a numeric style, like ACM? (This raises an interesting question, actually: what does the Pandoc syntax do with author suppression for numeric citation styles? Does [-@Smith99] still output the year, or does it produce the same numeric reference as [@Smith99]?) > I have only one suggestion to keep in mind: > What happens when a field is undefined? >>> >>> I guess I would suggest the same thing as happens in LaTeX: you get a >>> nice, bold "??" in the output where the missing data should be. >> >> Or better, throw an error. > > A *warning* would be better than an error, i.e. something that does > indicate a problem but that doesn't stop the export completing. LaTeX > does this (as noted above). Agreed. Something easily greppable, but not process-stopping. > Interestingly, I have just had a paper accepted for publication which > was written *entirely* in org. I used the [[cite:fraga-etal-2014]] > approach for handling citations. The paper made significant use of > babel to have everything in one place (data, code, results). Very > pleasing and painless experience. I did have to resort to LaTeX > specific commands a few times but mostly for the preamble (title, > authors, etc.). Cool! Best, Richard
Re: [O] Citations, continued
Erik Hetzner writes: >> The ideal would be if citeproc would take care of proper formatting >> of all such citation types, given just an ordered list of the fields >> that should appear. I don't know if CSL supports this, though; do >> you? > > I’m not entirely sure what you mean. The authors of citeproc have come > up with a huge number of styles which seem to satisfy people’s needs. > What appears in the in-text citation is configurable, see: > > > http://citationstyles.org/downloads/specification-csl101-20120903.html#citation Sorry, I wasn't clear. What I mean is, is there a way to tell an implementation of CSL "hey, this particular citation right here should only contain the author (or year, or journal...) of the referenced work, even though the citation style for this document is (e.g.) numeric?" The link you referenced makes it seem like the element describes how citations should be formatted for a whole document, but maybe I don't understand it. (Can there be multiple citation formatting styles specified by a CSL stylesheet? or multiple stylesheets used to format the citations in a document?) The idea is, a citation like "As Doe says in @Doe99:title, ..." should render like "As Doe says in /The Title/, ...", not like "As Doe says in Doe (1999), ...", even if "@Doe99" citations in the document generally render like the latter. I suspect this must be possible with citeproc/CSL, but I don't actually know, since Pandoc doesn't provide syntax for this kind of case. Best, Richard
Re: [O] [bug?] Link to be exported only in HTML
Hi Sebastien, Sebastien Vauban writes: > #+TITLE: ECM Links for HTML only > > * Test > > If I want to include a link (GPL logo, here) to the HTML export, I should put > it > in a block, right? > > #+begin_html > [[http://opensource.org/licenses/GPL-3.0][http://img.shields.io/:license-gpl-blue.svg]] > #+end_html > > Well, that does not work: the link is not rendered as a link; it's copied > "verbatim". > > OTOH, the link on its own is correctly exported to HTML: > > [[http://opensource.org/licenses/GPL-3.0][http://img.shields.io/:license-gpl-blue.svg]] > > ... but it fails to be exported to LaTeX (causing a "TeX capacity exceeded" > error), reason why I must not have the link when exporting to LaTeX. > > Is this a bug? Is there an alternative? As far as I understand, this is not a bug: #+begin_html ... #+end_html is for writing literal HTML that will be included in HTML output. Thus, if you only care about the link appearing in HTML output, just use literal HTML: #+begin_html http://opensource.org/licenses/GPL-3.0";>http://img.shields.io/:license-gpl-blue.svg";> #+end_html (That is hand-translated...you should check whether it is the right HTML for your document.) Best, Richard
Re: [O] Citations, continued
Hi Nicolas, Nicolas Goaziou writes: > Also, AFAIU, the syntax for valid citations is not defined explicitly so > far. For example, I don't think it was discussed if any subset of Org > objects (e.g., macros or bold text) is allowed in a citation. This is a good question that, as you say, deserves more discussion. I am not sure, but I am *thinking* that inline citations are objects (not elements) that can contain some other objects. Specifically I think we need the following categories, all of which would be objects: - key - prefix / pre-text - suffix / post-text - locator - individual citation - bracketed citation - unbracketed citation These should have a grammar like the following, based on my (reverse-engineered) understanding of the Pandoc syntax for citations: - A bracketed citation is a list of one or more individual citations, separated by ';' if there are two or more, and surrounded by '[' ']' - An individual citation is formatted like: PREFIX KEY LOCATOR SUFFIX The key is obligatory, and the prefix, locator and suffix are optional. - A key optionally begins with '-', and obligatorily contains '@' followed by a string of charcters which begins with a letter or '_', and may contain alphanumeric characters and the following internal punctuation characters: :.#$%&-+?<>~/ - A prefix or suffix is a text object (that may contain markup like emphasis or macros) - An unbracketed citation consists of a key, optionally followed by a locator which is enclosed in '[' ']' I am not sure about the syntax of locators. In particular, I do not know if they should allow internal markup, I do not know if they have an internal syntax, and I do not know if a comma is required to separate them from a key in a bracketed citation. Best, Richard
Re: [O] Citations, continued
Erik Hetzner writes: > On Wed, 4 Feb 2015 at 07:59:46 PST, > Richard Lawrence wrote: >> The idea is, a citation like "As Doe says in @Doe99:title, ..." should >> render like "As Doe says in /The Title/, ...", not like "As Doe says in >> Doe (1999), ...", even if "@Doe99" citations in the document generally >> render like the latter. I suspect this must be possible with >> citeproc/CSL, but I don't actually know, since Pandoc doesn't provide >> syntax for this kind of case. > It’s not supported in existing citeproc implementations, but I think > it would be possible to support something like this. On the other > hand, this is also something that is easily done by hand, so I don’t > know if it’s worth the trouble. Actually, I've changed my mind; it occurs to me that there is a good argument for /not/ adopting this syntax. First of all, the cases it is meant to cover are not really cases of /citations/ so much as cases of /indirections/. Writing "@Doe99:title" instead of the title of the work is just to aid the author; it does not produce enough information in the output to let the reader look up the referenced work, so it isn't really a citation. Second, it would be difficult to get the formatting of these selected fields right in general. Should titles be emphasized, or put in quotes? When do we insert commas between fields? etc. Instead, I think Org should provide functions that provide the same aid to document authors without the indirection, functions like: - org-get-fields-from-citation - org-insert-fields-from-citation-at-point - org-replace-citation-at-point-with-fields These would take care of looking up the desired data in the reference database and inserting it into the Org document, where the author could format it as desired. Furthermore, if someone *really* needs the indirection, I think it would be relatively straightforward to implement as an export filter, especially if the above functions are provided. This case should be uncommon enough that users can be expected to handle it themselves. So, unless someone thinks it's really important to find a workable solution, I hereby drop this (the `field selectors') part of my proposal. That means citations in the inline case can remain fully compatible with Pandoc. Best, Richard
[O] Bug: New keywords for org-agenda-sorting-strategy give "wrong type argument" error [8.0 (release_8.0-1-g5ef07d @ /home/rwl/src/org-mode/lisp/)]
Dear Org team,
I think I have found a bug related to the new agenda sorting strategies.
When I set:
(setq org-agenda-sorting-strategy '(deadline-up))
; or deadline-down, or timestamp-up/down, or scheduled-up/down, etc.
; the same problem occurs using the '((agenda deadline-up) ...) form
it results in the following error:
"org-entries-lessp: Wrong type argument: stringp, nil"
and no entries are displayed in the agenda.
Some crude debugging on my part suggests that this error is triggered
when org-entries-lessp tries to compare the "now" line (i.e., the agenda
item generated from org-agenda-current-time-string) against another
item.
I think the problem is actually in org-cmp-ts: string-match doesn't like
getting nil as an argument. So maybe the problem is that the "now" line
doesn't have the text properties corresponding to deadlines, timestamps,
etc., such that get-text-property is returning nil?
Hope that's helpful! Please let me know if I can help with further
debugging.
Best,
Richard
Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1)
of 2013-01-08 on murphy, modified by Debian
Package: Org-mode version 8.0 (release_8.0-1-g5ef07d @
/home/rwl/src/org-mode/lisp/)
current state:
==
(setq
org-todo-keyword-faces '(("WAITING" . "orange"))
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-agenda-custom-commands '(("r" "Reading list" tags-todo "+reading") ("S" .
"STUDY context searches") ("Sf" todo "FIND") ("Sp" todo "PRINT")
("Sr" todo "READ") ("Sn" todo "NOTES") ("St"
tags-todo "+STUDY") ("P" tags-todo "+CAMPUS") ("D" tags-todo "+COMPUTER")
("H" tags-todo "+HOME") ("E" tags-todo
"ERRAND|BUY") ("F" tags "+FREETIME") ("X" tags-todo "+EXERCISE"))
org-agenda-files '("~/Documents/philosophy/dissertation/tasks.org"
"~/org/school.org" "~/org/life.org" "~/org/beer.org" "~/org/food.org")
org-metaup-hook '(org-babel-load-in-session-maybe)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-footnote-auto-label 'confirm
org-list-empty-line-terminates-plain-lists t
org-agenda-sorting-strategy '(deadline-up) ;; and others
org-capture-before-finalize-hook '((lambda nil (add-bibliographic-data)))
org-export-preprocess-hook '(ignoreheading-org-export-preprocess-hook)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-shell-link-function 'yes-or-no-p
org-todo-keywords '((sequence "TODO" "INPROGRESS" "WAITING" "|" "DONE"
"CANCELED") (sequence "FIND" "PRINT" "READ" "NOTES" "|" "DONE" "CANCELED")
(sequence "PRIMARY" "SECONDARY" "|" "BOTTLED"))
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-hide-inline-tasks org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-agenda-span 1
org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook
change-major-mode-hook org-show-block-all append local] 5]
#[nil "\300\301\302\303\304$\207" [org-add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-refile-targets '((nil :maxlevel . 4))
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-refile-use-outline-path t
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-occur-hook '(org-first-headline-recenter)
org-from-is-user-regexp "\\"
org-mobile-directory "/media/nexus/mobileorg"
org-agenda-cmp-user-defined 'org-agenda-cmp-by-deadline
org-modules '(org-habit org-w3m org-bbdb org-bibtex org-docview org-gnus
org-info org-irc org-mhe org-rmail)
org-metadown-hook '(org-babel-pop-to-session-maybe)
)
Re: [O] Bug: New keywords for org-agenda-sorting-strategy give "wrong type argument" error [8.0 (release_8.0-1-g5ef07d @ /home/rwl/src/org-mode/lisp/)]
Indeed, the following patch seems to fix the issue for me, though I don't know enough about the code to know if this is clean/elegant/general enough: diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 631c6d0..c53c8c8 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -6989,9 +6989,9 @@ or \"timestamp_ia\", compare within each of these type. When TYPE is the empty string, compare all timestamps without respect of their type." (let* ((def (if org-sort-agenda-notime-is-late 9901 -1)) -(ta (or (and (string-match type (get-text-property 1 'type a)) +(ta (or (and (string-match type (or (get-text-property 1 'type a) "")) (get-text-property 1 'ts-date a)) def)) -(tb (or (and (string-match type (get-text-property 1 'type b)) +(tb (or (and (string-match type (or (get-text-property 1 'type b) "")) (get-text-property 1 'ts-date b)) def))) (cond ((< ta tb) -1) ((< tb ta) +1 -- Best, Richard
Re: [O] Can't Sort with New, 8.0 Sort Methods
Hi Nick, I filed a bug report for this issue here: http://article.gmane.org/gmane.emacs.orgmode/70890 And mentioned a fix that works for me here: http://article.gmane.org/gmane.emacs.orgmode/70893 You could try my fix in the meantime, and let the list know if it helps. Best, Richard
[O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]
Hi Org maintainers,
I've been trying to get iCalendar export working with my agenda files
again since upgrading to 8.0, and I've found that footnotes break the
agenda export to .ics. The problem is that a plain text version of the
footnotes in the file ends up in the output "floating loose"---not
wrapped by VEVENT tags or any other tags---resulting in an unparseable
.ics file (at least according to Google Calendar).
Here's a sample Org file to illustrate:
* Entry 1
This entry has some text with an inline footnote[fn:: which isn't
very interesting]
* Entry 2
This entry has some text with an external footnote[fn:1]
* Appointment with Someone
<2013-04-20 Sat 15:00>
* Footnotes
[fn:1] which still isn't very interesting
And here's the output I get when I export this
(via C-c a < a C-x C-w /tmp/test.ics):
BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:OrgMode
PRODID:-//Richard Lawrence//Emacs with Org mode//EN
X-WR-TIMEZONE:America/Los_Angeles
X-WR-CALDESC:
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20130420T211153Z
UID:TS1-5b8f14ac-d380-437f-88dd-4ed0a4ebacb9
DTSTART:20130420T15
DTEND:20130420T17
SUMMARY:Appointment with Someone
DESCRIPTION:<2013-04-20 Sat 15:00>
CATEGORIES:test
END:VEVENT
Footnotes
─
[1] which isn't very interesting
[2] which still isn't very interesting
END:VCALENDAR
Note that I still seem to get the behavior when I restrict the export to
headlines matching certain tags. In that case, even footnotes from
entries which should not be exported end up in the output, which seems
pretty strange.
It doesn't make much sense to me to have footnotes when exporting to a
calendar format, so is there any way to suppress exporting footnotes in
this case?
Thanks!
Best,
Richard
Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1)
of 2013-01-08 on murphy, modified by Debian
Package: Org-mode version 8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)
current state:
==
(setq
org-todo-keyword-faces '(("WAITING" . "orange"))
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-agenda-custom-commands '(("r" "Reading list" tags-todo "+reading") ("S" .
"STUDY context searches") ("Sf" todo "FIND") ("Sp" todo "PRINT")
("Sr" todo "READ") ("Sn" todo "NOTES") ("St"
tags-todo "+STUDY") ("P" tags-todo "+CAMPUS") ("D" tags-todo "+COMPUTER")
("H" tags-todo "+HOME") ("E" tags-todo
"ERRAND|BUY") ("F" tags "+FREETIME") ("X" tags-todo "+EXERCISE")
("Z" "Export to iCalendar file" tags
"event|appointment" nil
("~/Documents/website/public_html/lib/attachments/calendar.ics"))
)
org-agenda-files '("~/Documents/philosophy/dissertation/tasks.org"
"~/org/school.org" "~/org/life.org" "~/org/beer.org" "~/org/food.org")
org-metaup-hook '(org-babel-load-in-session-maybe)
org-capture-templates '(("s" "School")
("st" "Todo" entry (file+olp "~/org/school.org"
"Tasks" "Spring 2013") (file "~/org/templates/todo.txt") :prepend t)
("sy" "Todo (from active region or kill ring)" entry
(file+olp "~/org/school.org" "Tasks" "Spring 2013")
(file "~/org/templates/todo-with-yank.txt") :prepend
t)
("sl" "Todo (with link)" entry (file+olp
"~/org/school.org" "Tasks" "Spring 2013") (file
"~/org/templates/todo-with-link.txt")
:prepend t)
("se" "Event" entry (file+headline "~/org/school.org"
"Events") (file "~/org/templates/event.txt") :prepend t)
("sr" "Reading" entry (file+olp "~/org/school.org"
"Reading list") (file "~/org/templates/reading.txt") :prepend t)
("sa" "Appointment" entry (file+olp "~/org/school.org"
"Tasks" "Spring 2013") (file "~/org/templates/appointment.txt") :prepend t)
("sb" "Bookmark" entry (file+olp "~/org/school.org"
"Bookmarks") (file "~/org/templates/bookmark-school.txt"))
Re: [O] merging per-file (or heading) TODO sequences
Hi Eric, Eric Abrahamsen writes: > I could have sworn I've done this successfully before, but... > > I need a special sequence of TODO keywords for one file -- actually just > one headline in particular. I thought I remembered this used to be > possible, but it doesn't seem to be anymore. > > Setting #+SEQ_TODO: FOO | BAR at the top of the file actually > overwrites the existing value of `org-todo-keywords' for that file. In > this case I'd like to either: > > 1. Create this sequence for a single subtree (it's okay if it clobbers > the global value of `org-todo-keywords', so long as it's *only* for this > subtree), or > > 2. Set the new sequence at the top of the file, but merge this sequence > with the global value of `org-todo-keywords'. > Not sure if this is exactly what you want, but you can have multiple #+SEQ_TODO lines at the top of your file, e.g.: #+SEQ_TODO: TODO INPROGRESS WAITING | DONE CANCELED #+SEQ_TODO: FIND PRINT READ NOTES | DONE CANCELED Then trees will use the different sequences depending on which state you place them in initially. Best, Richard
Re: [O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]
Hi Bastien, Bastien writes: > Richard Lawrence writes: > >> I've been trying to get iCalendar export working with my agenda files >> again since upgrading to 8.0, and I've found that footnotes break the >> agenda export to .ics. The problem is that a plain text version of the >> footnotes in the file ends up in the output "floating loose"---not >> wrapped by VEVENT tags or any other tags---resulting in an unparseable >> .ics file (at least according to Google Calendar). > > I tried this patch but for some reason it does not work. This patch does not work for me, either, but thanks for trying! > I did not look further, surely Nicolas has something that > works. I agree footnotes should be turned off by default > for the .ics export. I also tried the following modifications in the definition of the icalendar backend, without much effect: 1) Adding (footnote-definition . ignore) and (footnote-reference . ignore) to the :translate-alist 2) Adding (:filter-footnote-definition . ignore) and (:filter-footnote-reference . ignore) to the :filters-alist Both of these looked like they might work based on the org-export-define-backend documentation, but the footnotes still show up in the output. [...further tinkering...] It looks like the problem is this: the icalendar backend does not specify a transcoder for the "inner-template" element. Thus it falls back to the org-ascii-inner-template transcoder, which appends footnotes to the end of the exported content. Thus, one solution is to define an org-icalendar-inner-template transcoder which does nothing to modify the content (but overrides the fallback); that is the solution I've used in the attached patch. Best, Richard diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el index 49299b0..39ba383 100644 --- a/lisp/ox-icalendar.el +++ b/lisp/ox-icalendar.el @@ -261,6 +261,7 @@ re-read the iCalendar file.") (inlinetask . ignore) (planning . ignore) (section . ignore) + (inner-template . org-icalendar-inner-template) (template . org-icalendar-template)) :options-alist '((:exclude-tags @@ -747,7 +748,18 @@ END:VALARM\n" (if (zerop alarm-time) org-icalendar-alarm-time alarm-time) - Template + Templates + +(defun org-icalendar-inner-template (contents info) + "Return inner contents string after iCalendar conversion. +CONTENTS is the transcoded contents string. INFO is a plist used +as a communication channel. + +This function just returns CONTENTS unchanged. Its purpose is to +override the inner-template transcoder of the ascii +backend (`org-ascii-inner-template'), which appends footnotes +that break the iCalendar format." + contents) (defun org-icalendar-template (contents info) "Return complete document string after iCalendar conversion.
[O] [PATCH] tiny fixes in ox-ascii.el [was: Re: Bug: Footnotes break iCalendar export]
Here is a patch for a couple of tiny issues I encountered in ox-ascii.el while debugging ox-icalendar.el. Explanation: 1) There is no function called `org-ascii-footnote-definition' (though it looks like maybe there once was?), so I changed a reference to it to `ignore' to be more explicit. I'm not sure if this is the right thing to do -- maybe the point was to let the user define such a function if she wishes? That however would be inconsistent with the comment that such definitions are ignored (see below). 2) A tiny change to the comment explaining why there is no such function: footnote definitions are ignored because they are compiled by `org-ascii-inner-template', not `org-ascii-template'. Best, Richard diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el index 2191539..4543c34 100644 --- a/lisp/ox-ascii.el +++ b/lisp/ox-ascii.el @@ -68,7 +68,7 @@ (export-block . org-ascii-export-block) (export-snippet . org-ascii-export-snippet) (fixed-width . org-ascii-fixed-width) -(footnote-definition . org-ascii-footnote-definition) +(footnote-definition . ignore) (footnote-reference . org-ascii-footnote-reference) (headline . org-ascii-headline) (horizontal-rule . org-ascii-horizontal-rule) @@ -1147,7 +1147,7 @@ CONTENTS is nil. INFO is a plist holding contextual information." Footnote Definition ;; Footnote Definitions are ignored. They are compiled at the end of -;; the document, by `org-ascii-template'. +;; the document, by `org-ascii-inner-template'. Footnote Reference
Re: [O] How to analyze clocking reports (e. g. with spreadsheet application)?
Hi Martin, Martin writes: > I'm using the org-mode clocking features (in org-mode 7.9.4) extensively > to document how much time I spent with which task and when. > > I wonder how I can export the data (e. g. to MS Excel) for further analysis; > * time consumed by different projects > * interruptions and "jumping" from task to task > * time consumed by tasks with a special tag > etc. Have you looked at this section in the manual? I don't use many of these features myself, but I think Org itself can tell you many of these things without exporting the data to a separate tool: http://orgmode.org/org.html#The-clock-table -- Best, Richard
Re: [O] Collaborating with TODO lists and clocks.
Hi Gareth, Gareth Smith writes: > Does anyone use org to collaborate on task lists? It seems to me that it > would be very natural to put a tasks.org file into a VCS repo, claim a > task by changing its status from TODO to IN_PROGRESS (and committing > that change), work, then mark as DONE at the end. > > That's all awesome - but what if you're also using org to clock your > working time? > ... > Alternatively, am I wrong about what I think I want? Is there a better > workflow I should be thinking about adopting? Is there a reason you don't want any clock data to end up in the shared tasks.org? If not, one thing you could do is: 1) When claiming a task, each person uses a tag for their name (in addition to, or instead of, just changing the TODO state). Then that person "owns" the clock data for that task. 2) Then use the :tags option on a clock table to filter the clock data for just the tasks you personally have worked on; each person can have their own table (in tasks.org). For example, suppose you have a task like: * TODO Frobnicate something You claim it by changing that to: * IN_PROGRESS Frobnicate something :gareth: Check that in, then start your clock in this tree. Somewhere else in the file, you have a clock table like: #+BEGIN: clocktable :maxlevel 3 :scope file :tags "+gareth" #+CAPTION: Gareth's working time on all tasks # ... #+END: which will show you the clock data for just the tasks you've worked on (i.e., are tagged in). -- Best, Richard
Re: [O] Collaborating with TODO lists and clocks.
Hi Gareth, Gareth Smith writes: > I hadn't thought of using :tags on a clock table. I still worry if we'll > find ourselves in a situation where more than one of us has clocked in > some time on the same task. Yes, I agree this might not be optimal, for that case in particular. One nice thing about this use of tags is that you have a representation of when more than one person is working on a task, but that makes the clock less useful, as it can no longer represent an individual's working time without some effort to separate the clocks of the different owners. > For example, often I clock into a task while I do the work of > sub-dividing it into smaller tasks. And often when I'm actively working > on a task, I'll create a sub-task of my current-clocked-task on the > fly. It seems to me that if I continue with this sort of working > practice, and attempt to collaborate with others who work similarly, > then we might quickly find that it's not easy to describe a given task > (or even subtask) as being "owned" by a single person. So one problem case is where you "own" a task, but someone else owns one of its subtasks, e.g.: == * Clock tables #+BEGIN: clocktable :maxlevel 2 :scope file :tags "+gareth" #+CAPTION: Clock summary at [2013-04-29 Mon 18:25] | Headline | Time | | |++--| | *Total time* | *3:05* | | |++--| | TODO Task 1| 3:05 | | | \__ TODO Subtask 1 || 1:05 | | \__ TODO Subtask 2 || 1:00 | #+END: #+BEGIN: clocktable :maxlevel 2 :scope file :tags "+john" #+CAPTION: Clock summary at [2013-04-29 Mon 18:17] | Headline | Time | | |++--| | *Total time* | *1:05* | | |++--| | TODO Task 1| 1:05 | | | \__ TODO Subtask 1 || 1:05 | #+END: * TODO Task 1:gareth: CLOCK: [2013-04-29 Mon 18:15]--[2013-04-29 Mon 19:15] => 1:00 ** TODO Subtask 1 :john: CLOCK: [2013-04-29 Mon 18:15]--[2013-04-29 Mon 19:20] => 1:05 ** TODO Subtask 2:gareth: CLOCK: [2013-04-29 Mon 16:16]--[2013-04-29 Mon 17:16] => 1:00 == Notice that Gareth gets credit for John's time on Subtask 1, because Gareth owns Task 1. You can avoid this particular gotcha in (at least) two ways: 1) Remove the :gareth: tag on task 1 and move the clock time to subtask 2 (more generally, "ownership" tags and clock times should only appear at the lowest level of the task tree). Maybe this makes the most sense, but it slows down the worflow a bit and is hard to enforce, etc. 2) Use a tag filter like "+gareth-john" to build the clock table (more generally, the clock table for each person should exclude tags for all the others). This prevents double counting and is easy to enforce, but if any tasks have more than one owner, no one will get credit for their clock times. > Again, perhaps my workflow is at fault, and I should be organising > myself in a more principled way. And perhaps in practice I'll find that > tasks do tend to be owned by just one person anyway. Yeah, it's a hard problem with no general solution that I can see. The best thing is just to figure out what constraints you're willing to put on your workflow, given what Org allows you to do. Hope that's helpful! Best, Richard
Re: [O] [OT] Gnus mail tutorial?
Jacek Generowicz writes: > Marcin Borkowski writes: > >> I'm thinking about using Emacs as my email client, and I'm considering >> using Gnus for that. > > If it is Emacs rather than Gnus itself that attracts you, then you might > consider notmuch or mu4e. Both have a Xapian-based core, and include an > Emacs interface. +1. I used Gnus with an IMAP account for a while, but found that (in addition to being intimidating and complicated) it was annoyingly slow. I did write a brief tutorial about getting it set up, which you may or may not find useful; it's at [1]. I still use Gnus to read news (e.g., this list, via Gmane), which is much simpler to set up, and pretty handy. After abandoning Gnus for mail, but wishing to remain in Emacs, I tried nmh with MH-E as a front end. I liked MH-E well enough, but the big problem was that I couldn't find any program to sync mail in both directions from MH directories, and I want a local copy of my mail on multiple machines which reflects the state on the IMAP server. So, long story short, I have now switched to using offlineimap to sync over IMAP with a Maildir. This keeps my mail locally available but also in sync across multiple machines. I read this Maildir in mutt, not Gnus, because I read nasty things on the Internet about how Gnus' Maildir implementation really stinks (e.g., it uses its own tagging system instead of the standard Maildir flags, and it eats up inodes on your filesystem like crazy). I use notmuch to index it, and notmuch-mode in Emacs to search it. I have my mutt editor set to emacsclient. It ain't perfect, by any means (and if anyone has suggestions on a better setup, I'd love to hear them), but it works for me. [1] http://whereofwecannotspeak.wordpress.com/2009/07/15/getting-gnus-to-read-mail-over-imap/ -- Best, Richard
[O] Avoid escaping braces in LaTeX export?
Hi all,
I'm wondering if there is a way to prevent the LaTeX exporter from
escaping "{" and "}" characters. There are export options to control
the behavior of a number of other special characters, but I don't see
any way to control export of braces in the documentation. Am I just
missing it? If not, I'd like to request this as a feature.
Here's my use case. I often create new commands in LaTeX to abstract
over some common pattern so I can easily type it and change it later if
necessary. For example, when taking notes on readings, I have a command
that makes its argument into an `inline comment' (basically an aside to
myself) defined as follows:
#+LATEX_HEADER: \newcommand{\ic}[1]{{\footnotesize [~#1~]}}
Then in my notes I have things like:
Marcus' point is more subtle, though, than that the substitutional
reading validates these inferences or theorems while the objectual
reading does not. \ic{This would not persuade Quine, for example: the
failure of existential generalization in modal contexts is for Quine a
reason to reject quantified modal logic, rather than give the
existential quantifier a different reading.}
The new exporter exports this as:
Marcus' point is more subtle, though, than that the substitutional
reading validates these inferences or theorems while the objectual
reading does not. \ic\{This would not persuade Quine, for example: the
failure of existential generalization in modal contexts is for Quine a
reason to reject quantified modal logic, rather than give the
existential quantifier a different reading.\}
with the braces wrapping the argument for my custom command escaped.
This breaks the custom command in the export.
I can't test it at the moment, but I believe the old exporter did not
escape these braces, as I used this command regularly and it compiled
correctly.
I would like to be able to get the old behavior back. I don't mind
manually escaping braces when necessary, because I almost always do not
want them escaped. I understand if this is not a reasonable default,
but it would be nice for me if it were something I could set on an
#+OPTIONS line. If others are interested in this, I can look into
creating a patch.
(By the way, it looks like there was a patch for a similar issue in
commit c6fd49726f2eaf417361b190b37e2d8ffb5864fc, but that is from April
2009 and therefore would apply to the old exporter.)
Thanks for your insights!
--
Best,
Richard
