[O] bug#18870: bug#18870: \emsp and alignment in org clock report
I can't speak for the technical details, but I get the sense that \emsp isn't the right thing to be displayed on an *agenda clock report* because agenda clock reports don't get exported (afaik). Even \__ is more preffered than an \emsp, as \emsp is not 'easy to read' per se. Since there are clearly difference in opinions, maybe a solution is to have a variable like 'org-clockreport-indentation-character' which defaults to \emsp for correct export, but could be changed to spaces or '\__' by the user. This would give people the choice between better export or better text-buffer display. Thoughts? Leo Ufimtsev | Intern Software Engineer @ Eclipse Team - Original Message - From: "Nicolas Goaziou" To: "Ben Finney" Cc: 18...@debbugs.gnu.org Sent: Tuesday, March 17, 2015 6:07:03 PM Subject: [O] bug#18870: \emsp and alignment in org clock report Ben Finney writes: > The behaviour described – displaying “\emsp” instead of space > characters – is a regression. That's what is being reported in this > bug. There wasn't space characters in the first place, but "\___" constructs. See commit bacfe5b4f7244eaf151f4e26a1d94dd8f66c1d19. Also, the bug is about table alignment when `org-pretty-entities' is used. >> Having some space character is not desirable as it would just move >> the problem the other way around (i.e., indentation would not appear >> during export) > > So the U+2003 EM SPACE character should be translated *during export*, > and not be literally in the displayed text. No, because it means this character should be treated specially by Org (e.g., LaTeX just ignores it so it needs to be turned into a space there). This is not a good idea, especially considering it is an invisible character. > IS the above suggestion an acceptable solution? No, it isn't. An acceptable solution would be a character or a string that looks decent both in the buffer and in an exported document, without further processing. >> Note that this is not LaTeX-specific markup. This is called an entity, >> and is correctly exported in various back-ends. > > But not for display, which is the bug to be fixed here. Actually, it works more or less correctly for display on GUI with a non-nil `org-pretty-entities', or calling `org-toggle-pretty-entities'. Regards,
Re: [O] [patch, koma-letter] Change of subject behavior
Rasmus writes:
> - (cdr (assoc (org-koma-letter--get-value key)
> - org-koma-letter-special-contents)))
> + (cdr (assoc-string (org-koma-letter--get-value key)
> + org-koma-letter-special-contents)))
AFAIU, this is a bugfix, so it should go in a separate commit.
> + (let ((special-tag (car (org-koma-letter--special-headline headline
> info
> +(if special-tag
> + (progn (push (cons special-tag contents)
> org-koma-letter-special-contents)
> +"")
> + contents)))
Nitpick:
(if (not special-tag) contents
(push ...)
"")
In this case, I suggest to change `org-koma-letter--special-headline'
into `org-koma-letter--special-tag', where the latter explicitly returns
special tag associated to the current headline, or nil (this skips the
`car' part).
> +(defun org-koma-letter--special-headline (headline info)
> + "Nonnil if HEADLINE is a special headline."
> + (let ((special-tags (plist-get info :special-tags)))
> +(mapcar (lambda (tag) (assoc-string tag special-tags))
> + (org-export-get-tags headline info
"Non-nil"
Also, the docstring should document INFO. Moreover, it isn't really
a predicate anymore, since you're using the value returned. Thus, that
value should be explained.
Eventually, since you're only interested in the first special tag
encountered, it may be cleaner to exit early, e.g.,
(defun org-koma-letter--special-tag (headline info)
"Return special tag associated to HEADLINE, as a symbol, or nil.
INFO is the current state of the export process, as a plist."
(let ((special-tags (plist-get info :special-tags)))
(catch 'exit
(dolist (tag (org-export-get-tags headline info))
(let ((special-match (assoc-string tag special-tags)))
(when special-match (throw 'exit (car special-match
> + (format "\\opening{%s}\n\n"
> +(org-export-data
> + (or (org-string-nw-p (plist-get info :opening))
> + (when (plist-get info :with-headline-opening)
> + (org-element-map (org-element-parse-buffer) 'headline
^
(plist-get info :parse-tree)
Regards,
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
On Tue, Mar 17, 2015 at 6:38 PM, Nicolas Goaziou wrote: (re unresolved ID links) >See e0b19dedb99d3c01199a159a2da8f9aa4adb2f6f >> Updated fuzzy link patch attached. > Applied (with minor tweaks). Thank you. Thanks for the changes. I had some issues using the error messages to track down bad links with descriptions since the link path is hidden. (isearch doesn't search the hidden text.) If anyone else is similarly challenged, `org-toggle-link-display' is very helpful here. Regards, Jake
Re: [O] Org to mindmap and back
Hi Nick, Good catch, thanks. I'll try contacting him directly and will share my findings here. -- Marcelo On Wed, Mar 18, 2015 at 10:05 AM, Nick Dokos wrote: > Marcelo de Moraes Serpa writes: > > > Hi Dave, > > > > Yes, I'm aware of the freemind exporter. I'm not very fond of freemind > though, I find it clunky to use. > > > > I really liked the minimalist style of the mind-mapping application > shown in the video (also the animation effects are cool, too). > > Would be great if the author could chime in and perhaps share the code. > Heck, I'd be willing to buy it if the integration with org > > was good enough (both-ways auto synchronization). > > If you examine the video closely, it looks like it's a Mac application, > the author is David Griffiths and the application *might* be iMapMinder > (also available on Windows, but not on Linux - non-free both in the > freedom and beer sense). All of this is pure guesswork on my part > and might very well be completely wrong. > > If David Griffiths is indeed the author, I don't remember seeing him on > the ML. You'll have to find another way to contact him. The org file > shows an email address of > > dgriffiths AT fas.harvard.edu > > but that might not be valid any longer (the video was posted in 2011). > > Nick > > > > > On Tue, Mar 17, 2015 at 3:59 PM, J. David Boyd wrote: > > > > Marcelo de Moraes Serpa writes: > > > > > Hi, > > > > > > While searching for mind mapping tools that already had some > > > integration with orgmode, I found this video: > > > https://www.youtube.com/watch?v=93cqGFu3B-g, which shows a simple > (but > > > seemingly powerful) mindmapping tool that integrates well with org. > > > > > > Unfortunately the link to the code / app is nowhere to be found in > the > > > video description and the video is pretty old. It'd be unfortunate > to > > > not share such an interesting project. I'm very interested in > > > using/testing/extending it. I'm wondering if the author still lurks > > > around this mailing list? *ping* > > > > > > Either way, it's a great idea and someone else (even myself) could > get > > > some inspiration out off it and create something similar (and > share!) - > > > I've been wanting a way to visualize my org files in the form of a > > > mindmap and keep both representations synced so I could just switch > > > when I wanted, and this seems to be the gist of it. > > > > > > Cheers, > > > > > > -- Marcelo > > > > There is a connection to Freemind in the source tree. Not near my > computer > > right now. The name is something like ox-freemind.el... > > > > Dave > > >
Re: [O] Include HTML fragments in HTML export
Hi, Titus von der Malsburg writes: > * My personal home page > ** Articles > #+INCLUDE "file1.html" html > > ** Posters > #+INCLUDE "file2.html" html This works in Org 8.3. Org 8.2 does not seem to insert blocks cf. org-export-expand-include-keyword. Hope it helps, Rasmus -- Me gusta la noche, me gustas tú
[O] Include HTML fragments in HTML export
Hi list, I use org mode to create my personal webpage via the HTML exporter. Some parts of my webpage are automatically generated (using bibtex2html) and stored as HTML fragments in separate files. I'd like to include the content of these files in the resulting document but there seems to be no way to achive this. One approach I tried is the following: * My personal home page ** Articles #+INCLUDE "file1.html" html ** Posters #+INCLUDE "file2.html" html This, however, escapes the HTML from file1.html and file2.html and I see the HTML source in the resulting webpage not the rendered version. Is this a bug in the HTML exporter or is this the intended behavior? If this behavior is intended, how can I include unescaped HTML in the output of the HTML export? Titus signature.asc Description: PGP signature
Re: [O] [proposal] timezone-aware timestamps enhancement
On 2015-03-18 at 12:33, Eric S Fraga wrote: > On Wednesday, 18 Mar 2015 at 10:13, Randomcoder wrote: >> Currently, AFAIK when scheduling something in Org-Mode, the timestamp >> doesn't have a timezone. > > there is no specific solution unfortunately. Having spent a year living > and working across time zones, I was unable to find a good > solution. I have a solution that works quite well outside of Org. Apple Calendar supports timezones plus a "floating" option. I use Org for all my floating events - local to the computer and me, whatever TZ we're in. I haven't found a way to put TZ-specific events into Org. If scheduling a Skype with someone in NZ, I enter it in iCal at the NZ time in the NZ timezone. Org pulls in my iCal events. Then wherever I am when that event happens, I get the alert at the correct time. Most things are local to me, so I use "floating" and stay in Org. -k.
Re: [O] [proposal] timezone-aware timestamps enhancement
On Wednesday, 18 Mar 2015 at 10:13, Randomcoder wrote: > Hi, > > Currently, AFAIK when scheduling something in Org-Mode, the timestamp > doesn't have a timezone. [...] > Thanks for taking the time to read this. I welcome any feedback on this > as I'm interested in how other people are solving this sort of problem. Hello Ms Randomcoder, there is no specific solution unfortunately. Having spent a year living and working across time zones, I was unable to find a good solution. And, in fact, the problem was compounded by trying to synchronise org data with Google's calendar and with MS Outlook. I eventually simply stopped synchronising and relied on my computer having the time that was appropriate for where I was at the time. All org data were "local" time with a fluid definition of "local". -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-820-gd92ef9
Re: [O] export code with backslashes
On Wed, 18 Mar 2015, hy...@lactose.homelinux.net wrote: "Charles C. Berry" writes: (defun org-export-ascii-filter-code (text back-end info) "Replace `\\n' with `\\' in ascii code." (if (eq back-end 'ascii) (replace-regexp-in-string "\n" "\\\n" (org-babel-chomp (org-export-string-as text 'ascii t)) nil t) text)) (add-to-list 'org-export-filter-code-functions 'org-export-ascii-filter-code) Just for the record. I had an open running emacs. I changed my .emacs file, applied the change with M-x load-file .emacs , and it worked perfectly. But today, I opened emacs fresh, and was greeted with an error Symbol's value as variable is void: org-export-filter-code-functions I got the same error when I tried to M-x load-file .emacs But After I did an ascii export (in which the backslashes do not appear), I could then M-x load-file .emacs, no error, and the backslashes worked. I added (require 'ox) to my .emacs file, and that resolved the problem. Use #+BEGIN_SRC emacs-lisp (eval-after-load 'ox '(add-to-list 'org-export-filter-code-functions 'org-export-ascii-filter-code)) #+END_SRC Chuck
Re: [O] [ox, patch] Keywords & what should go in ox?
Nicolas Goaziou writes: > Rasmus writes: > >> Nicolas Goaziou writes: >> >>> We don't need a convoluted markup for that, let's keep it simple. >> >> But then you'd have to repeat data. E.g. >> >> #+KEYWORDS: my keywords for meta-data that should also be printed. >> my keywords for meta-data that should also be printed. >> >> This seems error prone and undesirable IMO. > > Except that this is not a real repetition. As you mentioned, in the > latter case, you want to throw in links and probably other markup, which > make no sense in plain meta-data. Keywords are akin to small headings to identify the contents of a document. I see no reason to restrict this to the reader of the electronic version of a document. > IMO, this is over-engineering. I disagree, but extrapolating this will go nowhere. —Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
Re: [O] [ox] possible to modify org-export-document-properties OTG
Nicolas Goaziou writes: > Document properties are keywords where `org-element-context' is allowed > to return an object. It doesn't make sense to add random keywords > specific to some export back-ends to the list. I think something like SUBJECT in ox-koma-letter makes sense. But what I'm really after is an "easy" way to control org-export-data from the backend definition. >> Or should org-element-parse-secondary-string be used with appropriate >> limitations? > > For now, I suggest to use `org-element-parse-secondary-string'. Why I don't like this is that it feels quite low-level (purely emotional) (org-export-data (oe-parse-2nd-string ⋯) ⋯) > At some point, I thought about adding a `parsed' behaviour to > `org-export-options-alist' as a shortcut. Presumably you'd want to be able to toggle it for elements of export-options. > Sadly, I cannot remember why I didn't implement the idea eventually. It > may be related to `org-element-map', which couldn't map over data in > such keywords, or the fact that it would be confusing wrt > `org-element-context'. E.g., if we consider the two keywords > > #+TITLE: *boXld* > #+PARSED_KYWORD_IN_SOME_BACKEND_IGNORED_IN_OTHERS: *boXld* > > in the former, `org-element-context' at "X" returns a `bold' object, in > the latter, a `keyword' element. Note that I'm not arguing it should > return a `bold' object in both cases, it really shouldn't, but it can be > confusing and potentially trigger false bug reports. I don't understand why an export setting would affect an element interpretation such as org-element-map. Probably I have something different in mind than you. –Rasmus -- However beautiful the theory, you should occasionally look at the evidence
Re: [O] Why don't datetrees use timestamps?
Nick Dokos writes: D> Reuben Thomas writes: > >> On 16 March 2015 at 16:52, Subhan Michael Tindall >> wrote: >> >> You can use a custom capture template and have timestamps of various >> sorts inserted. >> >> For example, I have one datetree I use that inserts a date/time stamp >> using %T (%t gives only date, not time) >> >> See the documentation for capture (hit C-c C C to get into the >> customize interface then scroll down) >> >> My question was about the datetree entry headings of the form "2015-03-16 >> Monday". These aren't controlled by the template. I was interested to know >> why these >> headings look very much like timestamps (and effectively are timestamps, >> though at the top level they mention just a year and at the second level >> just a year and a >> month), but aren't actual timestamps. >> >> Eric Fraga said "I don't think it would make sense for the headlines in the >> date-tree to have time stamps"; but my question is not why they don't have >> time stamps, >> but why they ARE not time stamps (purely in the formal sense: the >> information they contain is already effectively a time stamp, as far as I >> can see). >> > > This is third-hand knowledge and guesswork on my part, but I think that > datetrees are used for things like journals: "that's what I did that > day". Datetrees just give you a hierarchical structure of nodes for > easy navigation: you can look at your journal and open and close nodes > at will, so you can navigate to the date of interest. The fact that the > third-level headings look like timestamps is purely coincidental. > > Timestamps are given to things that are going to appear in an agenda: > "that's what I have to do today, tomorrow or next week". They are > completely orthogonal to datetrees in that respect. > > The stuff that ends up in your journal is stuff that (mostly) did not > appear in the agenda: all the little things that you did that day, > probably unplanned (otherwise they would be in the agenda!) > > Not that the headings in a datetree couldn't be made into timestamps; > but that's not what people use datetrees for[fn:1]. The one thing that > would be facilitated if they *were* timestamps, would be clicking on one > and getting the day agenda for that long-gone day, so you could > reminisce about the other things that you did that day, that did not end > up in your journal. Maybe that's enough reason to make them > timestamps, but there are other (perhaps less convenient) ways > to do that. > > Of course, I may be suffering from a failure of imagination: you might > be using datetrees in a completely different way, one where having the > heading be a timestamp is a very good idea, but I can't think of any: > if you *have* something in mind, do tell. I often feel the same thing, that datetrees should use timestamps(the 'quiet' kind). The main reason is that I often write a journal entry the day after, and it would be easier to manipulate the date like you do a time stamp. > >> I was hoping to discover the rationale for the design from a developer :) > > You'll have to ask Carsten about it: he invented datetrees I believe (as > well as most of org), but he does not frequent org circles much these > days. > > Footnotes: > > [fn:1] Remember however my caveat about third-hand knowledge and > guesswork: I don't use datetrees. > > Nick > > > -- Joakim Verona
Re: [O] Multicite syntax
Nicolas Goaziou writes:
>> I ask because in that kind of context, I think it is generally going to
>> be more useful to deal with citation objects as a whole. I am not sure
>> we will want to treat citation-references as individual objects which
>> are themselves exported; instead, I think we will want to handle
>> exporting the citation-references in a citation all at once.
>
> I don't know. In any case, they need to be treated as regular object
> (e.g., they are expected to have a filter associated to them).
Hmm. I can see that making sense if the filter manipulates the
citation-reference object itself, but I can't see it making sense if the
idea is that the exporter transcodes citation-references individually,
and the filter manipulates the transcoded string.
For example, suppose LaTeX export works by mapping a citation object to
a biblatex command, and consider this citation:
[cite: See @Doe99 ch. 1; @Doe2000 p. 10]
This should be transcoded in the final output to something like:
\textcite[See][ch. 1]{Doe99}[][p. 10]{Doe2000}
in which case the transcoded string corresponding to the first
citation-reference object is "[See][ch. 1]{Doe99}". It's hard for me to
see how you could do anything useful with just this string, and it might
even be dangerous to manipulate it, since it is only part of a complete
command, which you might mess up by modifying the string.
In other backends, there might not even be a syntactically-identifiable
chunk of the output citation which corresponds to a given
citation-reference. (I'm having trouble thinking of a good example at
the moment, but I'm thinking of cases where e.g. CSL processing turns a
reference into "Ibid.", or some other output that only has meaning
relative to its place in the document and doesn't correspond in a
context-free way to the citation-reference object.)
But like I said, it makes more sense if the filter can manipulate the
citation-reference object itself, e.g. by setting additional properties
or modifying the prefix and suffix strings *before* the object is
transcoded as part of a citation.
> If some back-end doesn't need to export directly citation references, it
> just needs to skip the relative translator.
Sure. I guess I'm just having a hard time seeing why a backend would
ever need/want to translate citation-references individually, rather
than generating a complete citation all at once. That seems to be the
way to do it in both the LaTeX and CSL worlds, anyway.
Best,
Richard
Re: [O] Org to mindmap and back
Marcelo de Moraes Serpa writes: > Hi Dave, > > Yes, I'm aware of the freemind exporter. I'm not very fond of freemind > though, I find it clunky to use. > > I really liked the minimalist style of the mind-mapping application shown in > the video (also the animation effects are cool, too). > Would be great if the author could chime in and perhaps share the code. Heck, > I'd be willing to buy it if the integration with org > was good enough (both-ways auto synchronization). If you examine the video closely, it looks like it's a Mac application, the author is David Griffiths and the application *might* be iMapMinder (also available on Windows, but not on Linux - non-free both in the freedom and beer sense). All of this is pure guesswork on my part and might very well be completely wrong. If David Griffiths is indeed the author, I don't remember seeing him on the ML. You'll have to find another way to contact him. The org file shows an email address of dgriffiths AT fas.harvard.edu but that might not be valid any longer (the video was posted in 2011). Nick > > On Tue, Mar 17, 2015 at 3:59 PM, J. David Boyd wrote: > > Marcelo de Moraes Serpa writes: > > > Hi, > > > > While searching for mind mapping tools that already had some > > integration with orgmode, I found this video: > > https://www.youtube.com/watch?v=93cqGFu3B-g, which shows a simple (but > > seemingly powerful) mindmapping tool that integrates well with org. > > > > Unfortunately the link to the code / app is nowhere to be found in the > > video description and the video is pretty old. It'd be unfortunate to > > not share such an interesting project. I'm very interested in > > using/testing/extending it. I'm wondering if the author still lurks > > around this mailing list? *ping* > > > > Either way, it's a great idea and someone else (even myself) could get > > some inspiration out off it and create something similar (and share!) - > > I've been wanting a way to visualize my org files in the form of a > > mindmap and keep both representations synced so I could just switch > > when I wanted, and this seems to be the gist of it. > > > > Cheers, > > > > -- Marcelo > > There is a connection to Freemind in the source tree. Not near my > computer > right now. The name is something like ox-freemind.el... > > Dave
Re: [O] Citation syntax: a revised proposal
Hi Matt, Matt Price writes: > Just a note about Zotero: I think for most of us, the reason to export > into ODT and/or DOC is to circulate a paper either for review or > collaboration. Either case will likely involve some revision to citations, > which would ideally be handled through Zotero. for this to work properly, > we would want to export a full Zotero citation. To do that, we would > likely need to speak directly to Zotero iteself. > ... > Among other pieces of data, it contains a reference to a zotero URL which i > don't think org-citeproc will know about. Can you describe what would be > necessary to get text like this into an ODT, using ythe code you've been > working on? Hmm, interesting. It looks like the ODT XML encodes the actual JSON representing the citation, with the Zotero URL you refer to going in the "uri" or "uris" property. What is this used for, exactly? I get an Access Denied error when I try to visit the URL...is it something you can share with collaborators? I'm not sure exactly what's required to get this information through a processing pipeline that looks like Zotero -> Org -> org-citeproc -> pandoc-citeproc -> pandoc -> org-citeproc -> Org. The question is whether the pandoc(-citeproc) data structures have slots for URLs associated with a work in the reference database, and whether the rendering functions will pay attention to those URLs. I know that Pandoc is capable of reading in citation data that includes URLs, but I don't know whether that URL information makes it to the other side of the pandoc-citeproc CSL processing. It may (in fact, probably does) depend on the CSL stylesheet. I would need to look into this a bit, but it's possible that with an appropriate stylesheet, it's pretty trivial to generate output like this. Another option would be to post-process the org-citeproc output within the Org exporter. If Org has got the data from Zotero, wrapping the actual citation in and tags that contain this data shouldn't be too hard to do from Elisp. Finally, a third option is not to use org-citeproc at all in this case. If you are already using Zotero, which contains its own CSL processor (citeproc-js), then you may be able to just use Zotero to render the citations and bibliography, by passing it JSON data. The zotxt plugin might help here: https://bitbucket.org/egh/zotxt/src. In that case, the processing pipeline would be much simpler: Org -> (zotxt ->) Zotero (-> zotxt) -> Org. The nice thing about using the citeproc-js JSON format as the input to org-citeproc is that it makes having this alternative pipeline pretty simple. I already have Elisp functions to generate this JSON from an Org citation object (see the *-to-json functions in the org-citeproc repo). Setting up this alternative pipeline would involve figuring out how to send that data to Zotero and how to parse the response, which would basically mean writing a function parallel to org-cite--process-citations (in the org-cite library in my wip-cite-org-citeproc branch) that talks to Zotero instead of org-citeproc. Best, Richard
[O] [RFC][PATCH] Store links to named elements
In [1], storing links to named elements was discussed. AFAICT, no patches came from that discussion. The current behavior is that given: * Headline #+Name: foo org-store-link will store a link to `*Headline' rather than `foo'. Attached is a very rough first attempt at patching org-store-link to recognize and link to the name. Is this approach worth fleshing out or are there problems associated with this type of link? Using the above example, [[foo]] seems to be a valid link, recognized by both export and org-open-at-point. If doable, a couple of specific questions: This attached patch makes no attempt to store the file name as currently done for headlines. Would it be better to check for a name in the headline linking code (the final "t" in the org-mode-p `cond' in org-store-link) or rather reproduce file name code separately. Does a context string make sense for links to element names? Regards, Jake [1] http://permalink.gmane.org/gmane.emacs.orgmode/91935 From f1166d30ccabdb208b0263d87fd9366fa9a2f325 Mon Sep 17 00:00:00 2001 From: Jacob Gerlach Date: Wed, 18 Mar 2015 09:58:00 -0400 Subject: [PATCH] Add support to link to named elements * lisp/org.el (org-store-link): Store links to named elements. Before falling back to the current headline, check if point is at a named element, and if so store the element name as the link. TINYCHANGE --- lisp/org.el | 5 + 1 file changed, 5 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index b1999dc..0a37a2f 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -9838,6 +9838,11 @@ active region." (concat "file:" (abbreviate-file-name (buffer-file-name (buffer-base-buffer + + ((org-element-property :name (org-element-at-point)) + ;; At a named element, link to the name + (setq cpltxt (org-element-property :name (org-element-at-point + (t ;; Just link to current headline (setq cpltxt (concat "file:" -- 1.9.1
Re: [O] export code with backslashes
"Charles C. Berry" writes: > (defun org-export-ascii-filter-code (text back-end info) > "Replace `\\n' with `\\' in ascii code." > (if (eq back-end 'ascii) > (replace-regexp-in-string > "\n" "\\\n" > (org-babel-chomp > (org-export-string-as text 'ascii t)) > nil t) > text)) > (add-to-list 'org-export-filter-code-functions >'org-export-ascii-filter-code) Just for the record. I had an open running emacs. I changed my .emacs file, applied the change with M-x load-file .emacs , and it worked perfectly. But today, I opened emacs fresh, and was greeted with an error Symbol's value as variable is void: org-export-filter-code-functions I got the same error when I tried to M-x load-file .emacs But After I did an ascii export (in which the backslashes do not appear), I could then M-x load-file .emacs, no error, and the backslashes worked. I added (require 'ox) to my .emacs file, and that resolved the problem. This error only happens on my Windows machine. On my Unix machine, it appears to work correctly the first time, and I do not see any differences between the .emacs files on the two machines. --hymie! http://lactose.homelinux.net/~hymiehy...@lactose.homelinux.net
Re: [O] [patch, koma-letter] Change of subject behavior
Nicolas Goaziou writes:
>> I have only tested the patch briefly as I need to actually produce a
>> letter. But for the letter I'm writing export works fine.
>
> You sent a wrong patch.
Ups. Let's try again.
In the second patch I fix the no interpretation of #+SUBJECT.
—Rasmus
--
Lasciate ogni speranza, voi che leggete questo.
>From 0d8e0f21f3c120afef3e08628962f7fa99337aef Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Wed, 18 Mar 2015 13:33:42 +0100
Subject: [PATCH 2/2] ox-koma-letter: Interpret #+SUBJECT.
* ox-koma-letter.el (org-koma-letter-template): Interpret #+SUBJECT.
---
contrib/lisp/ox-koma-letter.el | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index d7572b5..e7be56a 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -626,7 +626,11 @@ holding export options."
(mapconcat #'symbol-name with-subject ","
(let* ((title-as-subject (plist-get info :with-title-as-subject))
(subject* (org-string-nw-p
- (org-export-data (plist-get info :subject) info)))
+ (org-export-data
+ (org-element-parse-secondary-string
+ (plist-get info :subject)
+ (org-element-restriction 'keyword))
+ info)))
(title* (and (plist-get info :with-title)
(org-string-nw-p
(org-export-data (plist-get info :title) info
--
2.3.3
>From a7289286b0b02310b4e3f714fc7047f7af7a027c Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Tue, 17 Mar 2015 18:32:26 +0100
Subject: [PATCH 1/2] ox-koma-letter: Stricter subject inference
* ox-koma-letter.el (org-koma-letter--special-headline): New function.
(org-koma-letter--get-tagged-contents): Refactor
(org-koma-letter-headline): Use org-koma-letter--special-headline
and do not guess opening.
(org-koma-letter-template): Directly infer subject from first
non-special headline.
---
contrib/lisp/ox-koma-letter.el | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 1b5dd17..d7572b5 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -412,6 +412,7 @@ was not present."
(:with-place nil "place" org-koma-letter-use-place)
(:with-subject nil "subject" org-koma-letter-subject-format)
(:with-title-as-subject nil "title-subject" org-koma-letter-prefer-subject)
+(:with-headline-opening nil nil org-koma-letter-headline-is-opening-maybe)
;; Special properties non-nil when a setting happened in buffer.
;; They are used to prioritize in-buffer settings over "lco"
;; files. See `org-koma-letter-template'.
@@ -453,8 +454,8 @@ was not present."
(defun org-koma-letter--get-tagged-contents (key)
"Get contents from a headline tagged with KEY.
The contents is stored in `org-koma-letter-special-contents'."
- (cdr (assoc (org-koma-letter--get-value key)
- org-koma-letter-special-contents)))
+ (cdr (assoc-string (org-koma-letter--get-value key)
+ org-koma-letter-special-contents)))
(defun org-koma-letter--get-value (value)
"Turn value into a string whenever possible.
@@ -553,19 +554,17 @@ Note that if a headline is tagged with a tag from
`org-koma-letter-special-tags' it will not be exported, but
stored in `org-koma-letter-special-contents' and included at the
appropriate place."
- (unless (let ((tag (car (org-export-get-tags headline info
- (and tag
- (member-ignore-case
- tag (mapcar #'symbol-name (plist-get info :special-tags)))
- ;; Store association for later use and bail out.
- (push (cons tag contents) org-koma-letter-special-contents)))
-;; Opening is not defined yet: use headline's title.
-(when (and org-koma-letter-headline-is-opening-maybe
- (not (org-string-nw-p (plist-get info :opening
- (plist-put info :opening
- (org-export-data (org-element-property :title headline) info)))
-;; In any case, insert contents in letter's body.
-contents))
+ (let ((special-tag (car (org-koma-letter--special-headline headline info
+(if special-tag
+ (progn (push (cons special-tag contents) org-koma-letter-special-contents)
+ "")
+ contents)))
+
+(defun org-koma-letter--special-headline (headline info)
+ "Nonnil if HEADLINE is a special headline."
+ (let ((special-tags (plist-get info :special-tags)))
+(mapcar (lambda (tag) (assoc-string tag special-tags))
+ (org-export-get-tags headline info
Template
@@ -641,7 +640,17 @@ holding export options."
(format "\\begin{letter}{%%\n%s}\n\n"
(org-koma-letter--determine-to-and-from info 'to))
;; Opening.
- (format "\\opening{%s}\n\n" (plist-get info :opening))
+ (format "\\opening{%s}\n\n"
+ (org-export-data
+ (or (org-string-nw-p (plist-get info :opening))
+ (when (plist-get info :with-headline-opening)
+ (org-element-map (org-element-
Re: [O] [patch, koma-letter] Change of subject behavior
Rasmus writes: >>> + (:with-headline-opening nil nil >>> org-koma-letter-headline-is-opening-maybe) >> >> I don't think this line is required. > > It feels more consistent to provide the check through the definition, but > I'm not willing to pick a fight over this so it's back to just checking > the variable. Of course, you're right. It is way better to add it as an option, since you can override variable value during publishing. You can irrevocably ignore my comment. > I have only tested the patch briefly as I need to actually produce a > letter. But for the letter I'm writing export works fine. You sent a wrong patch. Regards,
[O] [bug] Multi-day events aren't properly fontified in the agenda
Hello, Having 2 events such as: --8<---cut here---start->8--- ** Party during day 1 of the week-end <2015-03-21 Sat> ** Party during week-end <2015-03-21 Sat>--<2015-03-22 Sun> --8<---cut here---end--->8--- you'll see that the mono-day event will be fontified with the face `org-agenda-calendar-event', not the multi-day event. Best regards, Seb -- Sebastien Vauban
[O] [proposal] timezone-aware timestamps enhancement
Hi, Currently, AFAIK when scheduling something in Org-Mode, the timestamp doesn't have a timezone. Use-case example: Let's say Carsten Dominik schedules a meeting with someone, then jumps on a plane and travels to some place that's on a timezone difference of -/+ 3 hours. He will probably miss the meeting. I propose one of the following alternatives: * either all timestamps are considered UTC and they dynamically change with the timezone of the system where Emacs is running * timestamps come with timezone so the user can see what time the meeting was scheduled at. Thanks for taking the time to read this. I welcome any feedback on this as I'm interested in how other people are solving this sort of problem.
