Re: [O] Org-mode for school work
6. Finaly it is possible to make a table that i use a lot a form that i can fill and it is possible with i don't know a short-cut or something to call this form when i need it. Depending on what exactly you have in mind, Org Capture might be the answer. Yours, Christian
Re: [O] The Org-ODT exporter is now in Org's core (latest git)
On 12/15/11 8:26 AM, Jambunathan K wrote: Alan That solved the problem. I was loading an old version. If you had copied etc/styles dir by hand to the installation dir I would consider that a bug. This copying should happen auto-magically. I hope things work auto-magically now without any manual intervention. Not for me. Could be specific to make install into Emacs.app on Mac (I know squat about this, except that we have to edit our Makefile to get lisp and docs installed in the right place, and maybe we have to do something special for the etc dir too?). Could someone confirm that etc/styles is automatically installed on Linux / that it isn't on Mac? Yours, Christian
Re: [O] ODT export custom link colors?
On 12/15/11 8:41 AM, Jambunathan K wrote: I usually put the cursor on the text that I am interested in, press F11 and switch to char styles or whatever category. The right style would be highlighted which you can directly inherit from. Indeed, that's a better recipe. (On a Mac laptop keyboard, Cmd-T instead of F11.) The exact scenario you describe here is documented in the manual. (info (org) Creating one-off styles) The scenario was not mixing raw ODT XML in with Org, but using a custom link type to color text. The manual page you point to gives all the info one would need to figure out how to do it, and I should have given the reference. But the manual does not spell out exactly how to solve that scenario, so I thought that would be helpful. #+begin_src emacs-lisp (org-odt-format-fontify This text is in red red-style) #+end_src It will mark the text in red-style. You can similarly use this or this for marking text in bold. #+begin_src emacs-lisp (org-odt-format-fontify This text is in red 'bold) #+end_src That's cool, but how do you suggest to use it? I tried it with =:exports results=, but that didn't work (the angle brackets got escaped). But I probably misunderstood, and you meant to use it to generate the correct raw XML and then include the result in the text, with =@= signs added? That works out of the box for the bold example, but not for red-style -- I assume we'd have to create that style first? If you look at OrgOdtStyles.xml (C-h v org-odt-styles-dir) and you can see a bunch of styles marked as Org Agenda Styles. These are used for marking TODO in red and DONE in green etc. Copy paste those styles, fix the name and background color and you are done. Thanks, that's helpful. Yours, Christian
Re: [O] odt export error
Hi, Looking into your styles.xml, it seems openoffice is choking on the representation of the bullet character. Exporting your org document with the default stylesheet in Org 7.8 works (result attached), with a valid unicode bullet character in the styles.xml. It is likely that you are running an old bleeding-edge development version of the ODT exporter. If you can update to Org 7.8, you should do that; as of this week, the ODT exporter is part of core Org. (And when you update, clean out old versions of org-odt from your load-path and your .emacs.) hope this helps, Christian On 12/14/11 4:03 AM, Kevin Emerson wrote: Hello all, I am relatively new to org-mode, but I am certainly a convert - a great piece of work! I usually export things as html, but my employer always wants updates in doc format. I was hoping to use the new odt export functionality and then I can save the odt as a doc file. This works for me sometimes - but not always. I can not pinpoint exactly what yields the error, but it reads Format error discovered in the file in sub-document styles.xml at 415,108(row,col) when the file attempts to open in openoffice 3.2. I am using org-mode 7.6. I have attached my org file and the resulting odt file. Any thoughts would be greatly appreciated. Cheers, Kevin 2011-12-13-periodAnnotationTranscriptome2.odt Description: application/vnd.oasis.opendocument.text
Re: [O] The Org-ODT exporter is now in Org's core (latest git)
Of course, getting libreoffice to do what I want is another story... ;-) I imagine I'll have to use a mouse :-( Well, you can always author your own styles file in plain XML conforming to the ODF specification. No mouse required!... ;-) Christian
Re: [O] ODT export custom link colors?
Hi,
I'm not sure about this, because I don't really know the ODT spec, but
I *think* you will have to define an ODT Character style for *each*
color you want to use, using a consistent convention for naming these
styles.
For instance, in the LibreOffice Styles and Formatting window, choose
the Character styles tab, right-click on Default, select New. Name
your style (e.g.) Bgcolor red. Right-click it, select Modify, in the
Background tab give it a red background.
Repeat for other colors you use, e.g. Bgcolor blue, Bgcolor yellow...
Now, modify your custom link code as follows:
(org-add-link-type
bgcolor nil
(lambda (path desc format)
(cond
((eq format 'html)
(formatspan style=\background-color:%s;\%s/span path desc))
((eq format 'latex)
(format\\colorbox{%s}{%s} path desc))
((eq format 'odt)
(format text:span text:style-name=\Bgcolor
%s\%s/text:span path desc))
(t
(formatBGCOLOR LINK (%s): {%s}{%s} format path desc)
(You can change the style-name in the format string to follow whatever
naming convention you've adopted for your styles. If you want to call
them simply red, blue and so on, it would be text:style-name=\%s\.)
(Judging from the manual, if you have space in your style names, like
above, you should perhaps escape the spaces with _20_, but the
Bgcolor %s above seems to work fine.)
Please report back if this works for you. If so, and depending on what
Jambunathan might have to add, I'll look into updating the Worg examples.
(By the way, before I added my 't' case above, it returned nil, which
caused the odt exporter to blow up with an unhelpful error. Would a
patch for that be considered too much of a corner-case? I'd be happy
to submit one.)
I don't know what others think, but I think the habit of always
providing one's custom links with an explicit fallback should be
encouraged, if necessary by rude reminders from failing exporters...
:-)
hth,
Christian
Re: [O] The Org-ODT exporter is now in Org's core (latest git)
2. I see where the default styles are and I am happy with these generally. However, as a libreoffice n00b, how do I create my own style file that would be appropriate for the ODT exporter? It's not so much about the creating of style files (although help in that regard would not be sniffed at ;-) but about whether there is a list of paragraph styles that can be customised somewhere? The easiest way is now described in the manual: write your document in Org, including all the sorts of stuff you might want to have styles for, then export it to ODT, open it in LibreOffice, and tweak the styles you find there. Because you exported it from Org, you can be sure that the styles have the names the exporter uses. You can customize any style, no limits. LibreOffice's Styles and Formatting window is your friend (accessible from the Format menu or from an icon usually at the far left of the toolbar). It has tabbed lists of Paragraph, Character, Page, Frame and List styles. Right-click on a style to modify it. When your LibreOffice document looks like you want it to, simply save it somewhere smart. The next time you export from Org, point org-export-odt-styles-file to that file as your style template. hth, Christian
[O] [BUG] LaTeX subtree export gives spurious unbalanced begin/end_%s blocks error
Hi, Here's a minimal document: BEGIN EXAMPLE #+title: Testing * Src blocks Here's some Lisp: #+begin_src emacs-lisp (message Hello world!) #+end_src END EXAMPLE When I try to export the Src blocks subtree to PDF via LaTeX, I get the error: unbalanced begin/end_src blocks Export of the whole document to PDF via LaTeX is not affected. Neither, initially, is HTML export, including subtree export to HTML. However, after getting an error by trying to export the subtree to LaTeX, I get the same error when trying to export to HTML (whether subtree or the whole document). I can clear the HTML export error by exporting the whole document via LaTeX again. I'm using Org 7.7 (pulled this morning) on GNU Emacs 23.3.1 on a Mac. Yours, Christian
[O] [BUG] Various problems with org-odt export
Hi, Either something's gone wrong with my setup, or there are a number of issues to straighten out after org-odt moved to core. Here's what I have so far (with Org 7.7 pulled this morning, Emacs 23.3.1, on a Mac). Issues 1 and 3 look urgent. 1. The org-export-odt-styles-file variable still points to ~/src/base/org-mode/contrib/odt/styles.xml as the default style template. The defcustom comes with a FIXME note, and that has become urgent, as the lack of a default styles file in the default place would cause Org-odt export to fail out of the box for most users. I'm not sure where this should point, but I assume it should not point to anything in contrib any longer. 2. The #+ODT_STYLES_FILE directive does not seem to work. It's ignored and the value of org-export-odt-styles-file is used instead. 3. Current backend not set to 'odt? During ODT export, org-export-format-source-code-or-example fails while trying to load a file called org-nil. So apparently org-export-current-backend fails to be passed the value 'odt on ODT export. The latter problem could also explain why, trying to export a file with verse environments, I got LaTeX mixed in with the ODT XML... Yours, Christian
Re: [O] [BUG] Various problems with org-odt export
Hi, Thanks, the problem was indeed with setup and not with org-odt as such, so I'm really sorry about the noise. But I'm wondering if something needs to be done about the Makefile to make sure etc/styles installs. Background: I'm in the habit of compiling and installing Org each time I pull, and as I'm on a Mac, that means changing a couple of installation paths in the Makefile so as to install into Emacs.app. All this probably puts me in a small minority of users. The lisp files got installed all right, including the up-to-date org-odt.el and org-odt.elc. And yes, I did for some reason have an older org-odt.el in my loadpath that was interfering. Very embarrassing. But after I got rid of that, I was definitely running the new org-odt. However, things still did not work, and the reason seems to be that the etc/styles directory did not get installed into the appropriate etc directory in Emacs.app. Because the directory was missing, org-odt-styles-dir never got set; it kept throwing an error that it couldn't find the factory styles. I copied the etc/styles dir manually over into Emacs.app, and now everything seems to work. Could it be that, because there hasn't been anything to install from the etc directory before, the Org-mode Makefile doesn't take care of it? The only reference to etc/ I've found in the Makefile is in connection with ELPA, which I don't use. Yours, Christian On 12/12/11 2:46 PM, Jambunathan K wrote: Christian Hi, Either something's gone wrong with my setup, or there are a number of issues to straighten out after org-odt moved to core. Here's what I have so far (with Org 7.7 pulled this morning, Emacs 23.3.1, on a Mac). Issues 1 and 3 look urgent. 1. The org-export-odt-styles-file variable still points to ~/src/base/org-mode/contrib/odt/styles.xml as the default style template. The defcustom comes with a FIXME note, and that has become urgent, as the lack of a default styles file in the default place would cause Org-odt export to fail out of the box for most users. I'm not sure where this should point, but I assume it should not point to anything in contrib any longer. The default style files have been moved from contrib/odt/styles to etc/styles. Make sure that you are loading the right version of org-odt with M-x locate-library. Also the following variables: C-h v org-odt-lib-dir = ~/src/org-mode/lisp/ C-h v org-odt-styles-dir = ~/src/org-mode/etc/styles/ The first variable says wherefrom org-odt is loaded. The second variable -- which was newly introduced a 2-3 days ago -- should tell where the default style files come from. If you are unable to find the second variable, then it most postively suggests that it is the old org-odt that is loaded. 2. The #+ODT_STYLES_FILE directive does not seem to work. It's ignored and the value of org-export-odt-styles-file is used instead. May be related to (1). Is everything OK when there is *no* ODT_STYLES_FILE and org-export-odt-styles-file is *reset* to nil? 3. Current backend not set to 'odt? During ODT export, org-export-format-source-code-or-example fails while trying to load a file called org-nil. So apparently org-export-current-backend fails to be passed the value 'odt on ODT export. The latter problem could also explain why, trying to export a file with verse environments, I got LaTeX mixed in with the ODT XML... I hope org-odt loads fine... Does M-x load-library RET org-odt RET report any errors? Yours, Christian
Re: [O] Avoiding div from special blocks to be in p…
Thanks! Yours, Christian On 12/11/11 2:11 PM, Bastien wrote: Hi Christian, Christian Moem...@christianmoe.com writes: I submitted a patch to this effect a month and a half back. http://patchwork.newartisans.com/patch/979/ Apart from uncommenting that line, I put in an org-open-par after the div and rearranged a few lines to follow the same structure as other similar bits of code. I just applied it. Sorry for the delay and thanks for this. Best,
Re: [O] The Org-ODT exporter is now in Org's core (latest git)
this is wonderful! many thanks to Jambu, Bastien, Christian and everyone involved. That would be Jambu, for developing the whole thing, and Bastien, for integrating it. (I have only done a bit of testing and cheerleading.) Yours, Christian
Re: [O] [PATCH] Re: Export as HTML does not preserve nonstandard entities as TODO signs
On 12/11/11 6:57 PM, Bastien wrote: Applied, thanks! Thanks. Yours, Christian
Re: [O] [ANN][RFC] org-odt.texi/org-odt.pdf preview (was Re: Org-odt table format)
Great news! I'll go over the documentation as promised. Yours, Christian On 12/11/11 12:13 AM, Jambunathan K wrote: Hello Christian Christian Moem...@christianmoe.com writes: Hi, Great, I'll just wait for your revised draft so we don't get versions mixed up. You would have seen this announcement[1] by Bastien. I have checked in the revised Info documentation for ODT exporter in to the master repo. I have tried my best to act on all your inputs. Let me know what you think. [1] http://www.mail-archive.com/emacs-orgmode@gnu.org/msg49545.html Yours, Christian On 10/28/11 6:19 AM, Jambunathan K wrote: I will work on your suggestions and circulate a revised draft shortly. Once an initial org.texi gets in to the repo, improving it would be a breeze.
Re: [O] [feature request] Org as an Excerpt Database (or Multivalue Properties)
Hi,
I've successfully used the regular expression searches Herbert Sitz
describes to search and query a small (~ 500 kB) Org database of all
my source materials (text clippings) for a project, where some of the
properties I used had multiple values.
You will find Matt Lundin's Advanced searching tutorial invaluable:
http://orgmode.org/worg/org-tutorials/advanced-searching.html
Org has some basic support for multivalue properties, mainly for
editing (getting, putting, adding, removing) and also a membership
test. See the manual:
[[info:org#Using%20the%20property%20API]]
Note that unlike your example setup, the values are not comma-separated.
The multivalue support does not, as far as I remember, extend to match
expressions for searches etc. This would probably be non-trivial to
implement. Something could probably be cobbled up with
org-entry-member-in-multivalued-property. But regexp searches are
fairly simple to use, and work now.
You'll want to think carefully about what you put in properties, what
you put in tags, and what you put in multi-value properties, with a
view to making this easy to search and change as your file grows.
Yours,
Christian
On 12/11/11 1:09 AM, Herbert Sitz wrote:
Sven Bretfeldsven.bretfeldat gmx.ch writes:
A property search for code-writing should match this citation and all
others with this property. An additional search for career should
narrow the matches down. But orgmode understands money, ... ethics as
ONE value, not FOUR. That's the problem.
Sven --
I think you should be able to get results you want using regular expression
searches on your 'keyword' field. E.g., the following tags-todo search should
find headings that have both 'career' and 'code-writing' in a 'keyword'
property:
keyword={career}keyword={code-writing}
This search would find headings that had one or the other or both:
keyword={career\|code-writing}
Regular expressions start out simple but can get very complex. I expect there's
a way to get whatever you want out of the multi-value property strings you
want to use.
-- Herb
Re: [O] The Org-ODT exporter is now in Org's core (latest git)
Wonderful! Yours, Christian On 12/10/11 6:22 PM, Bastien wrote: Dear all, as the subject says. Please all test this heavily and report any problems. This will be part of Org 7.8 and soon in Emacs. Thanks a lot to Jambunathan for all this efforts, let's make sure everything is smooth before the release! Best,
Re: [O] Directional quotes in html
On 12/7/11 10:44 AM, Christer Boräng wrote: Does it handle possessive ' at the end of words ending with an s or z sound? Like James' house? Sure, but not because it cares what letter they end with, only because it turns any straight single quote that doesn't become an opening curly quote into a closing curly quote, identical to curly apostrophe. Yours, Christian
Re: [O] Directional quotes in html
On 12/6/11 7:25 PM, Herbert Sitz wrote: What is best way to get directional pairs of open- and close-quotes in html export? -- Herb Hi, Herb, I keep this in my .emacs: (setq org-export-html-special-string-regexps (cons '( \\\([^\]+\\)\ . ldquo;\\1rdquo;) org-export-html-special-string-regexps)) There may be a better way to do it altogether, and I'm sure the very simple regexp could be improved on (in fact, I'm posting this in the hope someone will improve on it), but it mostly works. Yours, Christian
Re: [O] Directional quotes in html
On 12/6/11 9:37 PM, Herbert Sitz wrote: Question: Does this work only if quotes both appear on the same line of Org-mode text? Or is the regex applied to paragraph as a whole after it's been assembled as part of export? Oops, that's embarrassing. I never even noticed. I'm not sure why it doesn't work -- the regexp /does/ catch multiline quotes. Anyway, after some experimenting, the following mess seems to work in most cases: #+begin_src (setq org-export-html-special-string-regexps (append '((\\(^\\|[ \(]\\)' . \\1lsquo;) (\\([^ ]\\)' . \\1rsquo;) (\\(^\\|[ (]\\)\ . \\1ldquo;) (\\\([ [:punct:]]\\|$\\) . rdquo;\\1)) org-export-html-special-string-regexps)) #+end_src At least, it should work - if the opening single or double quotation mark comes at the beginning of the line, after a space, or after opening parenthesis, - or if the opening single quotation mark comes after an opening double quotation mark, - and if the closing double quotation mark comes before a space, before punctuation, including a closing parenthesis, or at the end of the line. It will work if you put the period /after/ the closing quotation mark, like this. Typographically, though, you should do it like this. It looks like it does only double-quotes; makes me realize single quotes are a bit harder because they're often used alone as apostrophes. The above now also handles single quotes, including apostrophes between word characters (it's). The rule is that any single quote that is not an opening quote is turned into a closing quote, which works for apostrophes too. It also handles nested quotes (single quotes within double quotes). The following example should illustrate parentheses and nested quotes: #+begin_example Philosophy ain't easy (being is a surprisingly difficult concept, but not as hard as non-being). Who said: 'Being' is a surprisingly difficult concept, but not as hard as 'non-being'? #+end_example It seems like even single-quote pairs could work well if you put beginning-of-word (\) and end-of-word (\) regex anchors in there. I've experimented with those anchors, but ended up doing without them; punctuation mixes with quotation marks in odd ways. Yours, Christian
Re: [O] Avoiding div from special blocks to be in p…
Hi, I submitted a patch to this effect a month and a half back. http://patchwork.newartisans.com/patch/979/ Apart from uncommenting that line, I put in an org-open-par after the div and rearranged a few lines to follow the same structure as other similar bits of code. Yours, Christian On 12/4/11 5:01 PM, Jonathan BISSON wrote: Hi, I just uncommented a line in org-special-blocks.el that made div special blocks (like #+begin_foo) in html export to be betweenp…/p… It seems to work well like this (and now the produced documents are W3C valid). Any clue on why it was commented ?
Re: [O] HTML export and Zotero-friendly headers
On 11/22/11 3:44 PM, Erik L. Arneson wrote: Do I then understand correctly that what you want to do is simply to generate one COinS snippet with metadata about the document itself (author, title, etc.)? Yes, though it doesn't need to be only COinS. Zotero supports a number of different formats, but COinS looks like it may be the easiest and the most concise. Hi, Does Org document header data include more than author, title, date, description and keywords. So I'd be inclined to go with Dublin Core for this, and just twin the ordinary META tags (which Zotero doesn't bother with, probably wisely) with DC equivalents. Doing it as below, with a hook at the end of html export, is more than a little clumsy, but it will do for testing purposes. If people think it's a good idea to do this in HTML exports on a permanent basis, a non-clumsy version could be patched into org-export-as-html. #+begin_src elisp (defun org-export-with-dc () Add Dublin Core metadata from Org document headers to exported HTML. Comma-separated keywords and multiple authors separated with ` and ' will be correctly imported into Zotero. Note: For testing purposes only. It is only called as a hook from org-export-as-html, where it gets TITLE, DATE, AUTHOR, DESCRIPTION, and KEYWORDS values. (let ((creators (split-string author and )) (subjects (split-string keywords , ?)) fdate) (when (string-match [0-9]+-[0-9]+-[0-9]+ date) (setq fdate (match-string 0 date))) (goto-char (point-min)) (when (re-search-forward /head) (goto-char (match-beginning 0)) (while creators (insert (format meta name=\DC.Creator\ content=\%s\/\n (car creators))) (setq creators (cdr creators))) (insert (format meta name=\DC.Title\ content=\%s\/ meta name=\DC.Date\ content=\%s\/ meta name=\DC.Description\ content=\%s\/\n title fdate description)) (while subjects (insert (format meta name=\DC.Subject\ content=\%s\/\n (car subjects))) (setq subjects (cdr subjects)) (add-hook 'org-export-html-final-hook 'org-export-with-dc) #+end_src Yours, Christian
Re: [O] HTML export and Zotero-friendly headers
On 11/23/11 5:45 PM, Erik L. Arneson wrote: Thanks, that looks like a good start! Let me know how it went. Christian
Re: [O] HTML export and Zotero-friendly headers
Hi, Then I misunderstood you, sorry about the noise (to both Eriks, A. and H.). I thought you meant including Zotero-readable metadata for each citation in the Org document. Do I then understand correctly that what you want to do is simply to generate one COinS snippet with metadata about the document itself (author, title, etc.)? Yours, Christian On 11/21/11 10:14 PM, Erik L. Arneson wrote: I thought zotero-plain was used to add citations. What I'm trying to do is use org-mode to export HTML files with Zotero-friendly headers that the Zotero plugin will pick-up on in the browser. I can make the COinSspan snippets myself using the tool available on the COinS website, but it would be handy if org-mode could do that automatically using the org header data that already exists.
Re: [O] HTML export and Zotero-friendly headers
Hi, Adam Smith, You're repeating my misunderstanding -- that's not what he's looking for, see the thread above. Christian On 11/22/11 7:35 PM, adam.smith wrote: Yes, though it doesn't need to be only COinS. Zotero supports a number of different formats, but COinS looks like it may be the easiest and the most concise. You're aware that bibliographies exported as HTML from Zotero already contain COinS?
Re: [O] HTML export and Zotero-friendly headers
Hi, Does Erik Hetzner's zotero-plain work for you? If so, I'd try this experiment: set zotero-default-bibliography-style to COinS. Then insert a citation in Org using zotero-plain. In the link description, instead of a nicely formatted bibliographic reference, I imagine you should get the COinS data. If that works, zotero-plain could be very easily extended with a function to insert COinS data for all items in zotero links, and it could be run as a hook on HTML export. It hasn't worked for me lately, so I can't try the experiment myself. Yours, Christian On 11/21/11 7:19 PM, Erik L. Arneson wrote: Howdy, I've just stumbled across Zotero and have been reading about how folks are working to integrate it with org-mode, but from what I've read so far, all of the work has been on the citation end. Has anybody pursued creating Zotero-friendly headers/metadata in HTML exports? I use org-mode to manage a few websites and it would be handy to have the HTML snippets generated automatically. It looks like both COinS[1] and Dublin Core are fairly straightforward. I'm looking forward to hearing if anybody has done anything with this yet. Thanks, Erik Footnotes: [1] http://ocoins.info/
Re: [O] How to estimate effort by week?
Christoph LANGE ch.la...@jacobs-university.de writes: is there any way of estimating effort by week? Have a look at the doc string of org-effort-durations. Documentation: Conversion factor to minutes for an effort modifier. Each entry has the form (MODIFIER . MINUTES). In an effort string, a number followed by MODIFIER is multiplied by the specified number of MINUTES to obtain an effort in minutes. For example, if the value of this variable is ((hours . 60)), then an effort string 2hours is equivalent to 120 minutes. -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] BABEL -- PROPERTY?
On 11/16/11 9:21 AM, Michael Hannon wrote: (2) I typically use the following BABEL line: #+BABEL: :session *R* :cache yes :results output verbatim :exports both :tangle How would I express that using the PROPERTY syntax? #+PROPERTY: session *R* #+PROPERTY: cache yes #+PROPERTY: results output verbatim etc. Or if you've got everything under the same (parent) heading: * Top-level heading :PROPERTIES: :session: *R* :cache: yes :results: output verbatim :exports: both :tangle: yes :END: hth, Christian
Re: [O] zotero plain, org-odt, and citations in general
* Towards a solution for Zotero - Org - ODT
I think I have a way to get Zotero references from Org links into ODT
as working reference marks. Interested parties, please
test if this works for you at all.
1. Create Zotero links such as e.g.:
: [[zotero:0_RADJMJ8Q][{Bolin, 1958}]]
Below, I include code for a simple Zotero export translator
(OrgMode.js) that will create such links at a keystroke/mouse drag,
since some of us are currently experiencing difficulties with
zotero-plain.
2. Define a custom link export function to fake a Zotero field code
for ODT. Code below.
3. Export to ODT and do the things you normally do with Zotero, like
generating a bibliography. (Note that Zotero won't let you insert a
bibliography until you've inserted at least one Zotero reference
from within LibreOffice. You can always delete it afterwards.)
If this works for you, the code (which is a quickly thrown-together
mess) can probably be improved on.
Yours,
Christian Moe
** OrgMode.js translator
Installation:
1. Tangle or copy the below to a file called OrgMode.js.
2. Place it in the Zotero translators folder (on Mac, that's
~/Library/Application
Support/Firefox/Profiles/[PROFILENAME]/zotero/translators/
3. Restart Firefox.
4. Open Zotero Actions (the cogwheel icon) Preferences. From the
drop-down menu, select Org-mode as the Quick Copy default format.
Use: you can
- drag and drop references from the Zotero panel to the Emacs buffer,
or
- Quick Copy to clipboard with Shift-Cmd-C (Mac) and yank in the
Emacs buffer
#+name: OrgMode.js
#+begin_src javascript
{
translatorID: b0006c6f-b743-4508-beaf-490bbd68a403,
label: Org-mode,
creator: Christian Moe,
target: org,
minVersion: 2.1.9,
maxVersion: ,
priority: 200,
displayOptions: {
exportCharset: UTF-8,
exportNotes: true,
exportFileData: false
},
inRepository: false,
translatorType: 2,
browserSupport: gcs,
lastUpdated: 2011-11-12 17:05:00
}
// Loosely based on Scott Campbell's ZotSelect.js
// posted at
http://forums.zotero.org/discussion/8306/testing-zoteroselect/
function doExport() {
// Zotero.write(zotero://select//);
// Zotero.write(\n);
var item;
var notfirst = false;
while(item = Zotero.nextItem()) {
// Separate multiple links
if (notfirst) {
Zotero.write(; )
}
// Org link path
Zotero.write([[zotero:);
var library_id = item.LibraryID ? item.LibraryID : 0;
Zotero.write(library_id+_+item.key);
// Org link descr
Zotero.write(][{);
// create a unique citation key
//var descr = buildCiteKey(item, citekeys);
// write citation key
//Zotero.write(/+citekey);
// Authorname
if(item.creators item.creators[0] item.creators[0].lastName) {
Zotero.write(item.creators[0].lastName);
} else {
Zotero.write(n.a.)
}
// Separator
Zotero.write(, )
// Year
var numberRe = /^[0-9]+/;
if(item.date) {
var date = Zotero.Utilities.strToDate(item.date);
if(date.year numberRe.test(date.year)) {
Zotero.write(date.year);
}
} else {
Zotero.write(n.d.);
}
// Close Org link
Zotero.write(}]])
notfirst = true;
}
}
#+end_src
** Zotero link type
Evaluate the following (or place it in your .emacs for repeated use).
Note that clicking the links does not work on Mac and probably won't
work on Linux/Windows, either (but please let me know if it does!).
Consider org-zotero-open a placeholder for now.
#+begin_src elisp
(org-add-link-type zotero
'org-zotero-open
'org-zotero-export)
(defun org-zotero-open (path)
(browse-url (format zotero://select//%s path)))
(defun org-zotero-export (path desc format)
(cond
((eq format 'odt)
(let
((refmark text:reference-mark-start
text:name=\%s\/%stext:reference-mark-end text:name=\%s\/)
(zitem ZOTERO_ITEM
{quot;citationIDquot;:quot;%squot;,quot;citationItemsquot;:[{quot;uriquot;:[quot;http://zotero.org/users/local/%s/items/%squot;]}]}
%s)
(citation-id (substring (org-id-new) -10)) ; Is this a
good way to make a unique ID?
(library-id (car (split-string path _)))
(item-key (car (cdr (split-string path _
(rnd (concat RND (substring (org-id-new) -10
(setq zitem
(format zitem
citation-id
library-id
item-key
rnd))
(setq desc (format (%s) desc))
(format refmark zitem desc zitem)))
(t desc)))
#+end_src
[O] [ODT] [BUG?] Custom links are formatted as for html
Hi, Jambunathan,
When I try to define a custom link type with special formatting for
ODT export, the exporter behaves as if the backend is html.
I'll exemplify with a tweaked version of org-bbdb-export, since that's
the textbook example of a custom link. I've rewritten it below so that
if the export FORMAT is 'odt, BBDB links should be in bold.
(defun org-bbdb-export (path desc format)
Create the export version of a BBDB link specified by PATH or DESC.
If exporting to either HTML or LaTeX FORMAT the link will be
italicized, in ODT it's bold, in all other cases it is left unchanged.
(when (string= desc (format bbdb:%s path))
(setq desc path))
(cond
((eq format 'html) (format i%s/i desc))
((eq format 'latex) (format \\textit{%s} desc))
((eq format 'odt) (format text:span
text:style-name=\Bold\%s/text:span desc))
(t desc)))
Now, when I export this:
Here's my own address (bbdb:Moe).
...the ODT document does not contain the expected:
Here's my own address (text:span
text:style-name=\Bold\Moe/text:span).
...instead, it contains the formatting intended for HTML:
Here's my own address (iMoe/i).
...which, of course, displays as:
Here's my own address ().
Yours,
Christian
Re: [O] [ODT] [BUG?] Custom links are formatted as for html
On 11/12/11 10:24 PM, Jambunathan K wrote: When I try to define a custom link type with special formatting for ODT export, the exporter behaves as if the backend is html. I have pushed a fix for this. Note that I haven't modified org-bbdb yet. Hi, I confirm that it's fixed. Thanks! Just to be clear, I only used org-bbdb as an example, I wasn't planning to change it (but what I *was* trying to do with custom links and ODT was a bit too involved for a minimal example). (And I did not mean to imply that changing it is your job.) Yours, Christian
Re: [O] zotero plain, org-odt, and citations in general
On 11/11/11 5:12 PM, Erik Hetzner wrote: At Fri, 11 Nov 2011 10:51:22 -0500, Matt Price wrote: Wouldn't the rigt target be, not the sqlite db, but the Zoteor*service* that runs on port 50001 when Zotero is running? Aren't there some higher-level tools for working through that interface -- e.g., erik, your rst tool uses a python library, does it talk to Zotero that way? the server that runs on port 50001 is undocumented, last I checked. And there are no tools to connect to it. Frank Bennett put together a hack of the jsbridge Firefox extension which works quite well. [1] But that is python only, as far as I can tell. A good while back -- before zotero-plain -- I spent some late nights eavesdropping on SOAP talk between OpenOffice and Zotero, and writing a Perl script to emulate some of it. It wasn't fun, and though I had some basic functionality going for a while,
Re: [O] zotero plain, org-odt, and citations in general
On 11/13/11 12:45 AM, Christian Moe wrote: A good while back -- before zotero-plain -- I spent some late nights Sorry about the noise: I didn't mean to send this fragment. Please ignore. Christian
Re: [O] zotero plain, org-odt, and citations in general
On 11/10/11 5:53 AM, Erik Hetzner wrote: It works for me, with MozRepl 1.1beta2, and the latest Zotero plain. Thanks. If that's with the latest Firefox too (apparently I'm on 8.0, Mozilla's new approach versioning makes me dizzy), there must be some problem with my setup. I'll try to figure it out. Yours, Christian
Re: [O] problems with mathjax CDN and HTML export
On 11/8/11 5:09 PM, Giovanni Ridolfi wrote:
Yes, You're right. It is exported correctly and correctly formatted
if you export only *this* subheading. The subheading ** $$.
But, if you export the whole subtree, from the
* mathjax test heading, the equation is
converted in HTML format e.g.:alpha; = \frac{1}{Lsub0/sub}
Giovanni
Ah, I see.
The problem is that the $$ in the subheading is interpreted as an
unclosed math snippet. (Interesting that it's still exported as a
heading.) After that, math closes when it should open.
Try closing the subheading: * $$ $$ and exporting again.
Getting $$ as a subheading is not quite straightforward, but the
following will work. Create a user-defined dollar-sign entity (org
doesn't have one by default):
(setq org-entities-user
'((dollar \\$ nil #36; $ $ $)))
Now * \dollar\dollar should work.
Yours,
Christian
Re: [O] org-capture-template: How to correctly capture email addresses?
Hi,
If org-contacts-template-email doesn't find an address, it doesn't
insert a simple text prompt, it inserts a property prompt, which sets
the property. A property prompt does not need to be positioned in an
explicit property drawer in the template -- in fact, it looks like
that will not work.
Removing the EMAIL property and moving the
%(org-contacts-template-email) field out of the property drawer works:
(setq org-capture-templates
'((t TODO in ~/org/agenda.org - Tasks entry (file+headline
~/org/agenda.org Tasks)
* TODO %?\nSCHEDULED: %^t\n%U %a)
(c Contact in ~/org/contacts.org - Contact entry
(file+headline ~/org/contacts.org Contact)
* %?%(org-contacts-template-name) %^g
%(org-contacts-template-email)
:PROPERTIES:
:URL:
:WORK:
:HOME:
:MOBILE:
:LOCATION:
:BIRTHDAY:
:NOTE:
:END:)))
You still get EMAIL at the end of the property drawer, but the order
is arbitrary anyway. You could replace the whole properties drawer
with property prompts:
(setq org-capture-templates
'((t TODO in ~/org/agenda.org - Tasks entry (file+headline
~/org/agenda.org Tasks)
* TODO %?\nSCHEDULED: %^t\n%U %a)
(c Contact in ~/org/contacts.org - Contact entry
(file+headline ~/org/contacts.org Contact)
* %?%(org-contacts-template-name) %^g
%(org-contacts-template-email)
%^{URL}p %^{WORK}p %^{HOME}p %^{MOBILE}p
%^{LOCATION}p %^{BIRTHDAY}p %^{NOTE}p)))
...but then you'd be prompted for everything, each time; you may not
want that.
Yours,
Christian
Re: [O] zotero plain, org-odt, and citations in general
Hi, Is zotero-plain working for others? I test drove zotero-plain back when it was just developed. Looked promising, but I had uneven success with the MozRepl communication, possibly something to do with being on an older and slower machine. Trying it again today (with the most recent zotero-plain, MozRepl and moz.el I could find), I press `C-c z i' to insert a citation and nothing happens. Well, the Org buffer hangs until I press C-g, and except that the *MozRepl* buffer says Process MozRepl deleted. Yours, Christian
Re: [O] org-taskjuggler export problems
Hi Johnny yggdra...@gmx.co.uk writes: I am trying to export a simple project plan from org to taskjuggler through org-taskjuggler.el. I cannot get the behavour I expect and need do some manual tweaks to get the taskjuggler file working. What am I doing wrong? You're not doing anything wrong. You've hit some bugs in the taskjuggler exporter. 1) The 'end' date specified in the ':taskjuggler_project' base is ignored and the default 280d is used. Because the project duration is long this throws an error. The 'start' date however seems properly picked up. Indeed the end date is not picked up. I remember to have tried to fix this once, but the problem is that the root task serves as both a container for the project attributes and is a task at the same time. So if you define the end, you'll both define the end of the project and the task, which might not be what you want. Can you try to increase the org-export-taskjuggler-default-project-duration instead? 2) The 'task_id' fields are not exported properly. The taskjuggler exporter uses the task_ids you define just for dependency resolution. Other than that it creates automatic ids based on the title of the task. The assumption is that you are not that interested in defining ids. What do you need them for? 3) The 'precedes' property is not exported at all Yes, this is not implemented. Could you use 'depends' instead? And possibly use alap scheduling? Hope that helps Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] problems with mathjax CDN and HTML export
On 11/7/11 5:02 PM, Giovanni Ridolfi wrote:
the math snippets are always converted in HTML format e.g.:alpha; =
\frac{1}{Lsub0/sub}
Do I understand correctly that this is your problem? (Not very clear
from your long example, which starts with the CDN service.)
If so, I can't reproduce it. Your
$$
\alpha = \frac{1}{L_{0}} \left( \frac{L_2-L_1}{T_2-T_1} \right)
= \frac{1}{L_0}\frac{\Delta L}{\Delta T}
$$
exports verbatim for me, and is correctly formatted.
Yours,
Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/3/11 2:26 AM, Bastien wrote: Hi Nicolas, Nicolas Goazioun.goaz...@gmail.com writes: (...) There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 Correct me if I'm wrong, but the purpose of #+BIND is to specify a file local variable, isn't it? The manual gives one example of how to modify export settings with it. With Babel blocks, there should be clarity what variables are to be passed to the block as arguments, and what variables should not. Currently this is completely clear: Only variables named in a `var' property or header argument are passed. Using =#+bind foo 1= would be ambiguous; you wouldn't know when it's for Babel and when it's not. Say we make Babel use BIND values, and someone has this setup: #+BIND: org-export-latex-low-levels itemize #+BIND: foo 1 #+BIND: bar 2 Then this: #+BEGIN_SRC emacs-lisp (+ foo bar) #+END_SRC would tangle to something like: (let ((org-export-latex-low-levels (guote itemize)) (foo (quote 1)) (bar (quote 2))) (+ foo bar)) -- which was not the intention. Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/3/11 2:42 AM, Bastien wrote: But allowing a top-level :PROPERTIES: drawer with properties whose scope is the entire file looks like a good idea to me. How other would feel about this? Not sure if this is already clear, but just in case: The functionality is already there. PROPERTY lines set buffer-wide properties. This works now: #+TITLE: My foobar file #+PROPERTY: foo 1 #+PROPERTY: bar 2 #+PROPERTY: baz 3 Replacing it with a top-level property drawer before the outline would make another bit of syntax redundant, and it would sometimes save a bit of typing (if there are many buffer-wide properties tobe set): #+TITLE: My foobar file :PROPERTIES: :foo: 1 :bar: 2 :baz: 3 :END: I have come to expect that any file-wide settings are in #+... lines and that any property drawers are associated with outline entries. I don't know how important it is to maintain those expectations. Yours, Christian
Re: [O] Video showing Jambunathan's ODT exporter
On 11/3/11 8:57 PM, Herbert Sitz wrote: This is some seriously cool functionality for Org that deserves wider exposure. Jambunathan's done a great job. +1 Christian
[O] FSF assignment
Hi, I've signed the FSF papers (assignment 711933). Bastien, shall I just add myself to the list, or is there more procedure? Yours, Christian Moe
Re: [O] wrap long table formula
On 11/1/11 8:17 AM, henry atting wrote: I was thinking of a column formula but have no clue if it's possible and if so, how. In this short example the formula's length is no problem but for a table with 12 rows or more it certainly is; -- and currently it's the only way I can realize it. | | | |---+---| | 2 | | | 6 | 4 | | 7 | 5 | #+TBLFM: @3$2=vmean(@2$1..@3$1::@4$2=vmean(@2$1..@4$1 | | | |---+-| | 2 | | | 6 | 4 | | 7 | 5 | | 3 | 4.5 | | 9 | 5.4 | #+TBLFM: @3$2..@$2=vmean(@2$1..@0$1) hth, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 10/31/11 10:36 PM, Eric Schulte wrote: 4. My own idea of allowing any defined property to be passed as an argument to src blocks (which would require some changes to how Babel reads its :var header args). I do see how this approach could be powerful, however I fear both the size of the change and the potential negative consequences of combining the property and variable name spaces. Well, you would know better than me on both scores, so I'll stop pushing. Thanks for considering it. Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/1/11 5:58 PM, Eric Schulte wrote: so assuming var is an accumulating property, then #+property: var foo=1 #+property: var bar=2 would result in `org-file-properties' having the following value ((var . foo=1 bar=1)) Given this: --- #+property: var foo=1 #+property: var bar=2 * Heading :PROPERTIES: :var: foo=3 :END: --- Would it result in ((var . foo=3 bar=2))? Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/1/11 8:02 PM, Eric Schulte wrote: As for variable handling, I think the solution is to ensure that on the code-block side of things, a var string like foo=3, bar=2, foo=1 results in, foo=1 bar=2 that is, subtree variable definitions will pre-empty earlier definitions of the same variable.. Yes, that sounds like the way to go. My previous message implied that the var string should only contain unique variable names, but I see that that would be needlessly complicated. This is an interesting approach; I like it better than the property block. I'm sure we will think of other useful applications for cumulative properties, too (conversely, there'll probably be some side effect that will turn around and bite us at some point, though I can't think what it would be). Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Hi, Having followed the thread on Babel and properties after the removal of the #+BABEL headers, I understand the motivation for introducing this. But I share Nicolas' feelings that a property block doesn't rhyme with existing usage of blocks and properties. There were many other ideas that came up: 1. PROPERTY+ lines (as discussed in Eric's message above). 2. A similar approach to the table formula editor (C-c ') for properties. 3. Allowing some properties to accumulate values, in particular making the :var: property for Babel blocks cumulative (slightly different versions suggested by Eric and Darlan; either would require some changes to Org's property handling), and 4. My own idea of allowing any defined property to be passed as an argument to src blocks (which would require some changes to how Babel reads its :var header args). Solutions 1-2 would solve the long lines problem. Solutions 2-4 would avoid introducing new syntax (#+BEGIN_PROPERTY or #+PROPERTY+) largely to make up for having removed old syntax (#+BABEL). Solutions 3-4 would have wide-ranging effects and would need some careful study, but I think the advantages might outweigh the risks. Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 10/31/11 9:49 PM, Nicolas Goaziou wrote: #+begin_src org #+property: :var foo=1 #+property: :var bar=2 #+property: :var baz=3 #+property: :var qux=4 #+end_src Two problems: 1) You need to drop the colons before var. 2) The outcome is not what you expect. #+property: var foo=1 #+property: var bar=2 #+property: var baz=3 #+property: var qux=4 #+begin_src perl :results output print foo is $foo, bar is $bar, baz is $baz, qux is $qux #+end_src #+results: : foo is 1, bar is , baz is , qux is Because as things currently work, further assignments to the same property (var) by subsequent #+PROPERTY lines are ignored. (Whereas further assignments to the same property in property drawers further down an outline tree will `overwrite' assignments higher up.) Yours, Christian
Re: [O] [ANN][RFC] org-odt.texi/org-odt.pdf preview (was Re: Org-odt table format)
Hi, Great, I'll just wait for your revised draft so we don't get versions mixed up. Yours, Christian On 10/28/11 6:19 AM, Jambunathan K wrote: I will work on your suggestions and circulate a revised draft shortly. Once an initial org.texi gets in to the repo, improving it would be a breeze.
Re: [O] [ANN][RFC] org-odt.texi/org-odt.pdf preview (was Re: Org-odt table format)
Hi, Jambunathan, This is great. I'd be happy to proofread. What's the best way to return the proofs to you? A diff of the .texi? A couple of questions and suggestions. First, about the syntax rather than about the manual: - Image attributes: Are the parentheses needed in the ATTR_ODT line? (This is not about the manual, but about the syntax.) It would be simpler and generally more consistent with user expectations from other ATTR lines, I think, if it worked like this: #+ATTR_ODT: :width 10 :height 10 About the manual: - Literal examples: - Add a hint, where does one get an enhanced htmlfontify.el? - References and captions (not covered): It would be worth mentioning in the Tables and Images sections that these will work, but that you may need to use ToolsUpdateFields in LibreOffice to get them displayed right. - There are some long technical sections that are great if you want to get under the hood, but may be a bit intimidating, and that come before the short first-aid stuff. You might want to consider: - Starting Applying Custom Styles with a simple howto setting out the user-friendly steps: export an ODT (with num:t and any other settings needed to get all the styles), tweak its looks in LibreOffice (preserving heading numbering as an option), save the result and point to it with ODT_STYLES_FILE. (As it is, the manual gives a strong impression that the user will have to mess with XML files to get custom styles.) - Possibly moving Exporting and Converting to Other Formats to the end of the manual. - Possibly separating out the explanation of custom table styles as a separate section and moving it to the end of the manual. (BTW, custom table styles sounds great, I'm looking forward to trying this out.) Yours, Christian On 10/26/11 8:04 PM, Jambunathan K wrote: The org-odt.texi and org-odt.pdf are in the parent of this mail. It is also accessible as attachment at http://article.gmane.org/gmane.emacs.orgmode/48468 Proof readers invited.
Re: [O] Bug: Remote reference (@$1) doesn't work while ($LR1) works. [7.7]
Reproduced. I think this qualifies as a bug. Yours, Christian
Re: [O] Bug: Remote reference (@$1) doesn't work while ($LR1) works. [7.7]
Yes, that fixed it. Thanks! Yours, Christian On 10/27/11 6:13 PM, Carsten Dominik wrote: This should be fixed now, please verify. Thanks! - Carsten
Re: [O] [RFC] Standardized code block keywords
Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. Ditto -- it just wasn't on the table yet when I cast my vote. Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
for that, and would be equally happy to see that solution extended to solve your problem. Yours, Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/24/11 2:11 PM, Sebastien Vauban wrote: (...) But I just have a comment on your second advantage, something that can render your example inefficient: inheritance is not on by default, and you need to enable if for *specific properties*. You can set `org-use-property-inheritance' to t, to make all properties inheritable, or you can set it to a list to enable specific properties. I suppose you meant that the former would be a bad idea. (And it could be, depending on your working habits, file size, outline nesting depth and the speed of your machine.) But you're right, property inheritance is not on by default and I forgot to mention that this time around. (I think I did mention it in the previous long message where I presented the idea.) Make it on by default would be a very bad idea -- just think at examples of the mails sent through Org-mime: what about setting a Cc or To somewhere and inheriting that in all the file/subtree/etc. May be scary or inefficient performance-wise? Anyway, setting inheritance of properties to on, means you should declare the behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you say that var: x, y, z does that too (then you've two things in one shot -- why not?). Yes, if my suggestion becomes reality, this could be a useful refinement. Yours, Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/21/11 8:40 PM, Rainer M Krug wrote: Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? Wow. I guess I was wrong to imagine your problem was solved. If your code blocks share the same language, and it supports sessions, I'd bite the bullet and transform them into #+HEADERS lines for the first src block, then reuse them through a session. Does that make sense? If your variables are going to be used by different src blocks in different languages, I don't have any elegant solution. Yours, Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
somelocalvar=something or other
#+BEGIN_SRC Perl
while(...) {
...
}
#+END_SRC
This should expand to something like:
#!/usr/bin/perl
use warnings;
my $MAINVERSION = 1;
my $SVNVERSION = 0.4.13;
my $SVNSTATE = something or other
my $SVNSTATENUM = 13;
my $DISP_PACKAGE = seedDisp_0.4-13.tar.gz;
my $somelocalvar = something or other;
while(...) {
...
}
---
OK, hopefully my idea is clear by now.
Could it be made to work?
Would it solve some problems?
Would it mess other things up even worse?
Yours,
Christian
Re: [O] [RFC] Standardized code block keywords
I disagree with Tom on [1]: it should clearly be srcname, in analogy to #+tblname - and also so I don't have to change my files :-} (but see my question about tblname below). I'll have to change my files, either way. The price one pays for inconsistency. But as I've recently learned from Carsten, it should be a one-liner in Perl. :-) For the sake of analogy, I'll cast my vote for SRCNAME, even if SOURCE is more aesthetically pleasing. I agree on [2] call. +1 I'm confused by [3] so I will say nothing for now, except to ask some questions: are we talking about what a human would use to label a piece of data for consumption by a block (including perhaps the future possibilities of lists and paragraphs that Tom brought up)? what babel would use to label a results block (possibly so that it could be consumed by another block in a chain)? both? would that mean that #+tblname would go the way of the dodo and that tables would be labelled with #+data (or #+object or whatever else we come up with)? +1 (Confused, too) I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME don't? A reason to keep TBLNAME is that it's also used by the spreadsheet remote references. If Babel looked for DATA instead, a table that is both a remote reference for another spreadsheet and a data source for a src block would need both TBLNAME and DATA, which seems redundant. As for labeling lists and paragraphs, I recall from the list that Nicolas Goaziou is working on a generalized way to set captions, labels and attributes for various kinds of Org block, as is possible now for tables and images. I thought that sounded promising. I don't know if he planned for block names, too (currently we have tblname but no imgname), but that could make sense. In which case it might be a good idea to coordinate.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi again, I can quickly think of two advantages of the late lamented (if only by me) #+BABEL header over using properties. 1. Allowing you to specify multiple buffer-wide options on the same line (keeping things short), in the same colon :syntax as used in a src block header (keeping things consistent and easy to copy back and forth). None of this makes a substantive difference. 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 If BABEL is dropped for PROPERTY, it would be good for the :var: property to support multiple arguments (comma-separated would be good for consistency with passing arguments through the SRCNAME). E.g.: #+PROPERTY: var euro=1.3791, salestax=.15 I think I'd like this better in any case. Yours, Christian On 10/21/11 9:28 AM, Sebastien Vauban wrote: Multiple lines may be used to specify multiple properties. e.g., #+PROPERTY: results silent #+PROPERTY: cache yes *But* I did not know it was limited to _one property per line_. Knowing that: - there is no confusion at all -- we simply (have to) know that the first word is the name without colon, and the rest are values - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls. To sum up, I'm perfectly happy with the new choice. Best regards, Seb
Re: [O] Asciidoc
Hi Stephen Nelson-Smith sanel...@gmail.com writes: I have a large piece of writing to do, which my publisher wants in asciidoc. I'd prefer to write in orgmode and export as asciidoc. I used to use asciidoc but much prefer orgmode now. Is this feasible? Anyone doing this or done this before? Not directly as far as I know. You have different options: - Export to odt and from there to mediawiki followed by some text munging - Use the generic exporter to generate mediawiki again followed by some text munging - Tweak the generic exporter (don't know how feasible and easy that is) - Write an exporter. For simple ascii exporter that should be doable. There are however different competing starting points. There is an experimental generic exporter by Bastien and there is apparently one by Jambunathan. Can't tell you which one is better. Hope that helps -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] Patch for bug in adjusting time ranges in Agenda
Hi Carsten Carsten Dominik carsten.domi...@gmail.com writes: I have just checked in a slightly modified patch. I think there is a problem with this checkin. The variable org-agenda-move-date-from-past-immediately-to-today is not defined. Should this be a defcustom somewhere? Debugger entered--Lisp error: (void-variable org-agenda-move-date-from-past-immediately-to-today) org-agenda-date-later(1) org-agenda-do-date-later(nil) call-interactively(org-agenda-do-date-later nil nil) Thanks -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/21/11 11:12 AM, Rainer M Krug wrote: On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe m...@christianmoe.com mailto:m...@christianmoe.com wrote: (...) 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 I think it is a very important point, that the construct with :var still works - but as Eric only mentioned the *naming*, I assume that in the actual usage nothing changes. Hi, Rainer, My point was that there is at least one (minor) case where properties are not functionally equivalent to the BABEL line: You cannot pass arguments for more than one variable buffer-wide, because you can't have multiple var properties at the same time, and at present, one var property only sets one variable. The behavior of properties has not changed. What has changed is the removal of the BABEL header, whose colon (:var) syntax did allow you to set multiple variables buffer-wide should you wish to. Yours, Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/21/11 12:59 PM, Rainer M Krug wrote: So, using your above mentioned example, after the first PROPERTY line, euro=1.3795 and SALESTAX not set, while after the second one salestax=.15, and euro is unset? That would be quite bad. That's what I'd expected, but actually, euro is set and salestax is not. Apparently subsequent PROPERTY lines are ignored if they try to set an already existing property. To clarify: before, we could use #+BABEL and #PROPERTY to do similar things. Now the whole #+BABEL has been removed, and only the functionality from #+PROPERTY is left - correct? That's my understanding. And #+PROPERTY offers equivalent functionality in almost every way, but not, as far as I can understand, in this corner case. Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi, Yes, that works nicely, and should solve Rainer's problem. I haven't been able to think of anything else that can't be handled by properties. And I do think it's a good idea to winnow down the syntax a bit, even if things break. I just like to grumble. :-) Yours, Christian On 10/21/11 7:37 PM, Eric Schulte wrote: Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Whoa -- before this gets more confusing: Eric, did you push up a (new, or at least so far undocumented in the manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien seem to understand you? Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY line or :PROPERTIES: drawer, as provided in the manual? Yours, Christian (lamenting the demise of the #+BABEL header I'd just recently started to use) On 10/20/11 10:12 PM, Eric Schulte wrote: Nick Dokosnicholas.do...@hp.com writes: Eric Schulteschulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Best -- Eric
Re: [O] A more universal markup for exporters with italics/quotes?
Hi, On 10/18/11 10:14 PM, John Hendy wrote: - italics: org doesn't handle multiple line italics in between / and /. Tip: You can customize org-emphasis-regexp-components to accept more than one newline. Could there be something like #+begin_quote There is! It makes blockquotes. Just go ahead and use it. Yours, Christian
Re: [O] org-odt: specifying fonts
On 10/19/11 7:54 PM, Jambunathan K wrote: #+ODT_STYLES_FILE: /path/to/styles.xml Perfect. Thanks for the quick response! Yours, Christian
Re: [O] org-odt: specifying fonts
Hi, Mehul,
It's not that I would be opposed to a fonts option, of course, but I
don't see it as a priority or even necessary. As long as org-odt
handles the document structure and semantics right, and allows
attaching an external stylesheet, I think it's done its job.
There are other developments I'm more keen on, like a finalized set of
documented header options for images (those often need to be set on a
per-image basis), or the table styles Jambunathan's been experimenting
with (OpenOffice, eat your heart out!), or simply the definitive
integration of the odt exporter into core Org.
On 10/18/11 11:15 PM, Mehul Sanghvi wrote:
As for fonts, like styles, it
would be easier, simpler and more elegant
to be able to do that without having to edit styles.odt every time.
This is not specific to org-odt. It should be,
at least I think so for now, to do this with any exporting backend.
Some would say tinkering with fonts is a distraction from writing that
having Your Life In Plain Text allows you to get away from. And the
consistent use of styles and templates is anyway good word-processing
practice.
But sure, this is possible in other backends. For html export (which I
know better than latex), one can simply include a header like:
#+STYLE: style * { font-family: Gentium; } /style
to make every element use the Gentium font if available. If I need
more than 2-3 STYLE headers to get a job done, though, I find it
easier, simpler and more elegant to link to an external stylesheet.
HTML comes with the breathtaking power and simplicity of CSS styling;
LaTeX comes with breathtaking power and ... well, at least it's in
plain text that Org can pass on to the relevant backend. ODT is a
slightly different story. Its styles are in XML that was not really
meant to be hand-edited.
If you send me a styles.odt, and I do not like the fonts you are
using, it becomes cumbersome to be editing the styles.odt
for each font and making sure to change it in all possible places
until I settle on a proper font I want to use.
If I could instead specify the font in org file itself, it would be a
matter of changing the header and re-generating the file.
You'd still need to do the cumbersome work of making sure to change it
in all possible places, though. Changing the Default paragraph style
will typically change e.g. the linked Text Body style, too , but not
the headings (they're linked with Heading). So at a minimum, you'd
need options to modify both. And once fonts can be specified, users
will want sizes, weights, colors, borders, etc. Sure, there could be
an extensive options vocab a la:
#+ODT_STYLE: Default :type para :font Gentium :size 12pt
#+ODT_STYLE: Heading :type para :font Arial :size 16pt :weight
bold :color blue :borders ...etc. etc. ...
But is it needed? While Latex, HTML and DocBook users should never be
required to sully their hands with a GUI, when we use ODT we can
reasonably be expected to open up an office application now and again
to modify our templates.
Okay, #+END_RANT...
Yours,
Christian
Re: [O] outline-demote incorrectly demotes leaf nodes
Hi, The Org manual (2.5 Structure editing) says to use M-S-right (org-demote-subtree) for what the submitter wants to do. Yours, Christian On 10/18/11 10:55 AM, Sébastien Delafond wrote: Hello, from Debian bug #645360 (http://bugs.debian.org/645360): Here's my test file, call it c.org: * a ** aa *** aaa I put the cursor at the beginning of the file (at the * in the first line). Then I type C-c C- (i.e. outline-demote). The result is ** a *** aa *** aaa I expected that the last line (the leaf node aaa) would become a fourth-level heading, i.e. aaa. Instead, the fourth * that I was hoping for looks like it became a space. There wasn't any patch provided by the submitter. Cheers, --Seb
Re: [O] org-odt: turning off section numbering does not work
Hi, Jambunathan, On 10/18/11 2:05 PM, Jambunathan K wrote: When you are generating such a custom styles file for templating purposes, it is highly desirable that H:10 num:t be option used. (...) I believe the above restriction is not overly restrictive. No, that makes good sense, and thanks for pointing it out. I can well understand that you don't want to handle num:t isn't working complaints caused by other people's stylesheets. 3. Pointed org-export-odt-styles-file to styles.odt. 4. Exported test-odt.org to test-odt.odt. Result: no headings at all -- everything's in the Default style. (...) I have pushed a fix for this moment ago. Hope things are OK with your setup. Yes, whatever the problem was, it's gone now. Thanks! Yours, Christian
Re: [O] org-odt: specifying fonts
Hi, Mehul, cc: Jambunathan, I agree with Mehul it would be great to have an option to specify a styles file on a per-file basis. Something like: #+ODT_STYLE: ~/org/odt-templates/cv.odt Jambunathan, please consider this a feature request (if you haven't implemented it already, and I've missed it as usual...) Many users will want to use different styles files for different kinds of document (e.g. report.odt, cv.odt). Customizing org-export-odt-styles-file every time they've got a different kind of document to export does not seem the best way. There should be a way for each Org file to remember what ODT style it wants, parallel to the options that exist for html (#+STYLE) and latex (#+LATEX_HEADER). As for specifying fonts, etc., in ODT export, that's definitely something that should be done through the choice of an external style template. The org-odt exporter has done its job if everything you could reasonably want to style is exported in a named paragraph or character style that you can apply a template to. Yours, Christian PS. Mehul, I do have a stopgap solution for specifying the style template on a per-file basis. Place this somewhere in your Org document (e.g. before the first heading), and replace /path/to/template.odt with the path to your styles file. #+begin_src emacs-lisp :results silent :exports results (setq org-export-odt-styles-file /path/to/template.odt) #+end_src On 10/18/11 6:32 PM, Mehul Sanghvi wrote: This may not be specific to org-odt, but maybe applies to Org itself. I have a LaTeX file which I use for my resume at the moment. The fonts that are being used with it are great for what I want. How do I specify fonts that I want to use, rather then the defaults? Do I have to do that through styles.odt ? If so, is there a specific OPTION for specifying the style file to use ? That would be a nice enhancement if it is not already there. I may want to use different styles/fonts, etc. and probably do not want to play around with the styles.odt file each time I make changes to the styles.odt file.
Re: [O] org-odt: turning off section numbering does not work
Hi, According to this thread, num:nil should work in recent versions of Org: http://comments.gmane.org/gmane.emacs.orgmode/46058 It works for me. You might try updating to the most recent version of Org and see if that fixes things. As a one-off fix, in OpenOffice you can turn off the numbering with Tools Outline Numbering. For each of the three heading levels that are numbered, you need to set Number to None, and delete the dot in Separator After. Yours, Christian On 10/17/11 4:07 PM, Mehul Sanghvi wrote: I have the following in my org file: #+OPTIONS: toc:nil H:10 num:nil Yet in my ODT file I get numbered sections: 1. Work Experience 1.1.1 Company A 1.1.2 Company B 2. Skills 3. Education Am I doing something wrong ? Or is there another option that I am not aware of ?
Re: [O] org-odt: turning off section numbering does not work
That probably explains it, then. But, uh, can I borrow this thread for a moment? I find custom styles in ODT export aren't working as per the manual, section 12.8.2. Here's what I've done (test files attached; Emacs 23.3.1; Org 7.7, freshly pulled): 1. Exported test-odt.org to ODT with default settings. 2. In OpenOffice: Changed the Heading 1 style in the exported ODT document to red, then saved it as styles.odt. 3. Pointed org-export-odt-styles-file to styles.odt. 4. Exported test-odt.org to test-odt.odt. Result: no headings at all -- everything's in the Default style. This is how I understand the manual, and the thread I referenced before, and I remember having tested it before at some point when it worked perfectly, so I'm rubbing my eyes and wondering if it's just me. Could I ask someone to please check? Yours, Christian On 10/17/11 8:31 PM, Mehul Sanghvi wrote: On Mon, Oct 17, 2011 at 14:00, Nick Dokosnicholas.do...@hp.com wrote: My (factually-baseless but best-that-I-can-do given the paucity of information you provide) guess is that you are not running the version you think you are running. Nick What I have is Org-mode version 7.5 (baseline.533.ga5129.dirty), so it seems your factually-baseless guess is correct. % git remote -v origin http://repo.or.cz/r/org-mode/org-jambu.git (fetch) origin http://repo.or.cz/r/org-mode/org-jambu.git (push) I have been pulling from the wrong repository. cheers, mehul #+title: Test ODT export #+options: toc:nil num:nil (setq org-export-odt-styles-file ~/org/odt/styles.odt) * Heading Bla bla * Heading ** Subheading Bla bla test-odt.odt Description: application/vnd.oasis.opendocument.text styles.odt Description: application/vnd.oasis.opendocument.text
Re: [O] Export as HTML does not preserve nonstandard entities as TODO signs
Hi, I can't reproduce this. After adding your example to a test buffer and re-saving the buffer, I get the expected html export. (Before resaving, the buffer was still exported in iso-8859-1, producing garbage -- but not underscores -- in html; after resaving, in utf-8.) With point in your example buffer, what does `C-h v buffer-file-coding-system' say? Yours, Christian On 10/14/11 5:47 PM, Arne Babenhauserheide wrote: Hi, I started using ✔ and ❢ as replacement for DONE und TODO and I realized that they get replaced by an underscore (_) in HTML output. Since I really like using symbols for TODO and DONE¹, I wanted to ask, if this is a bug. Best wishes, Arne ¹: Just compare: * ✔ Sent bug question * ❢ check for response and * DONE Sent bug question * TODO check for response PS: I actually have ✔ on my keyboard, and C-c C-t makes it easy to use any kind of symbol for TODO states which is supported by the font.
Re: [O] Export as HTML does not preserve nonstandard entities as TODO signs
Hi, First, sorry about the noise: I had failed to activate your symbols as TODO keywords. Now I do reproduce your results. It also doesn't seem to help to add your special characters to Emacs word syntax, as the FAQ says you should. http://orgmode.org/worg/org-faq.html#sec-9-6 I think there's a bug in org-html.el (org-export-as-html), around line 1611. A function that is meant to get a valid class name for the todo keyword is not called when the class attribute of the span tag is inserted, but a line below, where the visible text content of the span tag is inserted. I'm posting a patch. Yours, Christian
[O] [PATCH] Re: Export as HTML does not preserve nonstandard entities as TODO signs
Correct html export of todo keywords * org-html.el (org-export-as-html): Apply org-export-html-get-todo-kwd-class-name to the the class attribute of the todo-keyword span tag, not to its text content The problem was that special characters in todo keywords were being replaced by underscore. This was meant to happen to the class attributes set around them. TINYCHANGE This only swaps two arguments to a concat. diff --git a/lisp/org-html.el b/lisp/org-html.el index a2a9426..47adfd2 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -1608,9 +1608,9 @@ lang=\%s\ xml:lang=\%s\ (if (member (match-string 2 line) org-done-keywords) done todo) - (match-string 2 line) - \ (org-export-html-get-todo-kwd-class-name - (match-string 2 line)) + (org-export-html-get-todo-kwd-class-name +(match-string 2 line)) + \ (match-string 2 line) /span (substring line (match-end 2) ;; Does this contain a reference to a footnote?
Re: [O] Bug: spreadsheet [7.7]
I have made a brute force solution for this issue, pressing C-c C-c on a #+ line will remove these overlays first. Not nice, but it helps with this problem. - Carsten make complains: org.el:18170:33:Warning: reference to free variable `org-table-coordinate-overlays' org.el:18171:17:Warning: assignment to free variable `org-table-coordinate-overlays' org.el:18172:54:Warning: `t' called as a function org.el:18177:71:Error: Invalid read syntax: ) Yours, Christian
Re: [O] org-odt: turning off Table of Contents
On 10/16/11 4:03 PM, Mehul Sanghvi wrote: I do not want a table of contents as it makes no sense for a resume. How do I disable the generation of that ? I ran the unit test for ODT and it generated a ToC, although I didn't see anything in the test.org file to indicate such a behaviour. In the #+OPTIONS line, set toc:nil http://orgmode.org/manual/Export-options.html#Export-options Hope this helps, Christian
Re: [O] Idea: insert current sort order property
Hi, Not sure I can help; I don't quite see how this error could be caused by anything in the code I sent you. Is this happening on the same system as you used before? What version of Emacs are you on when this happens? Yours, Christian On 10/13/11 1:40 PM, Gez wrote: Thanks. I got it to work from a scratch buffer but not from .emacs (previous version worked fine from my .emacs). Restarting emacs showed an error. --- Warning (initialization): An error occurred while loading `q:/Q_Synced/Portable/emacs-23.3/home/.emacs': Invalid read syntax: # 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. - I couldn't copy the whole backtrace here (an encoding issue?) Here's the start and end of it in case it's any help: ___ Debugger entered--Lisp error: (invalid-read-syntax #) eval-buffer(#buffer *load* nil q:/Q_Synced/Portable/emacs-23.3/home/.emacs nil t) ; Reading at buffer position 13136 load-with-code-conversion(q:/Q_Synced/Portable/emacs-23.3/home/.emacs q:/Q_Synced/Portable/emacs-23.3/home/.emacs t t) load(~/.emacs t t) #[nil un-pastable stuff snipped [init-file-user system-type user-init-file-1 user-init-file otherfile source ms-dos ~ /_emacs windows-nt directory-files nil ^\\.emacs\\(\\.elc?\\)?$ ~/.emacs ^_emacs\\(\\.elc?\\)?$ ~/_emacs /.emacs t load expand-file-name init file-name-as-directory /.emacs.d file-name-extension elc file-name-sans-extension .el file-exists-p file-newer-than-file-p message Warning: %s is newer than %s sit-for 1 default alt inhibit-default-init inhibit-startup-screen] 7]() command-line() normal-top-level() _ Gez
Re: [O] Idea: insert current sort order property
Hi,
You can copy the code into a buffer and `evaluate' it, i.e. teach
Emacs the new function for this session. You evaluate an elisp
expression by placing point right after the last closing parenthesis
and pressing `C-x C-e'. When you do, the minibuffer should display the
name of the function.
After this, Emacs will only remember the function for the rest of the
session. If you like it and want it available the next time you start
Emacs, just copy it into your .emacs file (only the bit *between* the
#+BEGIN_SRC and #+END_SRC lines).
This is the basic drill for using little snippets of code that don't
merit a file of their own.
Since this is an interactive function, you can call it with `M-x'.
Place point in the appropriate parent entry in your music outline and
try `M-x cm/org-store-outline-order'.
Options:
- Since the code in this case is surrounded by a #+BEGIN_SRC block, if
you copy it into an Org buffer, you can also evaluate it simply by
`C-c C-c' with point anywhere on the code block.
- You can change the name and drop the `cm/' prefix if you like (I
just use it as a reminder this is my hack, not part of Org-mode).
Yours,
Christian
On 10/12/11 1:35 PM, Gez wrote:
Thanks, Christian. Please forgive my ignorance but what should I do
with the code? I've not done anything more advanced than
org-customize before.
Gez
On 11 October 2011 20:46, Christian Moe m...@christianmoe.com
mailto:m...@christianmoe.com wrote:
Hi, Gez,
On 10/7/11 5:02 PM, Gez wrote:
What I'm imagining is a command executed on a headline to insert a
property into each of its children fixing the current order;
something like :sorted:01, :sorted:02 etc.
I think this is a neat idea, and can see some uses for it for my
own stuff. I've made a first pass below. Please test it and let me
know how it works for you (and please *don't* test it on anything
valuable without backing up first!).
snip
Code follows.
Yours,
Christian
#+begin_src emacs-lisp
(defun cm/org-store-outline-order (arg prop)
Store the outline of the subtree of the entry at point by
setting the property PROP of each direct child entry to its
current position in the tree. With prefix ARG, store the position
of the whole subtree. The tree can be restored to the stored
outline by sorting on the property with `C-c ^ r'. Note that this
will only work properly on the order of each subtree; if headings
are demoted, promoted, or moved into different subtrees, the
result may or may not be nonsense, but it will be impossible to
restore the original order by sorting.
(interactive P\nsProperty key (default OutlineIndex): )
(if (string= prop ) (setq prop OutlineIndex))
(if (or (not (org-map-entries t (concat prop ={.}) 'tree))
(y-or-n-p Property exists; overwrite? ))
(let* ((match (format LEVEL%s%s
(if arg = =)
(1+ (org-current-level
(counter 1)
(width (1+ (floor (log10 (length (org-map-entries t
match 'tree))
(fstr (concat %0 (number-to-string width) d)))
(org-map-entries
'(progn
(org-set-property prop
(format fstr counter))
(setq counter (1+ counter)))
match 'tree)
(message
#+end_src
Re: [O] Idea: insert current sort order property
On 10/12/11 5:59 PM, Gez wrote:
I do use revisioning, but Is there a protocol I should use for testing
code snippets before using them on my original data or can they be
considered safe after being run once?
Save often; backup/commit often; be ready to hit 'undo'...? Do the
first test run on mock data in a test.org file?
One thing that might be useful to add to the code please ... If when
prompting for the property key, TAB brought up the list of
auto-complete keys (like when using C-c C-x p) that would make for
easier maintenance and consistency; e.g. when I deliberately want to
overwrite a previous outline index it would avoid a second set of
properties being written accidentally if I made a typo.
Then we need a way to keep track of what property keys are used to
store outlines in, so we can offer those and only those for
completion. (We don't want to offer all the property keys used in the
buffer -- that's an invitation to overwrite data.)
So in my second pass (below), when you use a :foo: property to store
the outline index, `foo' gets added to a list of keys in the
:Stored_outlines: property of the parent. When you store an outline,
the prompt for a property key offers completion on all the keys stored
in :Stored_outlines:. See how this works for you.
Yours,
Christian
#+BEGIN_SRC emacs-lisp
(defun cm/org-store-outline-order (arg prop)
Store the heading order of the subtree of the entry at point
by setting the property PROP of each direct child entry to its
current position in the tree. With prefix ARG, store the position
of the whole subtree.
You can store different heading orders in the same subtree by
using different keys as PROP; these will be listed in the
Stored_Outlines property of the parent entry. The tree can be
restored to a given stored outline by sorting on the appropriate
property with `C-c ^ r'.
Note that this will only work properly on the order of each
subtree; if headings are demoted, promoted, or moved into
different subtrees, the result may or may not be nonsense, but it
will be impossible to restore the original order by sorting.
(interactive P\ni)
(let* ((match (format LEVEL%s%s
(if arg = =)
(1+ (org-current-level
(counter 1)
(width (1+
(floor
(log10
(length (org-map-entries t match 'tree))
(fstr (concat %0 (number-to-string width) d))
(defaultprop OutlineIndex)
(keychain Stored_Outlines)
(keys (org-entry-get-multivalued-property
(point) keychain)))
(unless prop
(setq prop
(org-icompleting-read
(concat Property to use [ defaultprop ]: )
(mapcar 'list keys) nil nil nil nil defaultprop)))
(when (or (not (org-map-entries t (concat prop ={.}) 'tree))
(y-or-n-p Property exists; overwrite? ))
(org-entry-add-to-multivalued-property
(point) Stored_Outlines prop)
(org-map-entries
'(progn
(org-set-property prop
(format fstr counter))
(setq counter (1+ counter)))
match 'tree)
(message
#+END_SRC
Gez
On 10/12/11 1:35 PM, Gez wrote:
Thanks, Christian. Please forgive my ignorance but what should I do
with the code? I've not done anything more advanced than
org-customize before.
Gez
Re: [O] [agenda] Case-insensitive tag search
On 10/11/11 8:22 AM, Carsten Dominik wrote: (...) To be on the safe side, my suggestion would be to apply a function to your files which would downcase all the tags present in the buffer. Marcelo, maybe this is a nice task to try your elisp on? With perl, it would be a one-liner I have one... but I won't spoil Marcelo's fun if he wants to write his own; it was indeed a nice task! :) Christian
Re: [O] Idea: insert current sort order property
Hi, Gez,
On 10/7/11 5:02 PM, Gez wrote:
What I'm imagining is a command executed on a headline to insert a
property into each of its children fixing the current order;
something like :sorted:01, :sorted:02 etc.
I think this is a neat idea, and can see some uses for it for my own
stuff. I've made a first pass below. Please test it and let me know
how it works for you (and please *don't* test it on anything valuable
without backing up first!).
Ideally there would
be a prompt for the property key (or part of it) so that there could
be more than one such property for a particular headline, but with the
option to simplify the usage and consistency by having just one
property key as a default and no prompt.
More or less done. There'll be a prompt anyway, but just hit RET to
select the default (OutlineIndex).
If a sorted headline got moved to a new parent its sort-order might be
a duplicate one of its siblings, but I don't really see that as a
problem - the user knows it's only text after all.
The below will just do sequential numbering, as you suggested (01, 02,
03...) Then, as long as you've only changed the order of siblings at
each level, the order can be restored by sorting on the outline-index
property (C-c ^ r) for each parent.
Irretrievable chaos may and probably will result if headlines are
demoted, promoted, or moved to new parents. As long as the user's fine
with that, everything's fine.
An obvious refinement would be to do true outline numbering (e.g. 01,
01-01, 01-01-01, 01-01-02, 01-02-01, 01-02-02 ...). Then you could
restore the original outline entirely no matter how headings have been
moved around. But you couldn't do that by sorting; making that useful
would take additional code, so I haven't implemented it (yet).
I don't know
whether it might be desired to similarly fix the sort-order of 1st
level headlines; perhaps the command could act per current file, with
a to narrow down to the current tree.
The below will not number the entry at point, because that could break
a numbering already set at that level. It will number its direct
children. With prefix, it will number all its descendants. See how it
works for you. I made it the default behavior to number only the
direct children of the entry at point, since littering the whole tree
with property drawers is not necessarily what you want to do.
I'm also not sure how to deal
with larger numbers - 01-99 seems like a good default but could one
have an option for 001-999? I also wonder about adding the property
to more than one level at a time, but might that be a bit much in
terms of affecting performance?
Solved; the below counts the total number of headings first, then
adjusts the zero padding accordingly. Code follows.
Yours,
Christian
#+begin_src emacs-lisp
(defun cm/org-store-outline-order (arg prop)
Store the outline of the subtree of the entry at point by
setting the property PROP of each direct child entry to its
current position in the tree. With prefix ARG, store the position
of the whole subtree. The tree can be restored to the stored
outline by sorting on the property with `C-c ^ r'. Note that this
will only work properly on the order of each subtree; if headings
are demoted, promoted, or moved into different subtrees, the
result may or may not be nonsense, but it will be impossible to
restore the original order by sorting.
(interactive P\nsProperty key (default OutlineIndex): )
(if (string= prop ) (setq prop OutlineIndex))
(if (or (not (org-map-entries t (concat prop ={.}) 'tree))
(y-or-n-p Property exists; overwrite? ))
(let* ((match (format LEVEL%s%s
(if arg = =)
(1+ (org-current-level
(counter 1)
(width (1+ (floor (log10 (length (org-map-entries t
match 'tree))
(fstr (concat %0 (number-to-string width) d)))
(org-map-entries
'(progn
(org-set-property prop
(format fstr counter))
(setq counter (1+ counter)))
match 'tree)
(message
#+end_src
Re: [O] [OT] org - InDesign integration possible?
No, I don't use it myself, but I expect using the ODT exporter, opening in OpenOffice or similar, and saving to .doc or .rtf for import into InDesign is your best bet. (As to whether .doc or .rtf, experiment. In my limited experience designers prefer RTF, for good reason, but OpenOffice RTF export has been quirky for me in the past.) Cheers, Christian On 10/9/11 11:06 PM, Marcelo de Moraes Serpa wrote: Hi list, I've seen a designer friend layout a book in InDesign so quickly and the output is amazing. I wonder if there's a way to feed text into InDesign documents through a plugin ? If so, a book could be written in text (org) and then fed into inDesign? Anyone around use / ever used InDesign for layout? Cheers, - M
Re: [O] [babel] create tikz pictures in an floating LaTeX environment
Hi, Torsten,
Incidentally, I had to remove \end{scope} (there is no corresponding
\begin{scope}) to make your code example work. Could that be causing
some of your trouble?
Yours,
Christian
On 10/8/11 4:45 PM, Torsten Wagner wrote:
Hi Eric
``:results output silent'' should suppress that I think.
Nick's solution should work well. Also, (if you're exporting to LaTeX)
couldn't you just combine the tikz picture and the wrapping figure
environment into a single begin_latex block?
Yep Nick solution is working fine. I just wonder what is the order of
execution during export. E.g. if I generate the link to a file as
output and place it directly under the lines to add a picture in
org-mode, I thought the code block would be execute first and the
result would replace the function call. The exporter will find a link
to a picture and export it as usual. This was the reason I thought the
following code should work.
#+CAPTION:my great picture
#+LABEL: fig:my_picture
#+ATTR_LaTeX:
#+srcname: mypicture
#+begin_src latex :file fig/mypicture.pdf :packages '(( tikz))
:border 1em :fit
\begin{tikzpicture}[line width=1pt,text centered, inner sep = 2]
\draw[fill=red!50] (0,0) rectangle ++(5,1);
\draw[fill=yellow!50] (1,1) rectangle ++(1,0.25);
\draw[fill=yellow!50] (3,1) rectangle ++(1,0.25);
\draw[fill=green!50] (0.75,1) rectangle ++(1.5,-0.4);
\draw[fill=green!50] (2.75,1) rectangle ++(1.5,-0.4);
\end{scope}
\end{tikzpicture}
#+end_src
or alternatively
#+CAPTION:my great picture
#+LABEL: fig:my_picture
#+ATTR_LaTeX:
#+call: mypicture()
As for putting all figure environment and tikz into one latex-code block.
First of all I thought that :file fig/mypicture.pdf will generate and
process an individual LaTeX file. Thus, I could not use any commands
for the main manuscript right? Sure I could skip the :file command
however, I would prefer to generate each picture as an individual pdf
file. This gives me much more flexibility. I can easily convert them
into any other format and share them individually with co-workers.
Furthermore, many journals are very strict (and minimal) with there
supported LaTeX environment. The tikz package is often not installed
on there machines and the upload process would fail. In addition some
journals require to upload each figure individually. Thus, I am used
already to generate individual pdf-files for each figure and include
them into the manuscript by a simple \includegraphic line.
Thanks for the help
Torsten
CC. I notice something else regarding to babel. Please see my next post
Re: [O] Merge Properties into Template
PS. Note that with the code example I sent, your templates can also access the special properties listed in section 7.2 of the manual, such as TODO, ALLTAGS, TIMESTAMP, DEADLINE etc.
Re: [O] The org paper manual - tools used
Nick Dokos nicholas.do...@hp.com writes: Marcelo de Moraes Serpa celose...@gmail.com wrote: How was the process, from org file to tex to paper? I think it'd be nice if whoever did it (Carsten?) documented that on Worg. Org is amazing as a publishing platform (for books and ebooks), but I feel the information is still scattered around. Unfortunately, the org documentation is not an org file: org.texi is the primary file and it has always been a texinfo file. makeinfo is used to turn it into an info file, and texi2pdf is used to turn it into a PDF file (and thence to paper): see the org Makefile. Well, back in the olden days the documentation was simple plain text inside of org.el which I eventually converted into a texinfo file. Texinfo has some very nice features which at the time org-mode did not even dream of having (it did not have an agenda and probably no exporters). -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
[O] [PATCH] Special blocks: Make well-formed HTML
* org-special-blocks.el (org-special-blocks-convert-html-special-cookies): Close paragraph before opening or closing the div, and open paragraph after. Also changed newline placement to be the same as for other blocks. The problem was that special blocks did not produce well-formed HTML because they wrapped the opening and closing div tags in p tags. TINYCHANGE This patch only borrows a few lines from the handling of `CENTER' blocks in org-export-as-html. --- lisp/org-special-blocks.el | 22 +- 1 files changed, 13 insertions(+), 9 deletions(-) diff --git a/lisp/org-special-blocks.el b/lisp/org-special-blocks.el index 2da57f0..f4e6258 100644 --- a/lisp/org-special-blocks.el +++ b/lisp/org-special-blocks.el @@ -78,15 +78,19 @@ seen. This is run after a few special cases are taken care of. (defvar line) (defun org-special-blocks-convert-html-special-cookies () - Converts the special cookies into div blocks. - ;; Uses the dynamically-bound variable `line'. - (when (string-match ^ORG-\\(.*\\)-\\(START\\|END\\)$ line) -;(org-close-par-maybe) -(message %s (match-string 1)) -(if (equal (match-string 2 line) START) - (insert div class=\ (match-string 1 line) \\n) - (insert /div\n)) -(throw 'nextline nil))) +Converts the special cookies into div blocks. +;; Uses the dynamically-bound variable `line'. +(when (string-match ^ORG-\\(.*\\)-\\(START\\|END\\)$ line) + (message %s (match-string 1)) + (when (equal (match-string 2 line) START) +(org-close-par-maybe) +(insert \ndiv class=\ (match-string 1 line) \) +(org-open-par)) + (when (equal (match-string 2 line) END) +(org-close-par-maybe) +(insert \n/div) +(org-open-par)) + (throw 'nextline nil))) (add-hook 'org-export-html-after-blockquotes-hook 'org-special-blocks-convert-html-special-cookies) -- 1.7.4.1
Re: [O] Org-special-blogs does not make well-formed xhtml
Hi, Carsten,
I've submitted a patch separately. It seems to play nice with the
enclosed test file.
If org-special-blocks is supposed to become part of the core (it's
moved out of contrib, but we still have to require it), it might make
sense to just move the html and latex formatting code into org-html.el
and org-latex.el respectively, together with the handling of
blockquotes, verses, centering etc.
Yours,
Christian
On 10/4/11 11:33 PM, Carsten Dominik wrote:
Hi Christian,
for now I have reverted the patch. WOuld you like to work on a better one?
- Carsten
On 4.10.2011, at 21:01, Christian Moe wrote:
Hi,
Carsten, thanks.
Jambunathan's probably right, though, that this fix (while necessary) is
incomplete. Sorry, I hadn't thought it through.
Now, when the first paragraph of a special block comes right after the #+BEGIN_WHATEVER line, it
will just come as the first text node of thediv block, and will not be wrapped in
ap element. So among other things, any special CSS styling forps will not be
applied to it.
It's not a big deal -- if you need ap (and often you really don't) the
workaround is as simple as leaving an empty line between #+BEGIN_WHATEVER and the
first paragraph.
But I guess it would be more consistent/expected/helpful behavior for special-blocks
to start a new paragraph -- this time *after* the openingdiv tag and not
around it!
Yours,
Christian
On 10/4/11 4:36 PM, Jambunathan K wrote:
Carsten Dominikcarsten.domi...@gmail.com writes:
I see no reason to not uncomment this line. Shall we just do this?
Shouldn't a paragraph be opened/closed while entering/leaving the div.
, See org-xhtml-format-environment
| (center
| (case beg-end
|(BEGIN
| (org-lparse-end-paragraph)
| (insert \ndiv style=\text-align: center\)
| (org-lparse-begin-paragraph))
|(END
| (org-lparse-end-paragraph)
| (insert \n/div)
| (org-lparse-begin-paragraph
`
We can always open a paragraph gratis, because empty paragraphs are
pruned at the end of export.
#+style: style.abstract:before { content: Abstract: ; font-weight: bold;
display: inline}
#+style: .abstract {font-size: 10pt; margin-left: 3em}
#+style: .sidebar {border: 1px solid black; padding: 1em; background: yellow;
counter-increment: box}
#+style: .sidebar:before {content: Box counter(box); font-weight: bold;
display: block}
#+style: p {font-family: arial}/style
Special blocks test
#+begin_src emacs-lisp
(require 'org-special-blocks)
#+end_src
#+results:
: org-special-blocks
#+begin_abstract
This is a special =abstract= block.
#+end_abstract
Some text.
#+begin_sidebar
This is a sidebar with additional detail. Check that the first
paragraph is styled the same as the others.
It extends over several paragraphs.
#+end_sidebar
Some more text.
#+begin_sidebar
This is another example with lines above/below.
#+end_sidebar
Text again.
#+begin_center
This is centered text. Like special blocks, it's wrapped in a =div=
element in HTML.
#+end_center
New code:
#+begin_src emacs-lisp
(defun org-special-blocks-convert-html-special-cookies ()
Converts the special cookies into div blocks.
;; Uses the dynamically-bound variable `line'.
(when (string-match ^ORG-\\(.*\\)-\\(START\\|END\\)$ line)
(message %s (match-string 1))
(when (equal (match-string 2 line) START)
(org-close-par-maybe)
(insert \ndiv class=\ (match-string 1 line) \)
(org-open-par))
(when (equal (match-string 2 line) END)
(org-close-par-maybe)
(insert \n/div)
(org-open-par))
(throw 'nextline nil)))
#+end_src
Re: [O] Merge Properties into Template
Hi, Org doesn't already have a particular way to do this, I think, so a little elisp is called for. It's fairly easy with the Org Properties API. Here's a modest example that will work with your sample document: #+begin_src emacs-lisp (defun cm/org-merge (target) Fill a template headlined TARGET with the properties of the entry at point, replacing e.g. `[AGE]' with the contents of an :AGE: property. Use `[HEADLINE]' for the text of the entry heading. (interactive sTarget template: ) (let ((props (org-entry-properties)) prop template) (setq props (cons (cons HEADLINE (org-get-heading)) props)) (save-excursion (org-open-link-from-string (format [[*%s]] target)) (setq template (org-get-entry))) (dolist (p props) (setq template (replace-regexp-in-string (format \\[%s\\] (car p)) (cdr p) template t))) (message template))) #+end_src Evaluate this code. Then place point in the Fido entry, do `M-x cm/org-merge', and type `Dog Template' at the prompt. To improve on that, how do you want to use it? Once Fido's data are merged with the template, what do you want to do with the results? Mail them to someone? Export them to HTML? Make a new Org entry with the contents and file it somewhere? Yours, Christian On 10/6/11 11:35 AM, Richard Parsons wrote: Hi all I'm new to emacs and I'm new to org-mode, apologies if I should have found this myself, but I have searched and come up blank. I have a node with properties and I would like to merge that data into a template. For example: * Dogs ** Fido :PROPERTIES: :BREED:West Highland Terrier :COLOR:White :AGE: 2 :END: * Templates ** Dog Template Your dog, called [HEADLINE], is a [COLOR] [BREED], who is [AGE] years old. I want to merge the item called Fido into the template called Dog Template. Could someone point me to the right bit of the manual so I can learn how to do this? Or should I be looking to use a different elisp module to achieve this, something that plays nicely with org-mode? Many thanks Richard
Re: [O] Merge Properties into Template
Hi, On 10/6/11 5:56 PM, Richard Parsons wrote: (...) Firstly, thank you so much for taking the time to write some code, which (even as a newbie) I was able to get running quickly and easily. My pleasure. I'm finding my legs in elisp myself, and I often find a better solution to a problem I've been grappling with when I think about someone else's request. So it was in this case -- I had worked on an insanely complicated mail-merge setup, your post made me realize it could be done more simply. Of practical benefit to me would be either: (a) make a new Org entry and file it (as you suggest) or (b) simply put it in the kill ring, so that I can yank it wherever I want. I enclose a new version (below) that does (b), add to the kill ring. We could also do (a), make an entry and refile it, but if this is what you want to do, I'd be more interested in looking into ways to do it with org-capture and avoid reinventing the wheel -- even if setting up org-capture templates is a little more involved than what you had in mind. Again, thanks so much for your help, and also the other replies I received. I'm very impressed by the org-mode community responding so quickly to my question. Pass it forward! Yours, Christian #+begin_src emacs-lisp (defun cm/org-merge (target) Fill a template headlined TARGET with the properties of the entry at point, replacing e.g. `[AGE]' with the contents of an :AGE: property. Use `[HEADLINE]' for the text of the entry heading. (interactive sTarget template: ) (let ((props (org-entry-properties)) prop template) (setq props (cons (cons HEADLINE (org-get-heading)) props)) (save-excursion (org-open-link-from-string (format [[*%s]] target) t) (setq template (org-get-entry))) (dolist (p props) (setq template (replace-regexp-in-string (format \\[%s\\] (car p)) (cdr p) template t))) (kill-new template) (message template))) #+end_src
Re: [O] Hyperlink to Lotus Notes documents
Hi, Looks like someone's solved your problem -- you could try this: https://bitbucket.org/pdixon/emacs/src/tip/org-lotus-notes.el ...replacing /usr/local/bin/notes with whatever is the path to the Notes client on your system. hth, Christian On 10/5/11 9:32 AM, bart wrote: Hi all, Is there a way how to create external link to Lotus Notes document? Links work fine in MS Office, in internet browser, but I haven't found any way, how to make it work in Org mode in Emacs... The sample links are as follows: Notes://BBMCZH1/C125771B00548CB1/CCBFC5B4442395E0C12570C4004563E1/049B02105C555056C12578EA003ACADA notes://BBMCZH1@BBMCZ@BBRAUN/__C125789A0054D94A.nsf/0/3A8D40C8D67679F5C12578BC004B064A?OpenDocument These are sample links to documents in Lotus Notes. These links work in MS Word (and browser as well), but I just cannot use it in Emacs. I know, that there is some way, how to program new hyperlink type, but I'm just a basic user... Thanks for help Rgds, David
Re: [O] Org-special-blogs does not make well-formed xhtml
I see no reason to not uncomment this line. Shall we just do this? - Carsten Yes, would you, please? Yours, Christian
[O] Org-special-blogs does not make well-formed xhtml
Hi, XHTML produced with Org-special-blocks is not well-formed; div tags get wrapped in p tags. Example: Some text. #+begin_sidebar Some details left out of the main text. Some more details. #+end_sidebar Some more text. This results in the following html, which causes XML processors to fail. p div class=sidebar Some details left out of the main text. /p p Some more details. /div /p p Some more text. /p/div The problem seems to be fixed by un-commenting the fifth line in the below function in org-special-blocks.el: (defun org-special-blocks-convert-html-special-cookies () Converts the special cookies into div blocks. ;; Uses the dynamically-bound variable `line'. (when (string-match ^ORG-\\(.*\\)-\\(START\\|END\\)$ line) ;(org-close-par-maybe) (message %s (match-string 1)) (if (equal (match-string 2 line) START) (insert div class=\ (match-string 1 line) \\n) (insert /div\n)) (throw 'nextline nil))) Does anyone know if that was commented out for a reason? Yours, Christian
Re: [O] Time estimates time format?
Johan Ekh ekh.jo...@gmail.com writes: But I'd like to make estimates in days, weeks or even months. You can certainly do that. Have a look at org-effort-durations. You could for example define the effort as '2d', '4w' or '7m'. And have spent time displayed in percentage of the estimate. Is this possible? You might be able to do something along this line. Have a look at the doc string of org-properties-postprocess-alist where it gives you an example on how to calculate the remaining time (clocked vs estimated). HTH -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] unexpected failure on all formulas
Hi, Nick, I think your vmode() needs to subtract one from the result. The mode in the systolic column of Jude's dataset should be 124 (f=12), not 125 (f=2). For Jude's limited purposes I got by with less code (but note the caveats): #+begin_src emacs-lisp (defmath vmode (vec) Returns the mode (most frequent value) of a unimodal vector of integers VEC. WARNING: Will not work with non-integer values or multiple vectors. Will only return the lowest mode for multimodal data. (let ((freq (histogram vec (1+ (vmax vec) (1- (find freq (vmax freq) #+end_src Using :=vmode(@I..@II), I get 124 (systolic), 80 (diastolic), 68 (pulse). Yours, Christian On 9/20/11 10:26 AM, Nick Dokos wrote: Nick Dokosnicholas.do...@hp.com wrote: Jude DaShielljdash...@shellworld.net wrote: |+--+---+---| | mode | | | | | Min| | | | | Max| 127. | 81. | 74. | #+TBLFM: @$2..@$4=vmode(@i..@ii) :: @$2..@$4=vmin(@i..@ii) :: @$2..@$4=vmax(@i..@ii) # Local Variables: # kept-new-versions: 100 # version-control: t # End: cut here. What did I do wrong with this #+TBLFM: line? Two things: o as Christian Moe pointed out, calc does not provide a vmode() function. o the separator lines in the formulas have to be specified using capital I letters. Here is an implementation of vmode - afaict, it works correctly but that may be because I've only tested it on a single set of data. If you find something wrong, please let me know. --8---cut here---start-8--- | Date Stamp | Systolic | Diastolic | Pulse | |+--+---+---| | [2011-07-19 Tue 02:26] | 138 |92 |74 | | [2011-07-20 Wed 04:03] | 130 |85 |74 | | [2011-07-21 Thu 03:50] | 128 |79 |76 | | [2011-07-22 Fri 02:33] | 121 |80 |79 | | [2011-07-23 Sat 02:52] | 118 |75 |68 | | [2011-07-24 Sun 04:13] | 126 |83 |78 | | [2011-07-25 Mon 02:12] | 122 |79 |76 | | [2011-07-26 Tue 01:57] | 124 |79 |72 | | [2011-07-27 Wed 04:03] | 137 |74 |76 | | [2011-07-28 Thu 03:47] | 136 |80 |76 | | [2011-07-29 Fri 04:06] | 120 |72 |76 | | [2011-07-30 Sat 03:18] | 128 |92 |80 | | [2011-07-31 Sun 07:11] | 124 |84 |72 | | [2011-08-01 Mon 04:55] | 124 |77 |69 | | [2011-08-02 Tue 02:47] | 128 |80 |67 | | [2011-08-03 Wed 06:00] | 132 |89 |70 | | [2011-08-04 Thu 04:30] | 137 |82 |77 | | [2011-08-05 Fri 06:10] | 124 |86 |77 | | [2011-08-06 Sat 04:04] | 139 |88 |78 | | [2011-08-07 Sun 04:02] | 124 |80 |68 | | [2011-08-08 Mon 06:36] | 137 |93 |79 | | [2011-08-10 Wed04:03] | 120 |80 |68 | | [2011-08-11 Thu 04:30] | 128 |78 |77 | | [2011-08-12 Fri 06:36] | 143 |82 |76 | | [2011-08-13 Sat 06:18] | 125 |76 |69 | | [2011-08-14 Sun 04:04] | 123 |70 |69 | | [2011-08-15 Mon 04:04] | 135 |83 |76 | | [2011-08-16 Tue 04:03] | 128 |80 |69 | | [2011-08-17 Wed 04:04] | 124 |80 |68 | | [2011-08-18 Thu 05:58] | 136 |87 |72 | | [2011-08-19 Fri 05:50] | 116 |80 |64 | | [2011-08-20 Sat 06:38] | 139 |84 |64 | | [2011-08-21 Sun 08:20] | 124 |84 |73 | | [2011-08-22 Mon 03:50] | 138 |76 |70 | | [2011-08-23 Tue 05:52] | 126 |79 |68 | | [2011-08-24 Wed 04:53] | 125 |81 |64 | | [2011-08-25 Thu 05:37] | 124 |79 |68 | | [2011-08-26 Fri 06:41] | 124 |87 |74 | | [2011-08-27 Sat 05:44] | 133 |74 |61 | | [2011-08-28 Sun 03:22] | 124 |76 |61 | | [2011-08-29 Mon 04:06] | 124 |76 |65 | | [2011-08-30 Tue 05:52] | 139 |87 |71 | | [2011-08-31 Wed 06:47] | 152 |86 |68 | | [2011-09-01 Thu 06:00] | 136 |86 |78 | | [2011-09-02 Fri 01:22] | 142 | 100 |78 | | [2011-09-03 Sat 09:12] | 126 |79 |70 | | [2011-09-04 Sun 11:53] | 130 |90 |72 | | [2011-09-05 Mon 06:29] | 138 |77 |65 | | [2011-09-06 Tue 05:42] | 121 |76 |68 | | [2011-09-07 Wed 06:47] | 131 |77 |68 | | [2011-09-08 Thu 06:02] | 122 |76 |72 | | [2011-09-10 Sat 05:38] | 126 |76 |69 | | [2011-09-11 Sun 10:12] | 137 |87 |64 | | [2011-09-12 Mon 04:00] | 135 |78 |89 | | [2011-09-13 Tue 06:00] | 132 |82
Re: [O] Time estimates time format?
Johan Ekh ekh.jo...@gmail.com writes:
Thank you,
I've changed to
#+PROPERTY: Effort_ALL 2d 1w 2w 3w 4w 2m
#+COLUMNS: %40ITEM(Task) %17Effort(Estimated Effort){:} %CLOCKSUM
but there is no mapping between days, weeks, months and hours. For example,
'2d' + '1w' is summed as '3:00'. How can I change this?
Ah, according to http://orgmode.org/org.html#Column-attributes the {:}
sums the times and treats the times as HH:MM, plain numbers are hours.
I guess this is a bug? You can define efforts in terms of weeks, etc.
Some parts of org-mode respect it but column view apparently not. Sorry.
Patches or even just proper bug reports are welcome.
Thanks
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
-
Viel Neues fuer Hoerspiel-Fans: Eine aktuelle Uebersicht des Angebots bei der
SBS finden Sie unter http://www.sbs.ch/hoerspiele .
Re: [O] unexpected failure on all formulas
Hi, Nick, No whacks intended! It was an easy catch because I was mulling over similar problems with my code. My own second pass at a vmode implementation for Calc is below, now with support for negative values and bimodal data. It takes a different route and is a bit shorter, but doesn't handle all the cases your code does (I guess; I don't grok it all). Yours, Christian (defmath vmode (vec) Return the mode(s), i.e. most frequent value(s), of a vector of integers VEC. (let ((results (vec)) ; hold results (index 1) offset maxfreq) (setq offset (- 1 (vmin vec)) vec (+ offset vec) ; bump all ints positive freq (histogram vec (1+ (vmax vec))) offset (1+ offset) ; histogram added `0' slot maxfreq (vmax freq)) ;; Collect indexes (less offset) of all max freqs (while ( (setq index (find freq maxfreq index)) 0) (setq results (vconcat results index) index (1+ index))) (setq results (- results offset)) ; get neg ints back ;; Return results as vector or number (if ( (vlen results) 1) results (head results On 9/20/11 4:59 PM, Nick Dokos wrote: Christian Moem...@christianmoe.com wrote: I think your vmode() needs to subtract one from the result. The mode in the systolic column of Jude's dataset should be 124 (f=12), not 125 (f=2). Yes, this is an off-by-one error: in vfreqs, I should cons prev onto freqs, not (nth 0 vec). In addition to this and the multimodal problem that both you and Lawrence Mitchell pointed out, there is another off-by-one error when vfreqs gets to the end of the list. All in all, a disaster: can a posting be deleted? or at least marked with a big, red X so that it won't mislead in the future? I'll try to post a corrected version later on. OTOH, my main interest in this was the hooking up of a user function onto calc and the example, though deeply flawed, does illustrate that. Thanks to both Christian and Lawrence for the whacks in the head (although now I have a headache...) Nick
Re: [O] vmin and probably vmax functions don't work
Hi, I think you'll need to include an actual example that isn't working. With my own tables I don't see any errors with vmean, vmin, vmax. As for vmode, does Calc have such a function? I can't see it documented, and putting one in my table doesn't work. Yours, Christian On 9/19/11 4:52 AM, Jude DaShiell wrote: I'm getting identical numbers with vmean and vmode. I don't know if that information is correct but will check it with another system later this week. The same figures though also come up for vmin function and I know for a fact that isn't correct. That was after saving my org file and starting up emacs again to see if those figures would change and those figures did not change. The only functions from calc that may work are vmean and perhaps vsum but I've not tried vsum yet so won't make any more categorical statements about that yet. I modified the #+TBLFM: line with the original vmean formulas on it changing them first to vmode and later to vmin. And that's how I got these results. What I would have liked to have done would have been to calculate a mode and a min and max for each of the three figures I'm tracking then had that information show up at the bottom of the table. Something like: | stats: | systalic | diastalic | pulse | | mode | xxx | yyy | zzz | | min | xxx | yyy | zzz | | max | xxx | yyy | zzz | |- Though how to get a #+TBLFM: line to calculate for all of this and position correctly I'll have to figure out later. Judejdash...@shellworld.net I love the Pope, I love seeing him in his Pope-Mobile, his three feet of bullet proof plexi-glass. That's faith in action folks! You know he's got God on his side. ~ Bill Hicks
Re: [O] vmin and probably vmax functions don't work
Hi, You've got row formulas when you want single-cell formulas. Assuming it's minima you're after, try #+TBLFM: @$2=vmin(@I..@II);f0::@$3=vmin(@I..II);f0::@$4=vmin(@I..II);f0 hth Christian On 9/19/11 12:15 PM, Jude DaShiell wrote: | Date Stamp | Systalic | Diastalic | Pulse | |+--+---+---| | [2011-07-19 Tue 02:26] | 138 |92 |74 | | [2011-07-20 Wed 04:03] | 130 |85 |74 | | [2011-07-21 Thu 03:50] | 128 |79 |76 | | [2011-07-22 Fri 02:33] | 121 |80 |79 | | [2011-07-23 Sat 02:52] | 118 |75 |68 | | [2011-07-24 Sun 04:13] | 126 |83 |78 | | [2011-07-25 Mon 02:12] | 122 |79 |76 | | [2011-07-26 Tue 01:57] | 124 |79 |72 | | [2011-07-27 Wed 04:03] | 137 |74 |76 | | [2011-07-28 Thu 03:47] | 136 |80 |76 | | [2011-07-29 Fri 04:06] | 120 |72 |76 | | [2011-07-30 Sat 03:18] | 128 |92 |80 | | [2011-07-31 Sun 07:11] | 124 |84 |72 | | [2011-08-01 Mon 04:55] | 124 |77 |69 | | [2011-08-02 Tue 02:47] | 128 |80 |67 | | [2011-08-03 Wed 06:00] | 132 |89 |70 | | [2011-08-04 Thu 04:30] | 137 |82 |77 | | [2011-08-05 Fri 06:10] | 124 |86 |77 | | [2011-08-06 Sat 04:04] | 139 |88 |78 | | [2011-08-07 Sun 04:02] | 124 |80 |68 | | [2011-08-08 Mon 06:36] | 137 |93 |79 | | [2011-08-10 Wed04:03] | 120 |80 |68 | | [2011-08-11 Thu 04:30] | 128 |78 |77 | | [2011-08-12 Fri 06:36] | 143 |82 |76 | | [2011-08-13 Sat 06:18] | 125 |76 |69 | | [2011-08-14 Sun 04:04] | 123 |70 |69 | | [2011-08-15 Mon 04:04] | 135 |83 |76 | | [2011-08-16 Tue 04:03] | 128 |80 |69 | | [2011-08-17 Wed 04:04] | 124 |80 |68 | | [2011-08-18 Thu 05:58] | 136 |87 |72 | | [2011-08-19 Fri 05:50] | 116 |80 |64 | | [2011-08-20 Sat 06:38] | 139 |84 |64 | | [2011-08-21 Sun 08:20] | 124 |84 |73 | | [2011-08-22 Mon 03:50] | 138 |76 |70 | | [2011-08-23 Tue 05:52] | 126 |79 |68 | | [2011-08-24 Wed 04:53] | 125 |81 |64 | | [2011-08-25 Thu 05:37] | 124 |79 |68 | | [2011-08-26 Fri 06:41] | 124 |87 |74 | | [2011-08-27 Sat 05:44] | 133 |74 |61 | | [2011-08-28 Sun 03:22] | 124 |76 |61 | | [2011-08-29 Mon 04:06] | 124 |76 |65 | | [2011-08-30 Tue 05:52] | 139 |87 |71 | | [2011-08-31 Wed 06:47] | 152 |86 |68 | | [2011-09-01 Thu 06:00] | 136 |86 |78 | | [2011-09-02 Fri 01:22] | 142 | 100 |78 | | [2011-09-03 Sat 09:12] | 126 |79 |70 | | [2011-09-04 Sun 11:53] | 130 |90 |72 | | [2011-09-05 Mon 06:29] | 138 |77 |65 | | [2011-09-06 Tue 05:42] | 121 |76 |68 | | [2011-09-07 Wed 06:47] | 131 |77 |68 | | [2011-09-08 Thu 06:02] | 122 |76 |72 | | [2011-09-10 Sat 05:38] | 126 |76 |69 | | [2011-09-11 Sun 10:12] | 137 |87 |64 | | [2011-09-12 Mon 04:00] | 135 |78 |89 | | [2011-09-13 Tue 06:00] | 132 |82 |66 | | [2011-09-14 Wed 06:01] | 137 |77 |77 | | [2011-09-15 Thu 04:08] | 141 |87 |64 | | [2011-09-17 Sat 08:35] | 121 |78 |66 | | [2011-09-18 Sun 07:04] | 124 |69 |65 | || | | | |+--+---+---| | modes | 127. | 81. | 74. | #+TBLFM: $2=vmin(@I..II);f0::$3=vmin(@I..II);f0::$4=vmin(@I..II);f0
