Re: [O] [patch] ox-latex.el: support for pgf files
Hello, Rasmus ras...@gmx.us writes: This patch adds support for pgf files. pgf is the machine upon which tikz is build. For instance matplotlib (of Python) and printpgf (of Octave) both produces pgf files. It's just a question of recognizing the extension. With this patch the following document exports correctly: #+TITLE: PGF test #+LATEX_HEADER: \usepackage{pgf} #+BEGIN_SRC emacs-lisp :exports none (set (make-local-variable 'org-latex-pdf-process) '(xelatex -pdf %f)) #+END_SRC #+BEGIN_SRC python :results raw :exports results from matplotlib import pylab as plt x, y = plt.rand(2) plt.scatter(x, y) fig = test.pgf plt.savefig(fig) ## utf8 by default return(.join([[[file:, fig, ]]])) #+END_SRC Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] patch for htmlize.el
Yes, that is all right at least for now, please go ahead. Thanks! - Carsten On 21 mei 2013, at 02:16, Eric Schulte schulte.e...@gmail.com wrote: Hi, I'd like to commit the following patch which improves htmlize's handling of svg image overlays. I couldn't find an upstream for htmlize, is it appropriate to patch htmlize in the Org-mode source tree? Thanks, From 4611b177def45bf23c2cfb1caf0b12baa5e0e91b Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Mon, 20 May 2013 18:15:05 -0600 Subject: [PATCH] export inline svg images with htmlize --- contrib/lisp/htmlize.el | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/contrib/lisp/htmlize.el b/contrib/lisp/htmlize.el index c03d605..3bf5949 100644 --- a/contrib/lisp/htmlize.el +++ b/contrib/lisp/htmlize.el @@ -601,10 +601,12 @@ list. (htmlize-attr-escape (file-relative-name file)) alt-attr))) ((plist-get imgprops :data) - (format img src=\data:image/%s;base64,%s\%s / - (or (plist-get imgprops :type) ) - (base64-encode-string (plist-get imgprops :data)) - alt-attr) +(if (equalp (plist-get imgprops :type) 'svg) +(plist-get imgprops :data) + (format img src=\data:image/%s;base64,%s\%s / + (or (plist-get imgprops :type) ) + (base64-encode-string (plist-get imgprops :data)) + alt-attr)) (defconst htmlize-ellipsis ...) (put-text-property 0 (length htmlize-ellipsis) 'htmlize-ellipsis t htmlize-ellipsis) -- 1.8.2.3 -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]
Rasmus writes: I found a bug in that the subject variable should be a list cf. the KOMA manual. This patch fixes this. It's pretty complex for something so simple, and I might be inclined to admit to the put it in a LCO-file approach might be better. I'd really like to have a second opinion on this. Viktor? Best, Alan
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
Hi John, John Hendy wrote: On Mon, May 20, 2013 at 5:15 PM, John Hendy jw.he...@gmail.com wrote: Sorry for the long title, but that's the summary! I fired up a fresh Emacs session and used =C-a s search-term RET= to navigate to a headline in the results by putting the cursor on the line and pressing RET. The file text was all black. If I visited the file directly, I had the typical color-coded text for headlines/keywords. I decided to replicate with a minimal config, and I was able to. Here's the context of the min config: #+begin_min-config ;; set load paths ;; set load dirs and global config options (add-to-list 'load-path ~/.elisp/org.git/lisp/) (add-to-list 'load-path ~/.elisp/org.git/contrib/lisp) #+end_min-config This was on a work file, and I couldn't initially replicate with a test file... but it appears it has to do with my header options. Here's the test file: #+begin_src org #+setupfile: ~/org/aux/setupfile.org #+options: :t num:t author:t creator:nil tags:t toc:nil date:t #+latex_header: \usepackage{lscape} #+latex_header: \usepackage{amsmath} * Test headline Some paragraph just to give me a keyword to search for ** Sub headline Some more text in the next headline #+end_src My process: - emacs -Q - M-x load-file RET ~/path/to/min-config RET - C-x C-f /path/to/file.org RET - C-c [ to add to agenda list - C-x C-k RET to kill buffer - M-x org-agenda RET s RET text RET - Navigate to test.org matching line RET - File looks like attached pic I deleted everything but my #+setupfile line and it still does that. Last bit of input -- when this behavior is displayed, if I C-c C-c on my options block at the top of the file, it returns to fontified behavior and stays that way (even if meddling with headlines). It appears that navigating to a headline with various #+keyword lines is not letting Org recognize something. Refreshing the setup seems to handles this. This is on: Org-mode version 8.0.3 (release_8.0.3-139-g419b69 @ /home/jwhendy/.elisp/org.git/lisp/) Happy to try anything else or provide more info. For now, I think I've made enough noise about this! Without any #+ options at the top of the file, it appears in color. End of last week, after updating Org, I also got lots of fontification troubles inside Org buffers, but as well in more places (Gnus, in particular). I restarted Emacs many, many times, used Org in different contexts, and problems did always appear after some time (a couple of minutes, generally). I did check out an older version of Org, and all the highlighting problems are gone. Currently used version: Org-mode version 8.0.3 (release_8.0.3-114-gab3f45 @ ~/Public/Repositories/org-mode/lisp/). I did not have time yet to bisect the problem, but it _seems_ to be a newly introduced feature. Maybe you can try to check out older versions ( 10 days ago), and see whether you can replicate your problem? Best regards, Seb -- Sebastien Vauban
Re: [O] TOC in HTML export - how to change formatting of ToDo levels?
Hi David, David Rogoff wrote: I've just started diving back into org-mode. I'm mostly using it for ToDo / Status tracking. I've been trying to change the format of the TOC entries with little success. I've figured out how to use org-export-html-style to change the CSS markup for my customized ToDo levels, but that just affects the formatting in the body of the document. The table of contents appears to ignore that. I've been digging through org-html.el and the TOC formatting (around line 1474) looks to be mostly card-coded with almost no variables to control anything. Any ToDo status of done is not marked up at all and anything else is just marked as class todo instead of the actual class of the item. Am I missing something? The only solution I've found is to write a script to fix the HTML after exporting. Any better solution? It's a very big ToDo list and I (and others who will look at the document) want to see the actual status (preferably with the CSS font/text markups) in the TOC to know which items to look into for further details. You should be able to customize the todo class only within the TOC context with such a rule: --8---cut here---start-8--- #table-of-contents .todo { ... } --8---cut here---end---8--- Best regards, Seb -- Sebastien Vauban
Re: [O] Customizing Org 8.0 Export
Hi Scott, Scott Randby wrote: 2. I want to put the following in my init.el: (add-to-list 'org-latex-classes '(notesclass \\documentclass{article} (\\section{%s} . \\newsection{%s}) (\\subsection{%s} . \\newsubsection{%s}))) But when I do, I get the following on startup: Warning (initialization): An error occurred while loading `/home/srandby/.emacs.d/init.el': Symbol's value as variable is void: org-latex-classes To ensure normal operation, you should investigate and remove the cause of the error in your initialization file. Start Emacs with the `--debug-init' option to view a complete error backtrace. This means I cannot put the above code in my init.el file where I want it to be. For such cases, I do write: #+begin_src emacs-lisp ;; LaTeX back-end (eval-after-load ox-latex '(progn ;; your code... )) ;; eval-after-load ox-latex ends here #+end_src Best regards, Seb -- Sebastien Vauban
Re: [O] Best way to make/add tech diagrams/graphics?
Asymptote http://asymptote.sourceforge.net/ would also be another option in a similar vein to TikZ. On 18 May 2013 01:14, John Hendy jw.he...@gmail.com wrote: On Fri, May 17, 2013 at 6:09 PM, Marcin Borkowski mb...@wmi.amu.edu.pl wrote: Dnia 2013-05-17, o godz. 11:40:17 John Hendy jw.he...@gmail.com napisał(a): On Fri, May 17, 2013 at 10:13 AM, Lawrence Bottorff borg...@gmail.com wrote: I'd like to embed images into my running org file -- for eventual conversion to Latex or html. These would be simple diagram-style pictures such as math or technical diagrams that cannot be done with gnuplot or other formula-to-picture conversion software. Examples: http://www.library.utoronto.ca/see/SEED/Vol5-1/Queiroz_Emmeche_El-Hani_files/image003.gif http://math.ucr.edu/home/baez/irvine/SBGN_process_description_cropped.jpg A few that come to mind for this sort of thing: - ditaa: http://ditaa.sourceforge.net/ - graphviz/dot: http://www.graphviz.org/ - my personal favorite, but quite the learning curve, it PFG/TikZ: http://www.texample.net/tikz/examples/ Typo: it's PGF, not PFG, just in case you wanted to google it or something;). Oops -- typo on my part. I'd also mention Metapost, on which I believe TikZ was modeled (at least to some extent). Since you mentioned embedding in LaTeX, I'd also suggest TikZ; it has a huge manual, but /very/ well written, with quite a few tutorials and examples. One benefit is that it is tightly integrated into LaTeX, but it can also export SVG (though with a few limitations compared to the pdfLaTeX-produced output). Also, you might want to check out the gallery of TikZ examples here: http://www.texample.net/tikz/ . The examples are great. The link I provided goes right to the examples vs. that sort of home page screen which only shows the most recent couple that have been submitted. I'll have to check out metapost, as I'd not heard of that one. Thanks, John Good luck! John Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] Indentation of code blocks within lists
Hi, May I bump up this thread? Thanks, Francesco Francesco Pizzolante wrote: Hi All, I'd like to let you know about issues I'm having while trying to put source code blocks within lists. Here's my example and how I indent it: * First situation - My first bullet We need to do this: #+begin_src emacs-lisp (message this is a string) (defun x() Doc... (interactive) (message hello)) #+end_src - My second bullet #+begin_src emacs-lisp test #+end_src #+results: : test - Sub-point of second bullet We need to do this as well: #+begin_src emacs-lisp (sort) #+end_src This way if indenting code blocks has the following advantages: - it looks nice; - thanks to the indentation, you directly know at which list level the code block belongs to; - you can easily use Emacs commands (like `C-x TAB') on regions or Org promote/demote commands on items or subtrees to edit and reorganize your text: relative indentation is preserved in all cases. But, I have 2 issues with it: - when using `C-c '' (`org-edit-special'), I see spaces before my code, while I would expect to see my code starting at column 0 in the edit buffer (the reference column for the margin being, here, the column with the '#' from '#+begin_src'; - when exporting, the spaces from column 0 to the start of my code are also exported, while I would again expect these spaces to be ignored for the export. The only way I found to fix these issues is to edit my text like this (and make any code to start in column 0): - My first bullet We need to do this: #+begin_src emacs-lisp (message this is a string) (defun x() Doc... (interactive) (message hello)) #+end_src - My second bullet #+begin_src emacs-lisp test #+end_src #+results: : test - Sub-point of second bullet We need to do this as well: #+begin_src emacs-lisp (sort) #+end_src But: - as you can see, the text does not look anymore as nice as in the previous example; - I'm no longer able to edit and reorganize the text using Emacs `C-x TAB' command. That command becomes forbidden as it can't correctly respect the indentation requirements: + starting at column 0 for code; + relative for list items (depending on their depth); - even Org promote/demote commands are buggy in this case: as a simple example, when I try to promote (with M-Shift-Left) the last point Sub-point of second bullet I get an error (indent-line-to: Wrong type argument: wholenump, -2 ) and the following half-baked result: - Sub-point of second bullet We need to do this: #+begin_src emacs-lisp (sort) #+end_src The #+end_src line got misaligned. So, my question is the following: is there a way to edit my text as shown in the first example and edit/export it ignoring the margin spaces? Any help is welcome. Thanks a lot, Francesco
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Alan Schmitt alan.schm...@polytechnique.org writes: It seems there are some semantic bugs in ox-koma-letter.el in that new variables are introduces for SENDER (as opposed to AUTHOR) and a separate email variable as well. This seems like a semantic bug IMO. This patch fixes these issues if they in fact are issues. Can we still use an lco file to set these after this change? (I'll also post this on the list). You can't set #+SENDER: Which seems to be how it was set up before. You can use #+AUTHOR So if you decide to convert your document from something you'd export with the normal LaTeX exporter it would be smoother this way. Author now works the same way that it does in the LaTeX exporter (come to think of it, we probably shouldn't need to mention anything as it build on top of the LaTeX exporter anyway). Thus, unless you disable export of author it wouldn't work with a LCO file. But then we could make export of author conditional on :with-author as in ox-latex.el and you could use LCO files. The gain is that in the (for me) 99.9% of the cases where I want to send a letter in my own name the exporter just figures it out without be having to specify anything (like in the normal exporter). –Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] patch for htmlize.el
Hi Eric, Carsten Dominik carsten.domi...@gmail.com writes: Yes, that is all right at least for now, please go ahead. Please also send an email to htmlize.el's author -- I think he's reading the mailing list, but ensuring he does would be nice. Best, -- Bastien
Re: [O] GFDL
Hi Ben, Ben Finney ben+em...@benfinney.id.au writes: It bothers me mostly for the guide, where I did spend a lot of time to make it compact, and now something like one fifth of it is license text. We may actually consider to re-release the guide under a different license. Please use this as an opportunity to seriously consider relicensing the entire work (programs, documentation, etc.) of Org-mode under the same license: the GNU GPL. It does not have the special problems of the FDL, and having the whole work under the same license terms makes it simpler and clearer. Well, relicensing the Org compact guide under GNU GPL is definitely feasible, but relicensing the Org manual is (sadly) not. Let's take the feasible step first? -- Bastien
Re: [O] Effort entry and confusing effort estimates
Hi Ken, Ken Mankoff mank...@gmail.com writes: But I'm still confused what 'org-set-effort' expects/interprets compared to 'org-clock-modify-effort-estimate'. Any clarification will be much appreciated. `org-set-effort' allows you to _set_ the effort value. `org-clock-modify-effort-estimate' allows you to either set the effort value (e.g. if you enter 1:30, the old value will be replaced by this one) or to increment/decrement the effort value by using +mm or +n[hdwmy] -- e.g. entering +1d will increment the current value by 1 day. 1 day is interpreted depending on `org-effort-durations', which see. Hope this clarifies, -- Bastien
Re: [O] ical2org.py
aitor aitors2...@gmail.org writes: Hi, I've implemented a little script which converts ics files to org-mode. You can find the script here: https://github.com/asoroa/ical2org.py Aitor, I would like to try this out but, as I am not a python user, I have no idea how to get the two bits you indicate being necessary (icalendar, pytz) installed. I have installed python-dateutil and python-pycalendar as these looked the most obvious candidates for icalendar but no luck. Searching the repositories for pytz draws a blank as well. , | $ ~/git/ical2org.py/ical2org.py | Traceback (most recent call last): | File /home/ucecesf/git/ical2org.py/ical2org.py, line 5, in module | from icalendar import Calendar | ImportError: No module named icalendar | $ ` I am using Ubuntu. Anyway help would be most welcome. thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-94-g5a1400
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Rasmus writes: Alan Schmitt alan.schm...@polytechnique.org writes: It seems there are some semantic bugs in ox-koma-letter.el in that new variables are introduces for SENDER (as opposed to AUTHOR) and a separate email variable as well. This seems like a semantic bug IMO. This patch fixes these issues if they in fact are issues. Can we still use an lco file to set these after this change? (I'll also post this on the list). You can't set #+SENDER: Which seems to be how it was set up before. You can use #+AUTHOR So if you decide to convert your document from something you'd export with the normal LaTeX exporter it would be smoother this way. Author now works the same way that it does in the LaTeX exporter (come to think of it, we probably shouldn't need to mention anything as it build on top of the LaTeX exporter anyway). Thus, unless you disable export of author it wouldn't work with a LCO file. But then we could make export of author conditional on :with-author as in ox-latex.el and you could use LCO files. The gain is that in the (for me) 99.9% of the cases where I want to send a letter in my own name the exporter just figures it out without be having to specify anything (like in the normal exporter). OK, sounds good, I've applied it. Thanks, Alan
Re: [O] Effort entry and confusing effort estimates
Bastien wrote: Hi Ken, Ken Mankoff mank...@gmail.com writes: But I'm still confused what 'org-set-effort' expects/interprets compared to 'org-clock-modify-effort-estimate'. Any clarification will be much appreciated. `org-set-effort' allows you to _set_ the effort value. `org-clock-modify-effort-estimate' allows you to either set the effort value (e.g. if you enter 1:30, the old value will be replaced by this one) or to increment/decrement the effort value by using +mm or +n[hdwmy] -- e.g. entering +1d will increment the current value by 1 day. 1 day is interpreted depending on `org-effort-durations', which see. I think the problem is slightly more complicated. org-set-effort does: read some effort duration (org-entry-put nil Effort duration-we-just-read) org-clock-modify-effort-estimate does: read some effort duration (org-duration-string-to-minutes value) convert this duration in minutes back to a string (org-minutes-to-clocksum-string minutes-corresponding-to-value) (org-entry-put nil Effort duration-we-just-calculated) So org-set-effort doesn't do any conversion of the effort string we enter. org-clock-modify-effort-estimate does do conversion. However, it does it badly. org-duration-string-to-minutes always uses org-effort-durations to convert the input string to minutes. However, org-minutes-to-clocksum-string /only/ uses org-effort-durations if org-time-clocksum-use-effort-durations is non-nil (not the default). The problem boils down to: (let ((org-time-clocksum-use-effort-durations nil)) (= (org-duration-string-to-minutes 3d 2h) ;; what the user entered (org-duration-string-to-minutes ;; what gets inserted (org-minutes-to-clocksum-string (org-duration-string-to-minutes 3d 2h) = nil (let ((org-time-clocksum-use-effort-durations t)) (= (org-duration-string-to-minutes 3d 2h) ;; what the user entered (org-duration-string-to-minutes ;; what gets inserted (org-minutes-to-clocksum-string (org-duration-string-to-minutes 3d 2h) = t I would argue that (org-duration-string-to-minutes (org-minutes-to-clocksum-string (org-duration-string-to-minutes some-value))) Should be a no-op. But that is only the case if org-time-clocksum-use-effort-durations is t. Lawrence -- Lawrence Mitchell we...@gmx.li
Re: [O] ical2org.py
Eric S Fraga e.fr...@ucl.ac.uk writes: I am not a python user [...] Hi, Eric. Nobody is perfect :-). Regards, François
Re: [O] RFQ - new contribution - org-screenshot.el
Max Mikhanosha m...@openchat.com writes: At Mon, 20 May 2013 13:45:48 -0500, Russell Adams wrote: What advantages would org-screenshot provide by comparison? To me the most useful feature is actually screenshot rotation shortcuts, I also have my own screenshot tool (this was my first own addition to Org mode, soon after I started to use it, quite a while ago now!) which is intermediate in features between Russell's and Max's. One thing I like in Max's approach is this capability of doing a Dired display, in which one segregates between used screenshots and orphan ones. When a document has many screenshots, such diagnostic help eases eliminating the dead wood and staying clean overall. François
Re: [O] odt import
On Sun, 19 May 2013 19:27:49 +0200 Uwe Brauer o...@mat.ucm.es wrote: Ethan == Ethan Ligon li...@are.berkeley.edu writes: Uwe Brauer oub at mat.ucm.es writes: Uwe Brauer Presumably a reference to https://bitbucket.org/josemaria.alkala/odt2org/wiki/Home I haven't used it, and it's rather old (predates org-elements, I think). Thanks but there are now files for downloading so I presume this project is dead. Don't know anything about it but there is something to try: https://bitbucket.org/josemaria.alkala/odt2org/src Detlef
[O] Let's discuss citation and Org syntax
Hi, Now that 8.0 has shipped let's talk bibliography support. This follows directly upon the discussion around March[1]. The essence of the thread was that some people agreed that it would be nice to have support for citation commands build into Org (I'll summarize in the next post). But let me first restate my own take on the issue. IMO a nice format would be: (*) [KEYWORD PROPERTIES] I think we should allow for a more general approach than one just for citation and this is a good thing (IMO). The in-buffer display of (*) could be governed by org-buffer-format-KEYWORD (similar to gnus-user-format-function-LETTER) or just identity if no function is defined. Export could be handled by org-BACKEND-KEYWORD or org-export-KEYWORD. With officially recognized KEYWORDs something like citation could be a 'first-class citizen'. PROPERTIES could be a string like: optional-keyless-entry :prop1 one :prop2 two ... Perhaps, treatment of keyword, could even be handled by an in-buffer Org Babel function in the spirit of e.g. reproducible research (see below). This would be different from Org links in that (*) is more like a functions that allows for (i) pretty and informative display in buffer/export and (ii) easy user extension. I think there are many compelling use-cases for such a framework. 1. Citation: Take the keyword citetext which should be an 'official' KEYWORD. So for instance we could have [citetext BIBTEX-KEY :prenote note, w/comma :postnote blah]. In buffers, via org-in-buffer-format-citetext, it would be displayed as BIBTEX-KEY (note, w/comma, YEAR, blah) or something similar (depending to what extend bibtex.el would be leveraged; e.g. BIBTEX-KEY might show the author/editor key and YEAR would also depend on parsing a bibtex file) (obviouesly, there's some reference to a bibtex file somewhere). In LaTeX it would be exported as \citetext[note,w/comma][blah]{BIBTEX-KEY} In html it might utilize some tool that understand bibtex (there's a link to such a tool in the next post). In ASCII it could almost use what would be displayed in the buffer. 2. MY-FUN: MY-FUN is some function that does something with some properties, perhaps just a string (simple cases: [sc text] is used for small caps, or mayhaps [my-treat-dna-string DNA-STRING]). I might use it in a single file that I want to send to people or I might just use it in my notes. Currently it's implemented via org-emphasis-alist or as a link. Changing emphases is a hacks, and they are hard to export with the now more robust Org syntax and further permit little control over how they are displayed in-buffer. Links are more flexible but lacks display control and becomes somewhat painful with many arguments[2]. Also, MY-FUN doesn't take a 'description'. With (*) I could simply write [MY-FUN PROPERTIES]. Perhaps, I could even define org-BACKEND-MY-FUN in a babel block if it's only relevant to the current file. There's been some work and some discussion on this already, most notably Aaron already supplied some patches towards this end[3], but using a slightly different syntax more like the link syntax; e.g. textcite above would look like [[textcite:bibtex-keypre%3Dfoopost%3Dbar][whatever]] where whatever is ignored. The state of the discussion is to some extend summarized in the next post. It would love to hear whether other people find something like this to be a good idea? Would anyone find a use such a framework? Would (*) conflict with anyone's current usage of Org? Is (*) too ambitious and in terms of getting citation support? Is this is taking a musket to kill a butterfly? What are the the flaws in the above. I'm not a good (lisp) programmer, but I think I have a month off this summer where I could work on something like the above. Thanks for reading, Rasmus Footnotes: [1] http://mid.gmane.org/20130303070635.GA12112%40panahar [2] my citation links often look like postnote;prenote without showing the BIBTEX-KEY or citation format. [2] here http://mid.gmane.org/87lia0s7wi.fsf%40bzg.ath.cx and here http://mid.gmane.org/87wqthk7vj.fsf%40gmail.com. -- When in doubt, do it!
Re: [O] Effort entry and confusing effort estimates
Hi Lawrence, Lawrence Mitchell we...@gmx.li writes: I would argue that (org-duration-string-to-minutes (org-minutes-to-clocksum-string (org-duration-string-to-minutes some-value))) Should be a no-op. But that is only the case if org-time-clocksum-use-effort-durations is t. Agreed. Thanks for the clear explanations. Can you provide a patch to get the correct behavior? At the time, I could not closely watch the side-effect of introducing `org-time-clocksum-use-effort-durations' and this is clearly one of them. Thanks in advance! -- Bastien
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Alan Schmitt alan.schm...@polytechnique.org writes: OK, sounds good, I've applied it. Thanks. Let's wait with the rest till Vicktor's had a chance to look over it. –Rasmus -- Summon the Mothership!
Re: [O] using gnuplot's splot and every commands on org-mode table data
Achim Gratz strom...@nexgo.de writes: [...] I've implemented calculation separators that register as hlines for table formulas, but are ignored when row groups are constructed for export. Your example table would then look like this: Achim, just to apologise for not getting back to you earlier on this. I've been swamped with work. I'll try to have a test of your table updates this week! thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.3-144-gf1b99a
Re: [O] RFQ - new contribution - org-screenshot.el
On Tue, May 21, 2013 at 08:03:45AM -0400, François Pinard wrote: I also have my own screenshot tool (this was my first own addition to Org mode, soon after I started to use it, quite a while ago now!) which is intermediate in features between Russell's and Max's. I can't take credit, that snippet has floated around on the ML for a while and I only changed the filename format to suit my tastes. Thanks. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [O] patch for htmlize.el
Bastien b...@gnu.org writes: Hi Eric, Carsten Dominik carsten.domi...@gmail.com writes: Yes, that is all right at least for now, please go ahead. Done Please also send an email to htmlize.el's author -- I think he's reading the mailing list, but ensuring he does would be nice. Done, Thanks, Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Let's discuss citation and Org syntax
A lot of people more clever than me have thought about this topic. Here I'll just summarize the org-exp-bibtex missing in git?-thread. The ordering more or less follows how it was displayed in my Gnus. I've tried to stay honest to the people I've quoted and hopefully I've not failed too badly. Also, I hope I've not forgotten valuable suggestions. I've not quoted Thomas, but he gave some insights of what one would want in citation here http://mid.gmane.org/m1a9qczekf.fsf%40tsdye.com. There were approximately three types of suggestions: 1. the new-type approach, which I've tried to generalize more above. Aaron made valueable suggestions here. Nicolas gave it some support. 2. The extending link approach, notably Bastien, Andreas and Aaron even supplied patches! I've also included some quick references to the current frontier using links. Lastly, there's some links to implementation in other formats. The new-type approach - Nicolas: #+BEGIN_QUOTE It would be good to integrate citations in export framework [...] Maybe something like [cite:]. org-element could parse this, and ox.el provide some tools to access data. Then each back-end could deal with them. [...] I favor [cite:PROPERTIES] over [[cite:PROPERTIES]], because the latter (link syntax) implies a (optional) description part. I don't think a description is ever meaningful in citations. #+END_QUOTE Ref: http://mid.gmane.org/87ehfwwgdd.fsf%40gmail.com and http://mid.gmane.org/874ngkzjt6.fsf%40gmail.com - Much of my discussion in the previoues post is similar to Aaron's response to my original post #+BEGIN_QUOTE So, a citation like [cite:doi:parens:some-doi:key=valkey2=val2] would be displayed by: 1. call (org-lookup-cite-doi some-doi) - (:author Foo :title bar ...) 2. call (org-display-cite-parens '(:author Foo :title bar ...)) - (Foo 2000) 3. (font-lock puts an overlay over the citation markup, with the returned string) If you click on the citation, org would open the location (URL or local file) returned by (org-resolve-cite-doi some-doi) A citation could exported by calling (org-export-cite-parens 'doi some-doi (:author foo :title bar) current-backend). This function could just return \parencite{foo} if exporting to latex and the citation was already in a bibtex file. But it could also just return “Foo 2000” as a static string for dumb backends like ASCII, or write the information to a temporary bibtex file (so that latex can atomatically use the bibliographic info looked up from a DOI citation). #+END_QUOTE Ref: http://mid.gmane.org/87txolk7qk.fsf%40gmail.com - Jamuthan's take on viewing citation as footnotes #+BEGIN_QUOTE I view Citations as closer to Footnotes. The syntax should parallels footnotes syntax. 1. PROPERTIES should be opaque to Org. It is a key or a list of keys possibly bibtex but Org doesn't take stand on how it looks like. 2. There will be a org-BACKEND-citation-reference. 3. There will be a org-BACKEND-bibliography. 2, 3 more likely with interface with respective citation processor (citation processor as opposed to a database) via CLI. Citation processor could be whatever org-exp-bibtex interfaces with right now. I also have some proof-of-concept - see zotcite - for zotero. 2, 3 will parallel footnote-reference and footnote-section callbacks in HTML backend. 4. Footnotes can be introduced with either fn: prefix or cite: prefix. There should be a way to put fn: and cite: in same enumeration context. There should be a way to put fn: and cite: in different enumeration context. The former case could be a degenerate mode where Org can transcode what is seen in the buffer where everything is footnotes. The latter case will result in Citations and Bibliography being generated by the above backend transcoders. 5. Citation definitions in Org buffer will be *ignored*. (It could be considered when the exporter works in a degenerate footnote only mode where plain text transcoding is resorted to because there is no suitable application available for the backend format.) Plain text citation definitions are only to help the author have a glimpse of what he is doing, it has only UI-value but no contents value. 6. There may be an advisory citation style - say APA, Chicago etc - which the backends may honor or ignore. #+END_QUOTE The extend-link suggestions: - Andreas Leha suggest something like what I suggested above, but extending upon the link syntax. What I agree strongly with is: citations are more than links but also include information on formatting
Re: [O] GFDL
Hi Bastien, Bastien wrote: Ben Finney ben+em...@benfinney.id.au writes: It bothers me mostly for the guide, where I did spend a lot of time to make it compact, and now something like one fifth of it is license text. We may actually consider to re-release the guide under a different license. Please use this as an opportunity to seriously consider relicensing the entire work (programs, documentation, etc.) of Org-mode under the same license: the GNU GPL. It does not have the special problems of the FDL, and having the whole work under the same license terms makes it simpler and clearer. Well, relicensing the Org compact guide under GNU GPL is definitely feasible, but relicensing the Org manual is (sadly) not. Let's take the feasible step first? FMI, why is GNU GPL not applicable to the manual? Best regards, Seb -- Sebastien Vauban
Re: [O] Effort entry and confusing effort estimates
Hi Bastien, On Tue, 21 May 2013, Bastien wrote: Ken Mankoff mank...@gmail.com writes: But I'm still confused what 'org-set-effort' expects/interprets compared to 'org-clock-modify-effort-estimate'. Any clarification will be much appreciated. `org-set-effort' allows you to _set_ the effort value. `org-clock-modify-effort-estimate' allows you to either set the effort value (e.g. if you enter 1:30, the old value will be replaced by this one) or to increment/decrement the effort value by using +mm or +n[hdwmy] -- e.g. entering +1d will increment the current value by 1 day. 1 day is interpreted depending on `org-effort-durations', which see. Thanks for the explanation. I guess I'm confused why one formats/converts/checks the input and the other does not. I guess this doesn't imply that org-set-effort does anything different, it really is just a pure subset of org-clock-modify-effort-estimate. Thanks, -k.
Re: [O] ical2org.py
Eric S Fraga e.fr...@ucl.ac.uk writes: aitor aitors2...@gmail.org writes: Hi, I've implemented a little script which converts ics files to org-mode. You can find the script here: https://github.com/asoroa/ical2org.py Aitor, I would like to try this out but, as I am not a python user, I have no idea how to get the two bits you indicate being necessary (icalendar, pytz) installed. I have installed python-dateutil and python-pycalendar as these looked the most obvious candidates for icalendar but no luck. Searching the repositories for pytz draws a blank as well. I got iCalendar from https://pypi.python.org/pypi/icalendar, untarred it and ran `sudo python setup.py install' Got pytz from https://pypi.python.org/pypi/pytz/. It comes as an egg file so you just run `sudo easy-install pytz-2013b-py2.7.egg' This command should get you going: `./ical2org.py input.ics output.org Hope this helps, Guido -- Ever since prehistoric times, wise men have tried to understand what, exactly, make people laugh. That's why they were called wise men. All the other prehistoric people were out puncturing each other with spears, and the wise men were back in the cave saying: How about: Would you please take my wife? No. How about: Here is my wife, please take her right now. No. How about: Would you like to take something? My wife is available. No. How about ... -- Dave Barry, Why Humor is Funny
Re: [O] GFDL
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: FMI, why is GNU GPL not applicable to the manual? While I would have long to say, here, I rather censor myself, mostly. I sometimes happen to think that the GDFL happened not so long after Richard Stallman and I had a harsh and long dispute about the GNU tar manual. In short, I wanted to publish it, Richard wanted that I refrain from doing so: he expected the manual to be a source of FSF revenue. The GDFL wording opens the door to Richard's restrictions, while the GPL, which I used, is more in the spirit of the remainder of the FSF. GNU tar has it own set of technical difficulties, and I hope I've been able to put it back on track so it became maintainable again. But in many non-technical ways, GNU tar has been an administrative nightmare. François
Re: [O] RFQ - new contribution - org-screenshot.el
Max Mikhanosha m...@openchat.com writes: Hi All, I've been writing some documentation in OrgMode with screenshots, and as with any screenshot taking, it takes a while to get one just right. A few tiny helper utilities, quickly snowballed into this :-) It may need some cleanup, but IMHO its too awesome not to share it with the list. To try it out, you'll need /usr/bin/scrot which is available as scrot package on most distributions. Cool. Can you make this a bit portable. On Mac OSX, the utility is called screencapture, and can be run with the same flags. Here is a piece of code that was published earlier with a sample use. http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 , | #+BEGIN_SRC emacs-lisp | (defun paste-clipboard-to-file (optional filename temp-dir) | Take a screenshot using the crosshairs and saveit to FILENAME, | if it is given or to a temp file in the TEMP-DIR | directory. Then add an orgmode style link at point. | (interactive) | (let* ((temporary-file-directory (or temp-dir images)) |(fname (or filename (make-temp-file img nil .jpg | (call-process-shell-command (concat | /usr/sbin/screencapture -s fname)) | (insert \n[[file: fname ]]) | (org-display-inline-images))) | ;; | (global-set-key (kbd C-c p) 'paste-clipboard-to-file) | | #+END_SRC ` Regards, -- Haider
Re: [O] Customizing Org 8.0 Export
On 05/21/2013 01:25 AM, John Hendy wrote: On May 20, 2013 9:03 PM, Scott Randby sran...@gmail.com wrote: Is there any way to make all of org's variables available for customization on startup? Yes, see the original exporter announcement: http://article.gmane.org/gmane.emacs.orgmode/65574 Section 3.0 calls out two methods of setting available backends. I'm guessing you are customizing org-export-backends vs (require 'ox-backend). Try requiring the backend and all associated variables will be there on startup. John Thanks for the solution. This is the second time in a row I've been referred to the original exporter announcement. I'm sorry that my questions are so basic, but I put off switching to 8.0 because my understanding of how org and Emacs work is not very deep and I know little elisp. Once I have things set up, I leave them alone and get to work. I'm very grateful to this list for helping me figure out things that, in hindsight, are obvious. Scott Randby
Re: [O] GFDL
On 21 mei 2013, at 15:34, François Pinard pin...@iro.umontreal.ca wrote: Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: FMI, why is GNU GPL not applicable to the manual? While I would have long to say, here, I rather censor myself, mostly. I sometimes happen to think that the GDFL happened not so long after Richard Stallman and I had a harsh and long dispute about the GNU tar manual. In short, I wanted to publish it, Richard wanted that I refrain from doing so: he expected the manual to be a source of FSF revenue. The GDFL wording opens the door to Richard's restrictions, I am curious, what passage does make such restrictions possible, and which kinds of restrictions? - Carsten while the GPL, which I used, is more in the spirit of the remainder of the FSF. GNU tar has it own set of technical difficulties, and I hope I've been able to put it back on track so it became maintainable again. But in many non-technical ways, GNU tar has been an administrative nightmare. François
Re: [O] Customizing Org 8.0 Export
On Tue, May 21, 2013 at 8:53 AM, Scott Randby sran...@gmail.com wrote: On 05/21/2013 01:25 AM, John Hendy wrote: On May 20, 2013 9:03 PM, Scott Randby sran...@gmail.com wrote: Is there any way to make all of org's variables available for customization on startup? Yes, see the original exporter announcement: http://article.gmane.org/gmane.emacs.orgmode/65574 Section 3.0 calls out two methods of setting available backends. I'm guessing you are customizing org-export-backends vs (require 'ox-backend). Try requiring the backend and all associated variables will be there on startup. John Thanks for the solution. This is the second time in a row I've been referred to the original exporter announcement. I'm sorry that my questions are so basic, but I put off switching to 8.0 because my understanding of how org and Emacs work is not very deep and I know little elisp. Once I have things set up, I leave them alone and get to work. I'm very grateful to this list for helping me figure out things that, in hindsight, are obvious. No problem, and I wouldn't say it was *that* obvious :) I found this document extremely helpful: - http://orgmode.org/worg/org-8.0.html I also started (and should really update again/maintain!) this as a landing place for documenting other things as they come up: - http://orgmode.org/worg/exporters/ox-overview.html And have a blog post walking through setting things up here, if it helps: - http://jwhendy.blogspot.com/2013/03/migrating-to-new-org-mode-exporter-org.html Good luck! We're all learning here, so no worries on the mailing list. More things for Google to index for users stumbling on this after you! John Scott Randby
Re: [O] GFDL
Carsten Dominik carsten.domi...@gmail.com writes: I am curious, what passage does make such restrictions possible, and which kinds of restrictions? Oh, I did not read the GFDL in quite a years, and really have no interest in diving and scrutinizing it again :-). More away I am from all this, better I feel :-). Sorry, just forget I've written this morning, I was likely in some strange mood. I do love the FSF idea and theory, and supported the GNU project in an intense way for maybe more than twenty years. But by now, in practice, I just cannot stand their slightest abuse, anymore. I'm all for programming freedom, but this ought to include programmer freedom too! François
Re: [O] ical2org.py
On Tue, May 21, 2013 at 03:10:51PM +0200, Guido Van Hoecke wrote: I got iCalendar from https://pypi.python.org/pypi/icalendar, untarred it and ran `sudo python setup.py install' Got pytz from https://pypi.python.org/pypi/pytz/. It comes as an egg file so you just run `sudo easy-install pytz-2013b-py2.7.egg' This command should get you going: `./ical2org.py input.ics output.org Hi Guido, thanks for the help! If the script gets enough interest I can sort out an easy installation method for it. best, aitor
Re: [O] Customizing Org 8.0 Export
On 05/21/2013 10:48 AM, John Hendy wrote: On Tue, May 21, 2013 at 8:53 AM, Scott Randby sran...@gmail.com wrote: On 05/21/2013 01:25 AM, John Hendy wrote: On May 20, 2013 9:03 PM, Scott Randby sran...@gmail.com wrote: Is there any way to make all of org's variables available for customization on startup? Yes, see the original exporter announcement: http://article.gmane.org/gmane.emacs.orgmode/65574 Section 3.0 calls out two methods of setting available backends. I'm guessing you are customizing org-export-backends vs (require 'ox-backend). Try requiring the backend and all associated variables will be there on startup. John Thanks for the solution. This is the second time in a row I've been referred to the original exporter announcement. I'm sorry that my questions are so basic, but I put off switching to 8.0 because my understanding of how org and Emacs work is not very deep and I know little elisp. Once I have things set up, I leave them alone and get to work. I'm very grateful to this list for helping me figure out things that, in hindsight, are obvious. No problem, and I wouldn't say it was *that* obvious :) I found this document extremely helpful: - http://orgmode.org/worg/org-8.0.html I also started (and should really update again/maintain!) this as a landing place for documenting other things as they come up: - http://orgmode.org/worg/exporters/ox-overview.html And have a blog post walking through setting things up here, if it helps: - http://jwhendy.blogspot.com/2013/03/migrating-to-new-org-mode-exporter-org.html Thanks for these links. I have been to the org-8.0.html page before, but I only read part of it. If I would just read through all these nice pages, then there would be no problem setting things up. But my approach to Emacs and org is rather haphazard --- I pick up those things I need and ignore all the rest. My init.el file is a sorry mess. One of these days I'll go through everything methodically. Good luck! We're all learning here, so no worries on the mailing list. More things for Google to index for users stumbling on this after you! Yes, this list is great. I've asked simple questions on other lists and received nasty RTFM responses. John Scott Randby
Re: [O] RFQ - new contribution - org-screenshot.el
Haider Rizvi hari...@gmail.com writes: Max Mikhanosha m...@openchat.com writes: Hi All, I've been writing some documentation in OrgMode with screenshots, and as with any screenshot taking, it takes a while to get one just right. A few tiny helper utilities, quickly snowballed into this :-) It may need some cleanup, but IMHO its too awesome not to share it with the list. To try it out, you'll need /usr/bin/scrot which is available as scrot package on most distributions. Cool. Can you make this a bit portable. On Mac OSX, the utility is called screencapture, and can be run with the same flags. Here is a piece of code that was published earlier with a sample use. It's a good idea, import has nearly same feature as scrot and should work with org-screenshot ,it is included imagemagick https://wiki.archlinux.org/index.php/Taking_a_Screenshot http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 , | #+BEGIN_SRC emacs-lisp | (defun paste-clipboard-to-file (optional filename temp-dir) | Take a screenshot using the crosshairs and saveit to FILENAME, | if it is given or to a temp file in the TEMP-DIR | directory. Then add an orgmode style link at point. | (interactive) | (let* ((temporary-file-directory (or temp-dir images)) |(fname (or filename (make-temp-file img nil .jpg | (call-process-shell-command (concat | /usr/sbin/screencapture -s fname)) | (insert \n[[file: fname ]]) | (org-display-inline-images))) | ;; | (global-set-key (kbd C-c p) 'paste-clipboard-to-file) | | #+END_SRC ` Regards, --
Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]
Hi, Alan Schmitt wrote: Rasmus writes: I found a bug in that the subject variable should be a list cf. the KOMA manual. This patch fixes this. It's pretty complex for something so simple, and I might be inclined to admit to the put it in a LCO-file approach might be better. I'd really like to have a second opinion on this. Viktor? I think this patch is great simply from the usability standpoint of being able to configure the behavior through customize (which I don't generally use, but admit that it's a good thing). I found a few issues though: 1. Choosing `No export' in customize results `\KOMAoption{subject}{nil}'. 2. It is not possible to set a subject format in the LCO file because if `org-koma-letter-subject-format' is set, the KOMA option will be overwritten explicitly, and if it is set to `nil' then the subject is inhibited altogether. This is actually a problem with the old code as well. One way out of this is to only print the subject line (i.e., `\setkomavar{subject}{.}' if `org-koma-letter-subject-format' is nil and and fix `noexport' to hide the subject (i.e., inhibit `\setkomavar{subject}{.}'). Is this the entended behaviour? I'll try to post a patch for this later tonight. 3. I'm not a big fan of the parentheses in the subject:(.) syntax, but if that's required to use an option list with multiple values I think it's okay. It would be nice to be able to specify a single value without the parens, but it's not a high priority (and I don't know how to do that). Cheers, Viktor Best, Alan
Re: [O] GFDL
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: FMI, why is GNU GPL not applicable to the manual? Because the manual is part of GNU Emacs, which is part of the GNU project, and every project in the GNU project is required to publish manuals in GNU FDL only. Dual licensing is not an option here. There are many discussions about this... a can of (dead) worms. -- Bastien
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
Hi Sébastien and John, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: I did not have time yet to bisect the problem, but it _seems_ to be a newly introduced feature. Can you check if the problems persist *before* this commit? http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=b83c03 -- Bastien
[O] [OT] Contributors to org.texi (was: GFDL)
Sebastien Vauban sva-n...@mygooglest.com writes: Bastien wrote: Well, relicensing the Org compact guide under GNU GPL is definitely feasible, but relicensing the Org manual is (sadly) not. Let's take the feasible step first? FMI, why is GNU GPL not applicable to the manual? Hehe, on an unrelated side note, that made me curious: Who did actually end up in org.texi, and how would I start to find out? 0. $ git blame -C -C -M -e org.texi ~/git-blame.txt (I searched the web for that ;) 1. We are only interested in the email addresses, so quick clean up with a keyboard macro. 2. Get rid of duplicates: M-x sort-lines C-x h M-x shell-command-on-region uniq And... I see 67 different addresses. Some clearly belong to one person, so getting rid of the obvious ones my count goes down to ... 58? Wow... Fun. Back to work :) Memon
Re: [O] RFQ - new contribution - org-screenshot.el
Feng Shu tuma...@gmail.com writes: Haider Rizvi hari...@gmail.com writes: Max Mikhanosha m...@openchat.com writes: scrot screencapture import (imagemagick) https://wiki.archlinux.org/index.php/Taking_a_Screenshot http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 Thanks for these links! :-) François
Re: [O] [patch] ox-koma-letter.el: credit [3/4]
Hi, Rasmus wrote: This is probably the most fun change. It adds special tags PS, ENCL, CC, AFTER_CLOSING as in my last patch set, but it uses heading this time. E.g. ENCLs are under the heading * ENCL :ENCL:. This was suggested by Nicolas, and it's nicer. The ideas comes from ox-groff.el file ¹. Thanks Luis! This is great! A few things: - It doesn't work because `org-koma-letter-special-content' is set to nil at the beginning of `org-koma-letter-template'. Why is that? If I comment it out everything works. - The function `org-koma-letter--get-tagged-content' does not use the `info' argument. Also, the function is not documented. - The second argument of `org-koma-letter-headline' is misspelled (`conents'). - I would remove the formatting from org-koma-letter-ps-prefix and put it in the docstring, simply because the separators for \encl and \cc are also not formatted in the KOMA-Script defaults. One thing I'd like to discuss is whether to adopt headings for TO and FROM also. The Groff exporter already does so for it's letters. The main benefit is that it allows for org-syntax. IMO it's a lot nicer to look at as well. Check the org-groff site in the footnote for an example. I am not sure about this. I often write a letter below a task in my Org files so I rely on exporting the subtree only. So I would have to put the TO address below the letter text which looks weird, but is doable. On the other hand, being able to use Org syntax and not have to escape linebreaks with `\\' is a big plus. I'd be happy to look into this the next time I have a free day for programming if you guys (also) find in a more appealing. (One additional benefit would be that for simple documents it wouldn't matter whether groff or scrlttr2 was used as backend). This would be a nice advantage. Maybe both options could be supported. I.e., use a FROM headline if available, but fall back on option lines if not? Or is this too confusing for users? Cheers, Viktor –Rasmus Footnotes: ¹ http://orgmode.org/worg/org-tutorials/org-e-groff-documentation.html#sec-1-5 -- Powered by magic pixies! From eeaa129b6807465566be881b96a94e14706c9a28 Mon Sep 17 00:00:00 2001 From: rasmus.pank rasmus.p...@gmail.com Date: Sun, 19 May 2013 21:50:14 +0200 Subject: [PATCH 3/4] Added support for after closing and after document entities in ox-koma-letter. * ox-koma-letter.el (org-koma-letter-special-tags-after-closing): specials tags inserted after =\end{closing}= * ox-koma-letter.el (org-koma-letter-special-tags-other): other special tags * ox-koma-letter.el (org-koma-letter-special-tags): collect the two previoues lists (this might be done in a wrong way). * ox-koma-letter.el (org-koma-letter-ps-prefix): a prefix for PS since scrlttr does not provide it. * ox-koma-letter.el (org-koma-letter-headline): stores content in a special list if it is =`org-koma-letter-special-tags'= as in ox-groff. Only returns contents if not tags not in special tags. * ox-koma-letter.el (org-koma-letter-special-content): holds special content temporarily. * ox-koma-letter.el (org-koma-letter-template): added support for the headings with special tags. The following example will now export a sensible manner. * my letter here's a letter * PS :PS: it's requires this patch * CC :CC: Nicolas, Viktor and Alan * ENCL :ENCL: many patches 1. this patch 2. another patch. * include patches :AFTER_LETTER: \myspecial macro Namely, content of PS, ENCL and CC headings will be exported after \closing{.} in the order prescribed by =`org-koma-letter-special-tags-after-closing'=. The concent of the =AFTER_LETTER= heading will be inserted after =\end{letter}=, ideal for e.g. =pdfpages= commands. --- contrib/lisp/ox-koma-letter.el | 86 +++--- 1 file changed, 81 insertions(+), 5 deletions(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index 77d21c7..8ae9fc5 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -183,6 +183,29 @@ Use `foldmarks:true' to activate default fold marks or :group 'org-export-koma-letter :type 'boolean) +(defcustom org-koma-letter-ps-prefix \\textsc{ps}: + The prefix of PS. Used to construct PS as \PS-SUFFIX PS\ + :group 'org-export-koma-letter + :type 'string) + + +(defconst org-koma-letter-special-tags-after-closing + '(PS ENCL CC) + Headers tags to be inserted after closing) + +(defconst org-koma-letter-special-tags-other + '(FROM AFTER_LETTER) + Headers tags to be inserted after closing) + +(defconst org-koma-letter-special-tags + (append org-koma-letter-special-tags-other + org-koma-letter-special-tags-after-closing) + Header tags with special meaning) + +(defvar org-koma-letter-special-content nil holds special +content temporarily.) + + ;;; Define Back-End @@ -198,15 +221,18 @@ Use
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Hi, Rasmus wrote: Alan Schmitt alan.schm...@polytechnique.org writes: OK, sounds good, I've applied it. Actually, this patch does break LCO files. Now, if you don't set AUTHOR or EMAIL in the letter the default options from the LaTeX exporter always overwrite the settings defined in LCO files. Rasmus, couldn't you just set the old `org-koma-letter-sender' option if you don't use LCO files? Also, I agree that SENDER should have been called AUTHOR. It was a workaround because the LaTeX backend would ignore nil values for AUTHOR in derived backends (but not for EMAIL, so I kept this). This should now have been fixed. Let's wait with the rest till Vicktor's had a chance to look over it. Hmm, not fast enough. :-) Cheers, Viktor –Rasmus -- Summon the Mothership!
Re: [O] [patch] ox-koma-letter.el: credit [1/4]
Hi, Rasmus wrote: This one just updates the credit: most importantly with Viktor. Cool, thanks! - Is it me or is there no option to have git send-email just fix a the subject and heads and let the email program do the rest?! The manual and various blog post did not reveal how on earth to get it to just use Gnus for sending. . . The program seems not really to follow the Unix principle. . . I use format-patch to create the patch and send them manually. But getting send-email to work would automate some things. Cheers, Viktor
Re: [O] [patch] ox-koma-letter.el: credit [3/4]
Viktor, Good to hear from you! This is probably the most fun change. It adds special tags PS, ENCL, CC, AFTER_CLOSING as in my last patch set, but it uses heading this time. E.g. ENCLs are under the heading * ENCL :ENCL:. This was suggested by Nicolas, and it's nicer. The ideas comes from ox-groff.el file ¹. Thanks Luis! This is great! A few things: - It doesn't work because `org-koma-letter-special-content' is set to nil at the beginning of `org-koma-letter-template'. Why is that? If I comment it out everything works. Hmm, it should be populated by the headline function each time. . . That is at least the idea. I.e. - When exporting `org-koma-letter-special-content' gets populated and is available until next export. - When exports run again stuff might have changed so I want to repopulate the variable. Perhaps I had loaded some magic in Emacs when I tested it that wasn't preserved in the patch. I'll test it again ASAP. - The function `org-koma-letter--get-tagged-content' does not use the `info' argument. Also, the function is not documented. No it doesn't use info. I guess it's just for consistency. It's more or less taken from ox-groff. I don't mind removing it. - The second argument of `org-koma-letter-headline' is misspelled (`conents'). Thanks! - I would remove the formatting from org-koma-letter-ps-prefix and put it in the docstring, simply because the separators for \encl and \cc are also not formatted in the KOMA-Script defaults. So you'd set org-koma-letter-ps-prefix to nil or ? The thing is, in scrlttr2 does not add a ps-prefix by itself, which seems inconsistent. So with your suggesting we'd get a more vanilla feel, which I guess would normally be nice, but here somehow feel inconsistent to me. I'm happy to oblige on this issue. One thing I'd like to discuss is whether to adopt headings for TO and FROM also. The Groff exporter already does so for it's letters. The main benefit is that it allows for org-syntax. IMO it's a lot nicer to look at as well. Check the org-groff site in the footnote for an example. I am not sure about this. I often write a letter below a task in my Org files so I rely on exporting the subtree only. So I would have to put the TO address below the letter text which looks weird, but is doable. On the other hand, being able to use Org syntax and not have to escape linebreaks with `\\' is a big plus. Maybe both options could be supported. I.e., use a FROM headline if available, but fall back on option lines if not? Or is this too confusing for users? The reason why I didn't add it as this point is that I'd want to keep it 'backward compatible' and I had to think about it. I was toying with introducing a =:with-legacy= variable that would govern which of =* TO :TO:= and =#+TO_ADDRESS= would be printed if both are present. What do you think? Thanks for your comments. –Rasmus -- The Kids call him Billy the Saint
Re: [O] RFQ - new contribution - org-screenshot.el
Hi, Haider Rizvi wrote: Max Mikhanosha m...@openchat.com writes: Hi All, I've been writing some documentation in OrgMode with screenshots, and as with any screenshot taking, it takes a while to get one just right. A few tiny helper utilities, quickly snowballed into this :-) It may need some cleanup, but IMHO its too awesome not to share it with the list. To try it out, you'll need /usr/bin/scrot which is available as scrot package on most distributions. Cool. Can you make this a bit portable. On Mac OSX, the utility is called screencapture, and can be run with the same flags. Attached is a very first try at making org-screenshot run on OS X. Many open issues remain: - Clicking in a window will not take a screenshot using `screencapture -s' but aborts the process altogether and does not create a file. To capture a window one has to use `screencapture -w'. Another option is to use `screencapture -i' and toggle between window and selection mode using the space bar. The problem with this approach is that hitting the control key will place the screenshot into the clipboard and not create a file either. - Delay does not work because `screencapture -d' has a different meaning. To delay a screenshot, one has to use `screencapture -T'. Cheers, Viktor Here is a piece of code that was published earlier with a sample use. http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 , | #+BEGIN_SRC emacs-lisp | (defun paste-clipboard-to-file (optional filename temp-dir) | Take a screenshot using the crosshairs and saveit to FILENAME, | if it is given or to a temp file in the TEMP-DIR | directory. Then add an orgmode style link at point. | (interactive) | (let* ((temporary-file-directory (or temp-dir images)) |(fname (or filename (make-temp-file img nil .jpg | (call-process-shell-command (concat | /usr/sbin/screencapture -s fname)) | (insert \n[[file: fname ]]) | (org-display-inline-images))) | ;; | (global-set-key (kbd C-c p) 'paste-clipboard-to-file) | | #+END_SRC ` Regards, -- Haider
Re: [O] RFQ - new contribution - org-screenshot.el
Forgot to attach the patch in my last mail. Sorry about the double posting. Viktor Rosenfeld wrote: Hi, Haider Rizvi wrote: Max Mikhanosha m...@openchat.com writes: Hi All, I've been writing some documentation in OrgMode with screenshots, and as with any screenshot taking, it takes a while to get one just right. A few tiny helper utilities, quickly snowballed into this :-) It may need some cleanup, but IMHO its too awesome not to share it with the list. To try it out, you'll need /usr/bin/scrot which is available as scrot package on most distributions. Cool. Can you make this a bit portable. On Mac OSX, the utility is called screencapture, and can be run with the same flags. Attached is a very first try at making org-screenshot run on OS X. Many open issues remain: - Clicking in a window will not take a screenshot using `screencapture -s' but aborts the process altogether and does not create a file. To capture a window one has to use `screencapture -w'. Another option is to use `screencapture -i' and toggle between window and selection mode using the space bar. The problem with this approach is that hitting the control key will place the screenshot into the clipboard and not create a file either. - Delay does not work because `screencapture -d' has a different meaning. To delay a screenshot, one has to use `screencapture -T'. Cheers, Viktor Here is a piece of code that was published earlier with a sample use. http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 , | #+BEGIN_SRC emacs-lisp | (defun paste-clipboard-to-file (optional filename temp-dir) | Take a screenshot using the crosshairs and saveit to FILENAME, | if it is given or to a temp file in the TEMP-DIR | directory. Then add an orgmode style link at point. | (interactive) | (let* ((temporary-file-directory (or temp-dir images)) |(fname (or filename (make-temp-file img nil .jpg | (call-process-shell-command (concat | /usr/sbin/screencapture -s fname)) | (insert \n[[file: fname ]]) | (org-display-inline-images))) | ;; | (global-set-key (kbd C-c p) 'paste-clipboard-to-file) | | #+END_SRC ` Regards, -- Haider From 5938b848f4b9b30b25c903e3487834f9400f6ad9 Mon Sep 17 00:00:00 2001 From: Viktor Rosenfeld listuse...@gmail.com Date: Tue, 21 May 2013 19:32:16 +0200 Subject: [PATCH] org-screenshot: Let user configure capture program. * org-screenshot.el (org-screenshot-capture-binary): Configure the binary to capture a screenshot. (org-screenshot-take): Do not use hardcoded `scrot' binary. --- contrib/lisp/org-screenshot.el | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/contrib/lisp/org-screenshot.el b/contrib/lisp/org-screenshot.el index a54cb8f..54c8074 100644 --- a/contrib/lisp/org-screenshot.el +++ b/contrib/lisp/org-screenshot.el @@ -85,6 +85,11 @@ Options for taking and managing screen-shots :group 'org-link) +(defcustom org-screenshot-capture-binary scrot + Binary to capture screen contents. Use `scrot' on Linux and `screencapture' on Mac OS X. + :type 'string + :group 'org-screenshot) + (defcustom org-screenshot-image-directory ./images/ Directory in which screenshot image files will be stored, it be automatically created if it does't already exist. @@ -307,7 +312,7 @@ screenshot is done, any more `C-u' after that increases delay by (or (apply 'start-process (append - (list scrot *scrot* scrot -s path) + (list scrot *scrot* org-screenshot-capture-binary -s path) (when (plusp delay) (list -d (format %d delay) (error Unable to start scrot process))) -- 1.8.2.3
Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]
Viktor Rosenfeld listuse...@gmail.com writes: I found a bug in that the subject variable should be a list cf. the KOMA manual. This patch fixes this. It's pretty complex for something so simple, and I might be inclined to admit to the put it in a LCO-file approach might be better. I'd really like to have a second opinion on this. Viktor? I think this patch is great simply from the usability standpoint of being able to configure the behavior through customize (which I don't generally use, but admit that it's a good thing). I found a few issues though: 1. Choosing `No export' in customize results `\KOMAoption{subject}{nil}'. Thanks, that's a bug. I'll look into it ASAP. 2. It is not possible to set a subject format in the LCO file because if `org-koma-letter-subject-format' is set, the KOMA option will be overwritten explicitly, and if it is set to `nil' then the subject is inhibited altogether. This is actually a problem with the old code as well. One way out of this is to only print the subject line (i.e., `\setkomavar{subject}{.}' if `org-koma-letter-subject-format' is nil and and fix `noexport' to hide the subject (i.e., inhibit `\setkomavar{subject}{.}'). Perhaps the ox-latex.el way is the way to go: #+TITLE: # i.e. nothing The difference would be that here would have not to format subject komavar at all. Is this the entended behaviour? I'll try to post a patch for this later tonight. Yeah, let's think about it. From my point of view, basically never using LCO files, I think 1. it should be possible to not post a subject. I tried to implement this via #+OPTIONS: subject:nil. 2. But perhaps I'm trying to be too clever. I might have defined komavar-subject in an LCO file, but still changing subject formating on the go. This is not possible. 3. If letting subject be disabled by an empty title 2. won't break it. So how about the condition (pseudo lisp): (or (title is nil) (subject is nil))? It should be pretty simple to get to that state I think. 3. I'm not a big fan of the parentheses in the subject:(.) syntax, but if that's required to use an option list with multiple values I think it's okay. OK, perhaps there's a clever way to get it to accept several keywords without a parenthese. I'm not sure. It would be nice to be able to specify a single value without the parens, but it's not a high priority (and I don't know how to do that). That should be possible. I thought I'd tested it. Note though, that giving a single value overwrites the default. I'm not sure whether it should extend upon the default. Cheers, Rasmus -- C is for Cookie
[O] org-export-html-date-format-string
I'm having trouble customizing the variable org-export-html-date-format-string. Before I tried to customize it, I would get the date in the postamble when I exported to html: p class=dateCreated: 2013-05-21 Tue 12:44/p The original string for the variable is: %Y-%m-%dT%R%z I don't want this string, so I changed it to %F%T%Z which didn't give any date when I exported. So I changed the string to %Y-%m-%d and still had no date after export. Changing back to the default string doesn't work either. This seems like a bug. Here is what is in my init.el after customization: '(org-export-html-date-format-string %Y-%m-%dT%R%z) '(org-html-postamble t) '(org-html-postamble-format (quote ((en p class=\author\Author: %a /p p class=\date\Date: %d/p p class=\creator\%c/p Here is the html of the postamble after export: div id=postamble class=status p class=authorAuthor: Scott P. Randby /p p class=dateDate: /p p class=creatora href=http://www.gnu.org/software/emacs/;Emacs/a 24.2.1 (a href=http://orgmode.org;Org/a mode 8.0.3)/p /div How do I get the date variable to work? Scott Randby
Re: [O] Let's discuss citation and Org syntax
Hi, Rasmus wrote: Hi, Now that 8.0 has shipped let's talk bibliography support. This follows directly upon the discussion around March[1]. I did not follow the discussion in March and only skimmed through the recent discussion in May [2]. But I was wondering if bibliography support in the LaTeX exporter would be BibTex-only or if it would also support biblatex, for example. Cheers, Viktor [1] http://mid.gmane.org/20130303070635.GA12112%40panahar [2] http://thread.gmane.org/gmane.emacs.orgmode/71754
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Viktor Rosenfeld listuse...@gmail.com writes: Actually, this patch does break LCO files. Now, if you don't set AUTHOR or EMAIL in the letter the default options from the LaTeX exporter always overwrite the settings defined in LCO files. This one is tough. . . One could #+INCLUDE an org-file but that's not really a fair comment. I'm not really sure how to progress. 1. One way would be do do a grep on the LCO files, but they might be in the TeX PATH which would vary over TeX systems and OSes. 2. Have people have empty AUTHOR and EMAIL if they've got the info in an LCO file, but this is not desirable. - Supply an optional filter to remove this info ex-post, but how would it know when to run? 3. Define some function to intelligently guess values based on content. 1. Perhaps a TYPE variable. So if TYPE is business or causal and I select business a list with business-defaults would be applied. OTOH this might be too complicated to just writing a LCO files. . . 4. Revert the path. What should be the standard? I'm compelled to go with work as the LaTeX-backend, but it may not be optimal here if there's a need for chaining email and name regularly. Rasmus, couldn't you just set the old `org-koma-letter-sender' option if you don't use LCO files? Sure, I just thought it was inconsistent that the framework didn't use the same keywords as other backends. But consistent might lack for good reasons. For me the previous behavior was annoying since I usually don't set AUTHOR and this didn't work nicely. Also, I agree that SENDER should have been called AUTHOR. It was a workaround because the LaTeX backend would ignore nil values for AUTHOR in derived backends (but not for EMAIL, so I kept this). This should now have been fixed. OK. So it's OK to switch to the AUTHOR keyword and just the default is what we need to settle on? –Rasmus -- . . . Stallman was indeed the tallest possible mountain and by standing on his shoulders you could see forever. . .
[O] Org sources and PDF files on Worg
Hi, I recently wrote a tutorial for the ox-koma-letter exporter [1] which includes a link to an Org file [2] file and a PDF file [3] as examples. The files are checked into the Worg repository, but they are not available online. Is there something I have to do to enable this? At first I thought the problem was related to the switchover to the new exporter, but the issue persists. Also, an old version of the tutorial at an old address [4] is still online even though I've changed the location in the git repository. How can I delete this version? Cheers, Viktor [1] http://orgmode.org/worg/exporters/koma-letter-export.html [2] http://orgmode.org/worg/sources/exporters/koma-letter-example.org [3] http://orgmode.org/worg/images/ox-koma-letter/koma-letter-example.pdf [4] http://orgmode.org/worg/org-tutorials/koma-letter-export.html
Re: [O] Let's discuss citation and Org syntax
Viktor Rosenfeld listuse...@gmail.com writes: Now that 8.0 has shipped let's talk bibliography support. This follows directly upon the discussion around March[1]. I did not follow the discussion in March I tried to summarize it the second post since the thread was very long. But I was wondering if bibliography support in the LaTeX exporter would be BibTex-only or if it would also support biblatex, for example. Currently, you can use both through the link syntax, but it's not so nice if you use prenote and postnotes. I solely use biber + biblatex these days. –Rasmus -- This space left intentionally blank
Re: [O] org-export-html-date-format-string
I solved the problem by putting the following in the file to be exported: #+DATE: [2013-05-21 Tue 14:45] However, this means I have to remember to change the date every time I export. Is there an easier way to do this? Scott Randby On 05/21/2013 01:49 PM, Scott Randby wrote: I'm having trouble customizing the variable org-export-html-date-format-string. Before I tried to customize it, I would get the date in the postamble when I exported to html: p class=dateCreated: 2013-05-21 Tue 12:44/p The original string for the variable is: %Y-%m-%dT%R%z I don't want this string, so I changed it to %F%T%Z which didn't give any date when I exported. So I changed the string to %Y-%m-%d and still had no date after export. Changing back to the default string doesn't work either. This seems like a bug. Here is what is in my init.el after customization: '(org-export-html-date-format-string %Y-%m-%dT%R%z) '(org-html-postamble t) '(org-html-postamble-format (quote ((en p class=\author\Author: %a /p p class=\date\Date: %d/p p class=\creator\%c/p Here is the html of the postamble after export: div id=postamble class=status p class=authorAuthor: Scott P. Randby /p p class=dateDate: /p p class=creatora href=http://www.gnu.org/software/emacs/;Emacs/a 24.2.1 (a href=http://orgmode.org;Org/a mode 8.0.3)/p /div How do I get the date variable to work? Scott Randby
Re: [O] org-export-html-date-format-string
Hello, Scott Randby sran...@gmail.com writes: I'm having trouble customizing the variable org-export-html-date-format-string. Use `org-html-metadata-timestamp-format' instead. Regards, -- Nicolas Goaziou
Re: [O] TOC in HTML export - how to change formatting of ToDo levels?
You should be able to customize the todo class only within the TOC context with such a rule: --8---cut here---start-8--- #table-of-contents .todo { ... } --8---cut here---end---8--- Best regards, Seb Thanks for the info. This will help a bit but still doesn't address the TOC code throwing out the actual ToDo states of the headlines and making everything either .todo or .done. David
Re: [O] org-export-html-date-format-string
On 05/21/2013 02:55 PM, Nicolas Goaziou wrote: Hello, Scott Randby sran...@gmail.com writes: I'm having trouble customizing the variable org-export-html-date-format-string. Use `org-html-metadata-timestamp-format' instead. Thanks. This worked after I replaced %d with %T in the format string for org-html-postamble-format. Regards,
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Hi, Rasmus wrote: Viktor Rosenfeld listuse...@gmail.com writes: Actually, this patch does break LCO files. Now, if you don't set AUTHOR or EMAIL in the letter the default options from the LaTeX exporter always overwrite the settings defined in LCO files. This one is tough. . . One could #+INCLUDE an org-file but that's not really a fair comment. I'm not really sure how to progress. 1. One way would be do do a grep on the LCO files, but they might be in the TeX PATH which would vary over TeX systems and OSes. Way too complicated and brittle, IMHO. 2. Have people have empty AUTHOR and EMAIL if they've got the info in an LCO file, but this is not desirable. - Supply an optional filter to remove this info ex-post, but how would it know when to run? Empty AUTHOR and EMAIL lines are not user-friendly. However, another option is to set `user-mail-address' and `user-full-name' to nil, but then this would also affect other areas of Emacs beside the LaTeX expoerter (which I currently no use so I can't speak to side-effects). 3. Define some function to intelligently guess values based on content. 1. Perhaps a TYPE variable. So if TYPE is business or causal and I select business a list with business-defaults would be applied. OTOH this might be too complicated to just writing a LCO files. . . Basically duplicates LCO files but will never achieve the same functionality. 4. Revert the path. Or 5, keep the change from SENDER to AUTHOR but revert the default values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL lines could be removed because they duplicate the derived latex backend.) What should be the standard? I'm compelled to go with work as the LaTeX-backend, but it may not be optimal here if there's a need for chaining email and name regularly. I prefer 5. :-) Rasmus, couldn't you just set the old `org-koma-letter-sender' option if you don't use LCO files? Sure, I just thought it was inconsistent that the framework didn't use the same keywords as other backends. But consistent might lack for good reasons. The default LaTeX exporter does not have LCO files. Sure you can simply \input a latex file but there is no dedicated support for this in Org mode, is there? The LaTeX exporter also assumes that every LaTeX file needs a title, a date, and an author, but this is not always true as the scrlttr2 class shows (title, or subject, is definitely optional). Also, LaTeX blocks which are evaluated separately don't need these values either. So I understand striving for consistency, but I think that the use case here is different enough to break it. For me the previous behavior was annoying since I usually don't set AUTHOR and this didn't work nicely. Also, I agree that SENDER should have been called AUTHOR. It was a workaround because the LaTeX backend would ignore nil values for AUTHOR in derived backends (but not for EMAIL, so I kept this). This should now have been fixed. OK. So it's OK to switch to the AUTHOR keyword and just the default is what we need to settle on? I think that switching from SENDER to AUTHOR, keeping the `org-koma-letter-{author,email}' variables in the KOMA backend, but setting them per default to `user-full-name' and `user-mail-address', would solve both your problems and let me keep LCO files. I would then simply set these `org-koma-letter-*' variables to `nil' and document this setup in the docstring. I'll see tomorrow if this is feasable. Cheers, Viktor –Rasmus -- . . . Stallman was indeed the tallest possible mountain and by standing on his shoulders you could see forever. . .
[O] org-plus-contrib elpa and ox-* files
Back in the beginning of May I pointed out what I thought was a bug in server.mk that prevented the ox-* files in contrib from getting included in the Org ELPA archives. It got fixed in 6de09e2d3e38ac84a09659931ee96dff5e5d68c9 (thanks Achim!). I just installed org-plus-contrib-20130520.tar from Org ELPA but the ox-* files still aren't there. Maybe I was wrong about the source of the issue? Or is there a delay between what hits master and what gets to the Org ELPA archves? Thanks in advance,
Re: [O] [patch] ox-koma-letter.el: credit [3/4]
Hi, Rasmus wrote: - It doesn't work because `org-koma-letter-special-content' is set to nil at the beginning of `org-koma-letter-template'. Why is that? If I comment it out everything works. Hmm, it should be populated by the headline function each time. . . That is at least the idea. I.e. - When exporting `org-koma-letter-special-content' gets populated and is available until next export. - When exports run again stuff might have changed so I want to repopulate the variable. Why not clear `org-koma-letter-special-content' at the start of `org-koma-letter-headline'? - I would remove the formatting from org-koma-letter-ps-prefix and put it in the docstring, simply because the separators for \encl and \cc are also not formatted in the KOMA-Script defaults. So you'd set org-koma-letter-ps-prefix to nil or ? The thing is, in scrlttr2 does not add a ps-prefix by itself, which seems inconsistent. So with your suggesting we'd get a more vanilla feel, which I guess would normally be nice, but here somehow feel inconsistent to me. I'm happy to oblige on this issue. Either nil or or even PS. I guess there is no default because people write things like PPS and PPPS and so on. Anyway, in my view having \ps specially formatted is inconsistent because \encl and \cc are not per default. One thing I'd like to discuss is whether to adopt headings for TO and FROM also. The Groff exporter already does so for it's letters. The main benefit is that it allows for org-syntax. IMO it's a lot nicer to look at as well. Check the org-groff site in the footnote for an example. I am not sure about this. I often write a letter below a task in my Org files so I rely on exporting the subtree only. So I would have to put the TO address below the letter text which looks weird, but is doable. On the other hand, being able to use Org syntax and not have to escape linebreaks with `\\' is a big plus. Maybe both options could be supported. I.e., use a FROM headline if available, but fall back on option lines if not? Or is this too confusing for users? The reason why I didn't add it as this point is that I'd want to keep it 'backward compatible' and I had to think about it. I was toying with introducing a =:with-legacy= variable that would govern which of =* TO :TO:= and =#+TO_ADDRESS= would be printed if both are present. I would definitely like to keep the old functionality. I like how your patch uses headlines to add additional information to the letter. But in the letters I wrote I would only need a FROM headline and having this single headline below the letter text seems strange. However, I realize that my preferences are very much tied to my workflow and being able to specify an address below FROM or TO headlines is very useful because it is so powerful (and probably easier to new users). If a letter uses both a headline and an option line to set an address I would think the headline should take precedence, because it is more powerful. A `:with-legacy' variable doesn't really solve anything because what does the exporter do if the variable is missing but there are two addresses set? Maybe the exporter could simply emit a warning in that case. Cheers, Viktor What do you think? Thanks for your comments. –Rasmus -- The Kids call him Billy the Saint
Re: [O] performance of exporting large tables
Nicolas Goaziou twisted the bytes to say: Nicolas Nicolas Goaziou n.goaz...@gmail.com writes: I am going to have a look at this. Nicolas I pushed a commit caching the results of some table functions. Export of Nicolas large tables should be a lot faster (I get 6 s now; it was 90 s before). Hi Nicolas, thank you very much. This has resolved my issue. I can now export an org file with these tables in few seconds. thank you, --daniel Nicolas Regards, Nicolas -- Nicolas Nicolas Goaziou -- Daniel M. German To read is to travel without all the hassles of luggage. Emilio Salgari http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with .
Re: [O] Let's discuss citation and Org syntax
Dnia 2013-05-21, o godz. 19:55:53 Viktor Rosenfeld listuse...@gmail.com napisał(a): Hi, Rasmus wrote: Hi, Now that 8.0 has shipped let's talk bibliography support. This follows directly upon the discussion around March[1]. I did not follow the discussion in March and only skimmed through the recent discussion in May [2]. But I was wondering if bibliography support in the LaTeX exporter would be BibTex-only or if it would also support biblatex, for example. Good point. I do not use Org-mode for authoring (I'm quite happy with LaTeX itself for that), and in LaTeX, I use neither bibtex nor biblatex; but AFAIK, bibtex is basically dead like John Cleese's parrot. I don't even think that it needs to or should be supported; the faster bibtex usage fades away, the better. What I would suggest is to look into amsrefs manual. The amsrefs package was (is?) an interesting attempt at a /pure LaTeX/ solution to the bibliography problem, not dependent on any executable other than LaTeX. It is not capable of sorting bibliographies, but other than that is quite powerful (much more than bibtex, though seemingly less than biblatex). What is interesting here is its \ycite and \ocite commands (see http://mirrors.ctan.org/macros/latex/contrib/amsrefs/amsrdoc.pdf); it might be a good idea to support something similar. (I'm not sure whether biblatex supports such a thing.) Cheers, Viktor Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] Org sources and PDF files on Worg
Hello Viktor, On Tue, May 21, 2013 at 2:13 PM, Viktor Rosenfeld listuse...@gmail.com wrote: Hi, I recently wrote a tutorial for the ox-koma-letter exporter [1] which includes a link to an Org file [2] file and a PDF file [3] as examples. The files are checked into the Worg repository, but they are not available online. Is there something I have to do to enable this? At first I thought the problem was related to the switchover to the new exporter, but the issue persists. Also, an old version of the tutorial at an old address [4] is still online even though I've changed the location in the git repository. How can I delete this version? Cheers, Viktor [1] http://orgmode.org/worg/exporters/koma-letter-export.html [2] http://orgmode.org/worg/sources/exporters/koma-letter-example.org [3] http://orgmode.org/worg/images/ox-koma-letter/koma-letter-example.pdf [4] http://orgmode.org/worg/org-tutorials/koma-letter-export.html I believe I can give a partial answer: it looks like Worg isn't publishing right now, which suggests that there was a recent commit which broke things. The search for the problem begins. Once the error is identified and fixed, then things should get back to normal. I've copied Marc on this message - we'll see if we can track the problem down. Thanks for the report. -- Jay Kerns -- G. Jay Kerns, Ph.D. Youngstown State University http://people.ysu.edu/~gkerns/
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Viktor Rosenfeld listuse...@gmail.com writes: Or 5, keep the change from SENDER to AUTHOR but revert the default values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL lines could be removed because they duplicate the derived latex backend.) I once had a teacher who talked about the optimal degree of conservatism (as well speaking positively about being in the infamoues ivory tower). 5. is fine with me. So I guess the deal is 1. default value is the same as in ox-latex. 2. . . . but it's kept in a seperete variable ox-kl variable. The default LaTeX exporter does not have LCO files. Sure you can simply \input a latex file but there is no dedicated support for this in Org mode, is there? only through #+LATEX: \input{.} I guess (or something similar). I think that switching from SENDER to AUTHOR, keeping the `org-koma-letter-{author,email}' variables in the KOMA backend, but setting them per default to `user-full-name' and `user-mail-address', would solve both your problems and let me keep LCO files. I would then simply set these `org-koma-letter-*' variables to `nil' and document this setup in the docstring. I'll see tomorrow if this is feasable. Does the attached patch work for you (also with ps tags?) –Rasmus -- Dung makes an excellent fertilizerFrom 92b07bac2d707f01e48796778453b67a9ecd1daa Mon Sep 17 00:00:00 2001 From: rasmus.pank rasmus.p...@gmail.com Date: Wed, 22 May 2013 01:16:54 +0200 Subject: [PATCH 5/5] Variables for author and email for ox-koma-letter and a bug fix. * ox-koma-letter.el (koma-letter): reintroduced koma-letter specif author and email. * ox-koma-letter.el (koma-letter): set org-koma-special-content to nil when exporting The former is needed so that author/email can be set in a LCO file. TINYCHANGE --- contrib/lisp/ox-koma-letter.el | 49 +++--- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index 020df52..92cf13a 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -109,6 +109,12 @@ :group 'org-export-koma-letter :type 'string) +(defcustom org-koma-letter-email user-mail-address + The default email address stored in the letter. ) + +(defcustom org-koma-letter-author user-full-name + The default name of the sender. ) + (defcustom org-koma-letter-signature \\usekomavar{fromname} String used as the signature. :group 'org-export-koma-letter @@ -143,7 +149,6 @@ English manual of 2012-07-22) :group 'org-export-koma-letter) - (defcustom org-koma-letter-use-backaddress t Print return address in small line above to address. :group 'org-export-koma-letter @@ -179,7 +184,6 @@ Use `foldmarks:true' to activate default fold marks or :group 'org-export-koma-letter :type 'string) - (defconst org-koma-letter-special-tags-after-closing '(PS ENCL CC) Headers tags to be inserted after closing) @@ -193,7 +197,7 @@ Use `foldmarks:true' to activate default fold marks or org-koma-letter-special-tags-after-closing) Header tags with special meaning) -(defvar org-koma-letter-special-content nil holds special +(defvar org-koma-letter-special-contents nil holds special content temporarily.) @@ -203,10 +207,10 @@ content temporarily.) (org-export-define-derived-backend 'koma-letter 'latex :options-alist '((:lco LCO nil org-koma-letter-class-option-file) -(:sender AUTHOR nil user-full-name t) +(:sender AUTHOR nil org-koma-letter-author) (:from-address FROM_ADDRESS nil org-koma-letter-from-address newline) (:phone-number PHONE_NUMBER nil org-koma-letter-phone-number) -(:email EMAIL nil user-mail-address t) +(:email EMAIL nil org-koma-letter-email) (:to-address TO_ADDRESS nil nil newline) (:place PLACE nil org-koma-letter-place) (:opening OPENING nil org-koma-letter-opening) @@ -275,29 +279,31 @@ channel. ;; Thanks, Luis! (defun org-koma-letter--get-tagged-content (tag info) - (cdr (assoc tag org-koma-letter-special-content))) + (cdr (assoc tag org-koma-letter-special-contents))) -(defun org-koma-letter-headline (headline conents info) +(defun org-koma-letter-headline (headline contents info) Transcode a HEADLINE element from Org to LaTeX. CONTENTS holds the contents of the headline. INFO is a plist holding contextual informatio.n 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-content' and included at the +stored in `org-koma-letter-special-contents' and included at the appropriate place. (let* ((tags (and (plist-get info :with-tags) (org-export-get-tags headline info -(if (member (car tags) org-koma-letter-special-tags) - (cond ((member (car tags) '(PS ps)) - (progn - (push (cons (car tags) (concat (plist-get info :ps-prefix) contents)) -
Re: [O] Let's discuss citation and Org syntax
Hi Rasmus, On 2013-05-21 21:21, Rasmus wrote: Now that 8.0 has shipped let's talk bibliography support. This follows directly upon the discussion around March[1]. Thanks for a great post and for taken initiative for making org-mode even better for my purposes. I started using org for writing papers a few years ago and I am not looking back. The weak point however is bibliographies, as you say. FWIW, I will describe my use case. For drafting and when I can get away with it, I am going from org to PDF through XeLaTex, with either bibtex or more recently biber+biblatex. However, when I submit papers, in most cases they have to be in a wordprocessor format, so I am going through the ODT export here. In my current workflow this means that the bibliographie falls apart and in the end (deadlines!!) I usually cut and paste what I can get into either HTML or PDF. This is not ideal and if this can improve it would mean a lot to me. One problem I have had with bibtex and which I am now kind of dealing with (albeit still in a hackish way) in biber+biblatex is that I need specific formatting of the entries depending on the language I am publishing in, which is mostly either English or Japanese. So for Japanese sources cited in English papers, I have to give the author and title optionally in Japanese characters, but also in romanized form and possibly in translation, whereas English sources in Japanese might require a Japanese form of the names and again a translation into Japanese. I ended up adding extra fields to my bibtex file, since no bibliographic format I know of (except TEI) would support this and still allow me to integrate it into my workflow, but the big problem lies of course in integrating this better in my workflow. So whatever org ends up with having in terms of bibliography, I would like to work with you and however jumps in to make sure that it also fits this need (which is actually not limited to an exotic field like mine, but is quite common for academics working in East Asia). All the best, Christian -- Christian Wittern, Kyoto
Re: [O] GFDL
On 21.5.2013, at 17:03, François Pinard pin...@iro.umontreal.ca wrote: Carsten Dominik carsten.domi...@gmail.com writes: I am curious, what passage does make such restrictions possible, and which kinds of restrictions? Oh, I did not read the GFDL in quite a years, and really have no interest in diving and scrutinizing it again :-). OK, I will not ask again. :) More away I am from all this, better I feel :-). Sorry, just forget I've written this morning, I was likely in some strange mood. I do love the FSF idea and theory, and supported the GNU project in an intense way for maybe more than twenty years. But by now, in practice, I just cannot stand their slightest abuse, anymore. I'm all for programming freedom, but this ought to include programmer freedom too! François
Re: [O] Let's discuss citation and Org syntax
At Tue, 21 May 2013 19:55:53 +0200, Viktor Rosenfeld wrote: Hi, Rasmus wrote: Hi, Now that 8.0 has shipped let's talk bibliography support. This follows directly upon the discussion around March[1]. I did not follow the discussion in March and only skimmed through the recent discussion in May [2]. But I was wondering if bibliography support in the LaTeX exporter would be BibTex-only or if it would also support biblatex, for example. And to further confuse the issue, why not consider pandoc style citations [1]? This works right now. Create an org file: See [@citekey, p. 10] for more info. (assuming a bibtex, endnote, ris, ... file that contains a cite with key “citekey”). Export to markdown. Process in pandoc, either to latex: ❤ pandoc --natbib test.md -t latex -s --biblio test.bib or to HTML, etc: ❤ pandoc test.md -s --biblio test.bib While it would be nice to make this work natively with org, especially with latex output, it would be great if compatibility with pandoc could be obtained. best, Erik 1. http://johnmacfarlane.net/pandoc/README.html#citation-rendering Sent from my free software system http://fsf.org/.