Re: [O] [beamer] Can I just export one frame?
On Mon, Nov 21, 2011 at 06:40, zwz zhangwe...@gmail.com wrote: SO I just want to know if there is some convenient way to export just one frame without tagging all the other frames as :noexport. Subtree export? -- Suvayu Open source is the future. It sets us free.
Re: [O] [babel] :var assignment no longer tolerant of whitespace
Eric Schulte schulte.e...@gmail.com writes: Hi Eric Hi Martyn, Tom mentioned this regression earlier and I treated it as a new restriction on variable specifications, but if multiple people are running into this issue I suppose spaces around equals should be supported. I have just pushed up a change and a test case ensuring that examples like yours below will work. Many thanks Best, Martyn Cheers -- Eric
[O] odt export to google-docs problem continues
On Fri, Nov 18, 2011 at 11:21 AM, Jambunathan K kjambunat...@gmail.comwrote: Suvayu/Rustom suvayu ali fatkasuvayu+li...@gmail.com writes: Hi Jambunathan, On Thu, Nov 17, 2011 at 11:06, Jambunathan K kjambunat...@gmail.com wrote: Can anyone else reproduce this? I can replicate this. The odt file exported by org-odt is not accepted by google docs even though libreoffice opens it without problems. However it I open it with libreoffice and say edit and save, google docs then accepts the new file. With my some experimentation, I am able to reproduce it now. I have this in my .emacs. , | (setq org-export-odt-prettify-xml t) Well now google docs accepts but libreoffice itself says file is corrupt shall I repair? If I take the odt file directly made by exporter direcly in googledocs there are lots of spurious spaces eg between bullets and the first word. If I push it through libreoffice and resave then googledocs does a better job of displaying
[O] TABLES: split cells on columns
The feature of remove/add cell is quite important. Should be a feature request. Another important feature request is to split cells. Example (copying and paste the example above) Example: I have the following table: |1 |1 | |2 | two words| |3 |4 | |4 | | Now I want to split cell @2$2 and thus move the second part to the following cell below in column 2 down one step. After: |1 |1 | |2 | two| | | words| |3 |4 | |4 | | I do it several times when I put much comments on an entry and the column becomes much wider. It is several commands (sometimes with rectangles, sometimes not depending on the remaining of the table) . Is there an easy way to do this? Daniel Is there a s 2011/10/1 suvayu ali fatkasuvayu+li...@gmail.com 2011/9/30 Michael Brand michael.ch.br...@gmail.com: Ehm - it is doable, but not by editing commands from Org table. Only with several rectangular edits or an Org table formula with a few tricks and a temporary column to be removed afterward. There are some org-table specific rectangle edit commands that should make it easier. Cut the cells with org-table-cut-region, and paste by org-table-paste-rectangle. Hope this helps. -- Suvayu Open source is the future. It sets us free.
Re: [O] [PATCH] Implement priority inheritance for agenda views.
Hi All, On 26.05.2011 14:21, Michael Hohmuth wrote: * lisp/org.el (org-use-prio-inheritance): New customizable for using priority inheritance in agenda views. Defaults to off (org-get-priority-char): Factored out from org-get-priority. Return priority token from headline, defaulting to an optional fallback or org-default-priority. (org-get-priority): Use org-get-priority-char. Default to an optional fallback or org-default-priority. (org-scan-tags): Assign and display priority according to org-use-prio-inheritance. --- This patch can be pulled from branch prio-inherit at git://github.com/altruizine/org-mode.git . I am aware that priority inheritance for to-do items has been requested and rejected in the past, on the grounds of inherited priorities allegedly inflating the number of assigned priorities, thereby defeating the purpose of priorities. Well, I disagree, as I have found inherited priorities useful in practice. I would be interested in this functionality. What is needed to merge this? Thanks, Martin
Re: [O] TABLES: split cells on columns
Hi Daniel Yes, there is: 1) M-down to add the new line 2) mark the region from t down to any char from the field below 3) M-Ret The opposite direction is: - C-u M-Ret to join the content of a field to the one above See also C-h f org-table-wrap-region for more tricks. Michael On Mon, Nov 21, 2011 at 14:31, Daniel Martins daniel...@gmail.com wrote: The feature of remove/add cell is quite important. Should be a feature request. Another important feature request is to split cells. Example (copying and paste the example above) Example: I have the following table: | 1 | 1 | | 2 | two words| | 3 | 4 | | 4 | | Now I want to split cell @2$2 and thus move the second part to the following cell below in column 2 down one step. After: | 1 | 1 | | 2 | two| | | words| | 3 | 4 | | 4 | | I do it several times when I put much comments on an entry and the column becomes much wider. It is several commands (sometimes with rectangles, sometimes not depending on the remaining of the table) . Is there an easy way to do this?
Re: [O] [beamer] Can I just export one frame?
zwz zhangweize at gmail.com writes: It takes long to export the whole file when it contains many babel stuff. And in many cases, I just want to check if the current frame is arranged as expected. SO I just want to know if there is some convenient way to export just one frame without tagging all the other frames as :noexport. Have you tried just tagging the tree you want with :export:? Once that select tag is present in the buffer Org will automatically exclude any trees that don't have it. From the docs: Org first checks if any of the select tags is present in the buffer. If yes, all trees that do not carry one of these tags will be excluded. If a selected tree is a subtree, the heading hierarchy above it will also be selected for export, but not the text below those headings. http://orgmode.org/manual/Selective-export.html#index-export_002c-selective-by-tags-or-TODO-keyword-1424
[O] beamer right aligned table
Hi, I have the following table. | |r | | 1. | gaaccgacct | | 2. | aaccgacct | | 3. | accgacct | | 4. |ccgacct | | 5. | cgacct | | 6. | gacct | | 7. | acct | | 8. |cct | | 9. | ct | | 10. | t | Even though table column are right aligned, in my pdf result they are still left aligned. What am I supposed to do? Thanks. -- HD
Re: [O] beamer right aligned table
On Mon, Nov 21, 2011 at 17:24, Haluk Dogan hlk.do...@gmail.com wrote: Even though table column are right aligned, in my pdf result they are still left aligned. What am I supposed to do? #+ATTR_LATEX: align=lr to left align the first column and right align the second column. HTH -- Suvayu Open source is the future. It sets us free.
[O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Dear Org-Babel developers, When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the code blocks of at least some languages are executed during the export process. (Has this always been like that, I noticed this for the first time?) I would like to switch that off completely. I prefer evaluating code blocks individually to check their results. Also, many of by code blocks run substantial programs which slow down the export process considerably. I could not find an option to switch this off in the documentation. Apologies if I missed something obvious. I assume it is there somewhere, but I could not find it. Thank you! Best wishes, Torsten -- Dr Torsten Anders Course Leader, Music Technology University of Bedfordshire Park Square, Room A315 torsten.and...@beds.ac.uk http://strasheela.sourceforge.net http://www.torsten-anders.de
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Torsten, Torsten Anders wrote: Dear Org-Babel developers, When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the code blocks of at least some languages are executed during the export process. (Has this always been like that, I noticed this for the first time?) I would like to switch that off completely. I prefer evaluating code blocks individually to check their results. Also, many of by code blocks run substantial programs which slow down the export process considerably. I could not find an option to switch this off in the documentation. Apologies if I missed something obvious. I assume it is there somewhere, but I could not find it. #+PROPERTY: eval never does inhibit evaluation of the code blocks. Best regards, Seb -- Sebastien Vauban
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Torsten, Torsten Anders wrote: Dear Org-Babel developers, When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the code blocks of at least some languages are executed during the export process. (Has this always been like that, I noticed this for the first time?) I would like to switch that off completely. I prefer evaluating code blocks individually to check their results. Also, many of by code blocks run substantial programs which slow down the export process considerably. I could not find an option to switch this off in the documentation. Apologies if I missed something obvious. I assume it is there somewhere, but I could not find it. #+PROPERTY: eval never does inhibit evaluation of the code blocks. You could also look into using the :cache header argument to only re-run code blocks when their inputs have changed, or sometimes I find it easy to simply disassociate the results of a code block from the code block itself (e.g., through a rename), and then change the export property of the code block to either code or none. Best -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] beamer email address isn't showed up
Hi, how can I display my email address in the first page of my presentation? Thanks. p.s. #+EMAIL property has been already set. -- HD
Re: [O] [org-babel] [PATCH] Improve ditta.jar finding heuristics
Org-mode has *many* customization variables, and for most problems a variable will exist to solve the problem, I understand where you're coming from. True, it is not possible to handle all obscure and arcane cases, that's what all these variables are for, but I don't think that a situation where user installs ditaa and later emacs, both via the package management system and find themselves unable to draw awesome ditaa diagrams without looking a variable up in documentation, adding appropriate code to his configuration file and hitting C-x C-e is some sort of a fringe use-case. If only myself and maybe another person has ever hit that roadblock, than I agree, it is not worth adding any additional code, and I rest my case. I would agree the above situation is not desirable. It is hard to tell how many people have run into this issue, as it is probably more trouble to post to this list than it is to find the appropriate variable and set it to an appropriate value. I don't know how the Emacs apt-get package is maintained, but it seems to me that the variable should be set by the apt-get package maintainers. I assume the Emacs packages already have to set a number of customization variables perhaps the best approach would be to find out how to add org-ditaa-jar-path to their list. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] beamer email address isn't showed up
Haluk Dogan hlk.do...@gmail.com wrote: Hi, how can I display my email address in the first page of my presentation? Thanks. p.s. #+EMAIL property has been already set. Have you read the manual? Hint: sec. 12.2, Export Options. Alternatively, press C-x C-e after the closing paren: (info (org) Export Options) Make sure you read the whole page. Nick
[O] HTML export and Zotero-friendly headers
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/ -- Erik L. Arneson dyb...@lnouv.com GPG Key ID : 1024D/62DA1D25 BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP Office : +1.541.291.9776Skype : callto://pymander http://www.leisurenouveau.com/ http://www.transformason.org/
Re: [O] [BUG] Inconsistency in src block hiding
Nicolas Goaziou n.goaz...@gmail.com writes: Eric Schulte schulte.e...@gmail.com writes: name is and should be an element of the `org-babel-data-names' list as it is the preferred way to name data in an Org-mode file, e.g., #+name: foo - 1 - 2 - 3 I agree. The only reason that tblname and results are included in the list are because tblname is used by other parts of Org-mode, and results was retained because it was felt that a name line without an actual name (e.g., as the results of an un-named code block) would look funny. I don't view the results style hiding as inconsistent It is inconsistent when keywords stack on top of each other. If you have only a #+name: keyword, block with fold at the #+name: level. If you have both #+name: and, for example #+results below, block will fold at the #+result: level and TAB will not respond at #+name:. Can you provide an example, I'm thinking that what you describe may not be legal syntax. For example #+name: one #+results: two - 1 - 2 doesn't make any more sense than #+name: one #+name: two - 1 - 2 If you have, from top to bottom, name, results header, nothing will fold. In all those cases, I think a consistent behaviour could be to hide the block, with any number of keywords above, and TAB pressed at any of them. Yes, I would agree, the hiding should be smart enough to find the whole unit and hide it. I'll take a look at the code. I'm not sure that #+results: or #+name: keywords should allow to hide whole parts of the buffer. I realize that toggling #+results: visibility has been in core for a while. But now that every Org blob can have a #+name attached to it, one can hide almost anything in the buffer. Until now we could hide contents with headlines, blocks, drawers, and items (with an option to prevent it). And we had a global mechanism to handle visibility toggling just fine (namely S-TAB with different numbers of prefixes). But hiding independently each list, table or paragraph with no possibility to make them appear in groups just doesn't sound right. Hence, I suggest to think again about it: we can live happily with outlines, blocks and drawers as folding entities. The hiding was added because code blocks occasionally generate *huge* results which make it impossible to read further down in the buffer. Hiding such large results can be very useful when you want to keep the data in-buffer, but still want to be able to read down the page. Is there a way to bring the hiding of results more in-line with the other methods of hiding in Org-mode? Should S-Tab be made to toggle the hidden states of named entities as well as outline levels? Moreover, there is another problem related to that. `org-export-blocks-preprocess' will remove all #+name: keywords in the buffer. It mustn't: again #+name: is a general naming mechanism for almost any Org syntax. It may/will be also used for other purpose than Babel. That information is important even after blocks have been processed. I'll take a look at this and submit a patch. Best -- Eric Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [ANN] Org Elements in contrib
Hello, I've added org-element.el in contrib directory. It is a complete parser and interpreter for Org syntax. While it was written to be extensible, it is also an attempt to normalize current syntax and provide guidance for its evolution. Org syntax can be divided into three categories: Greater elements, Elements and Objects. An object can be defined anywhere on a line. It may span over more than a line but never contains a blank one. Objects belong to the following types: `emphasis', `entity', `export-snippet', `footnote-reference', `inline-babel-call', `inline-src-block', `latex-fragment', `line-break', `link', `macro', `radio-target', `statistics-cookie', `subscript', `superscript', `target', `time-stamp' and `verbatim'. An element always starts and ends at the beginning of a line. The only element's type containing objects is called a `paragraph'. Other types are: `comment', `comment-block', `example-block', `export-block', `fixed-width', `horizontal-rule', `keyword', `latex-environment', `babel-call', `property-drawer', `quote-section', `src-block', `table' and `verse-block'. Elements containing paragraphs are called greater elements. Concerned types are: `center-block', `drawer', `dynamic-block', `footnote-definition', `headline', `inlinetask', `item', `plain-list', `quote-block' and `special-block'. Greater elements (excepted `headline' and `item' types) and elements (excepted `keyword', `babel-call', and `property-drawer' types) can have a fixed set of keywords as attributes. Those are called affiliated keywords, to distinguish them from others keywords, which are full-fledged elements. In particular, the name affiliated keyword allows to label almost any element in an Org buffer. Notwithstanding affiliated keywords, each greater element, element and object has a fixed set of properties attached to it. Among them, three are shared by all types: `:begin' and `:end', which refer to the beginning and ending buffer positions of the considered element or object, and `:post-blank', which holds the number of blank lines, or white spaces, at its end. Some elements also have special properties whose value can hold objects themselves (i.e. an item tag, an headline name, a table cell). Such values are called secondary strings. Lisp-wise, an element or an object can be represented as a list. It follows the pattern (TYPE PROPERTIES CONTENTS), where: TYPE is a symbol describing the Org element or object. PROPERTIES is the property list attached to it. See docstring of appropriate parsing function to get an exhaustive list. CONTENTS is a list of elements, objects or raw strings contained in the current element or object, when applicable. An Org buffer is a nested list of such elements and objects, whose type is `org-data' and properties is nil. The first part of this file implements a parser and an interpreter for each type of Org syntax. The next two parts introduce two accessors and a function retrieving the smallest element containing point (respectively `org-element-get-property', `org-element-get-contents' and `org-element-at-point'). The following part creates a fully recursive buffer parser. It also provides a tool to map a function to elements or objects matching some criteria in the parse tree. Functions of interest are `org-element-parse-buffer', `org-element-map' and, to a lesser extent, `org-element-parse-secondary-string'. The penultimate part is the cradle of an interpreter for the obtained parse tree: `org-element-interpret-data' (and its relative, `org-element-interpret-secondary'). The library ends by furnishing a set of interactive tools for element's navigation and manipulation. More specifically, that last part includes some tools like `org-element-forward', `org-element-backward', `org-element-drag-forward', `org-element-drag-backward', `org-element-mark-element', `org-element-up', `org-element-unindent-buffer'... For the impatient (well, not quite as you're still reading this), you can evaluate the following examples in an Org buffer : (org-element-parse-buffer) (org-element-parse-buffer 'headline) (org-element-parse-buffer 'headline 'visible-only) Also, the following code will parse the buffer, interpret the parsed tree, and create a canonical copy of it (no indentation, lowercased blocks, standard keywords): #+begin_src org (let ((out (org-element-interpret-data (org-element-parse-buffer (switch-to-buffer (get-buffer-create *Bijectivep*)) (erase-buffer) (insert out) (goto-char (point-min)) (org-mode)) #+end_src Beside allowing to add keywords like #+name:, #+caption: or #+attr_latex: to almost any Org element, it also introduces two less noticable changes: 1. #+label: keywords are deprecated in favor of #+name:. Though, for now, label is still considered as a synonym of name. 2. Protected HTML snippets (like @b) are no longer supported, as they were too specific. Instead, a
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] HTML export and Zotero-friendly headers
On Mon, 21 Nov 2011, Christian Moe wrote: Hi, Does Erik Hetzner's zotero-plain work for you? 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 COinS span 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. -- Erik L. Arneson dyb...@lnouv.com GPG Key ID : 1024D/62DA1D25 BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP Office : +1.541.291.9776Skype : callto://pymander http://www.leisurenouveau.com/ http://www.transformason.org/
[O] [PATCH] Timestamps: Fix org-schedule and org-deadline with absolute time arguments
* lisp/org.el (org-add-planning-info): Treat absolute time too. TINYCHANGE --- lisp/org.el |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index fffb0c1..3342b87 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12078,9 +12078,8 @@ be removed. default-input (and ts (org-get-compact-tod ts)) (when what (setq time - (if (and (stringp time) - (string-match ^[-+]+[0-9] time)) - ;; This is a relative time, set the proper date + (if (stringp time) + ;; This is a string (relative or absolute), set proper date (apply 'encode-time (org-read-date-analyze time default-time (decode-time default-time))) @@ -14807,7 +14806,7 @@ The prompt will suggest to enter an ISO date, but you can also enter anything which will at least partially be understood by `parse-time-string'. Unrecognized parts of the date will default to the current day, month, year, hour and minute. If this command is called to replace a timestamp at point, -of to enter the second timestamp of a range, the default time is taken +or to enter the second timestamp of a range, the default time is taken from the existing stamp. Furthermore, the command prefers the future, so if you are giving a date where the year is not given, and the day-month combination is already past in the current year, it will assume you -- 1.7.3.4
Re: [O] [OT]: Search for missing :END:
Markus Heller helle...@gmail.com wrote:
Hello all,
I have an OT request that can hopefully be answered by emacs gurus in
less than a minute:
I'm looking for an emacs search expression that finds :PROPERTIES:
*without* a matching :END: ...
If you mean a regexp, you are wasting your time[fn:1]. Regexps are
powerful, but their range of applicability is limited to regular
languages and even then, you have to worry about their efficiency. The
above *is* a regular language: if P stands for :PROPERTIES: and E stands
for :END:, then the regexp is
([^EP]*P[^EP]*E)*
In words, the stuff inside the parens says: 0 or more other things
(non-P and non-E), followed by a P, followed by 0 or more other
things, followed by an E. You can then have 0 or more of the
parenthesized things. This will succeed on well formed sentences and
fail on others. But it might have to backtrack over the inner [^EP]*
matches and then the outer matches, and rescan arbitrarily long
stretches, which in the worst case, can turn your search into an
exponentially slow descent into the abyss. You might be able to write
non-greedy regexps that might behave better in this case. In most cases,
you'd end up with a horrendous-looking regexp: good luck trying to
understand it next week. That's my biggest problem with complicated regexps.
However, a change of tool will simplify the problem enormously. E.g. here's
a simple algorithm that can be used for this kind of problem: start a
nesting depth at 0 - when you see a P, increment the nesting depth by 1;
when you see an E, decrement it by 1. If the nesting depth ever becomes
something other than 0 or 1, you got a problem - also, if at EOF, the
nesting depth is not 0, you got a problem. Easy variations of this will
check well-formedness even when nesting *is* allowed.
You can easily write such a program in any language you are familiar
with (it does not have to be elisp, although you *can* write it in
elisp - personally, I'd use awk).
But assuming that you are getting some error from org, you don't know
where the problem is and you are trying to find it, it will be simpler
to just use egrep:
grep -E -n ':PROPERTIES:|:END:' foo.org
will filter out the relevant lines, so all you have to do is scan the
output by eye and spot any irregularity (consecutive :PROPERTIES: or
consecutive :END: lines). Even if you have hundreds of them, that's
*easy* for humans to do.[fn:2]
Or, if you prefer, you can write trivial validation programs to operate
on the output, e.g.:
grep -E -n ':PROPERTIES:|:END:' foo.org | tee foo.out | grep PROP | wc
-l
grep END foo.out | wc -l
(the counts 'd better be the same).
or
grep -E -n ':PROPERTIES:|:END:' foo.org | foo.awk
where foo.awk implements the nesting depth algorithm above - something
like this:
--8---cut here---start-8---
#! /bin/bash
awk '
BEGIN { d = 0;}
/:PROPERTIES:/ { d++; if (d 1) { print $1, $d; exit; }}
/:END:/{ d--; if (d 0) { print $1, $d; exit; }}
END{ if (d != 0) { print $1, $d; }}'
--8---cut here---end---8---
Even on Windoze, you can probably do all this stuff with cygwin.
Nick
Thanks and Cheers and sorry for the OT ...
Markus
Footnotes:
[fn:1] In the (approximate) words of Jamie Zawinski: You have a
problem. You think 'I know, let me use regexps to solve it'. Now
you have two problems.
[fn:2] Of course, if you have formatted your file perversely or done
other naughty things, this might not work. The point is that although
this is not foolproof, it should deal with the vast majority of
reasonable files out there.
Re: [O] [ANN] Org Elements in contrib
Nicolas Goaziou n.goaz...@gmail.com writes: Hi Nicolas Hello, I've added org-element.el in contrib directory. It is a complete parser and interpreter for Org syntax. While it was written to be extensible, it is also an attempt to normalize current syntax and provide guidance for its evolution. Org syntax can be divided into three categories: Greater elements, Elements and Objects. An object can be defined anywhere on a line. It may span over more than a line but never contains a blank one. Objects belong to the following types: `emphasis', `entity', `export-snippet', `footnote-reference', `inline-babel-call', `inline-src-block', `latex-fragment', `line-break', `link', `macro', `radio-target', `statistics-cookie', `subscript', `superscript', `target', `time-stamp' and `verbatim'. An element always starts and ends at the beginning of a line. The only element's type containing objects is called a `paragraph'. Other types are: `comment', `comment-block', `example-block', `export-block', `fixed-width', `horizontal-rule', `keyword', `latex-environment', `babel-call', `property-drawer', `quote-section', `src-block', `table' and `verse-block'. Elements containing paragraphs are called greater elements. Concerned types are: `center-block', `drawer', `dynamic-block', `footnote-definition', `headline', `inlinetask', `item', `plain-list', `quote-block' and `special-block'. Greater elements (excepted `headline' and `item' types) and elements (excepted `keyword', `babel-call', and `property-drawer' types) can have a fixed set of keywords as attributes. Those are called affiliated keywords, to distinguish them from others keywords, which are full-fledged elements. In particular, the name affiliated keyword allows to label almost any element in an Org buffer. Notwithstanding affiliated keywords, each greater element, element and object has a fixed set of properties attached to it. Among them, three are shared by all types: `:begin' and `:end', which refer to the beginning and ending buffer positions of the considered element or object, and `:post-blank', which holds the number of blank lines, or white spaces, at its end. Some elements also have special properties whose value can hold objects themselves (i.e. an item tag, an headline name, a table cell). Such values are called secondary strings. Lisp-wise, an element or an object can be represented as a list. It follows the pattern (TYPE PROPERTIES CONTENTS), where: TYPE is a symbol describing the Org element or object. PROPERTIES is the property list attached to it. See docstring of appropriate parsing function to get an exhaustive list. CONTENTS is a list of elements, objects or raw strings contained in the current element or object, when applicable. An Org buffer is a nested list of such elements and objects, whose type is `org-data' and properties is nil. The first part of this file implements a parser and an interpreter for each type of Org syntax. The next two parts introduce two accessors and a function retrieving the smallest element containing point (respectively `org-element-get-property', `org-element-get-contents' and `org-element-at-point'). The following part creates a fully recursive buffer parser. It also provides a tool to map a function to elements or objects matching some criteria in the parse tree. Functions of interest are `org-element-parse-buffer', `org-element-map' and, to a lesser extent, `org-element-parse-secondary-string'. The penultimate part is the cradle of an interpreter for the obtained parse tree: `org-element-interpret-data' (and its relative, `org-element-interpret-secondary'). The library ends by furnishing a set of interactive tools for element's navigation and manipulation. More specifically, that last part includes some tools like `org-element-forward', `org-element-backward', `org-element-drag-forward', `org-element-drag-backward', `org-element-mark-element', `org-element-up', `org-element-unindent-buffer'... For the impatient (well, not quite as you're still reading this), you can evaluate the following examples in an Org buffer : (org-element-parse-buffer) (org-element-parse-buffer 'headline) (org-element-parse-buffer 'headline 'visible-only) Also, the following code will parse the buffer, interpret the parsed tree, and create a canonical copy of it (no indentation, lowercased blocks, standard keywords): #+begin_src org (let ((out (org-element-interpret-data (org-element-parse-buffer (switch-to-buffer (get-buffer-create *Bijectivep*)) (erase-buffer) (insert out) (goto-char (point-min)) (org-mode)) #+end_src Beside allowing to add keywords like #+name:, #+caption: or #+attr_latex: to almost any Org element, it also introduces two less noticable changes: 1. #+label: keywords are deprecated in favor of #+name:. Though, for now, label is still
[O] [PATCH] Avoid lisp error with (org-deadline nil +1d)
* lisp/org.el (parse-time-weekdays): Must not be void. TINYCHANGE --- lisp/org.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 253703b..41d418a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15229,7 +15229,7 @@ user. (setq org-read-date-analyze-futurep futurep) (list second minute hour day month year))) -(defvar parse-time-weekdays) +(defvar parse-time-weekdays nil) (defun org-read-date-get-relative (s today default) Check string S for special relative date string. -- 1.7.3.4
Re: [O] Bugs in lisp/ob-lilypond.el
Martyn Jago martyn.j...@btinternet.com writes: Hi Torsten Hi Torston Torsten Anders torsten.and...@beds.ac.uk writes: Also, the setting results: silent seems to be ignored. Best wishes, Torsten On 19 Nov 2011, at 15:22, Torsten Anders wrote: Dear Martyn Jago, dear all, I just pulled the latest version of Org mode and noticed a few bugs in the Lilypond support of Org babel that have not been there in the previous version (so far I was still using version 7.6). In general, there seems to be problems in parsing the line that starts #+begin_src lilypond. More specifically, - Global :noweb settings are now ignored - Any settings after the setting :file will be added to output file name! - Settings after :noweb yes cause trouble (disable this setting) Thanks for the heads-up Torsten - there have been many changes to the bare-metal Org as you probably are aware. Your observations will come in very useful to sort out the transition to the new improved order (which I am totally in favor of by the way), and the details you provide will prove very useful. Certainly consider checking out a `less hot' release to get working again ( i.e. git checkout release_7.7 ). In the mean-time I will work on compatibility (tomorrow hopefully) - and better regression tests. Great to hear you're making use of ob-lilypond by the way! Best, Martyn Again, thanks for lisp/ob-lilypond.el in the first place. (Apologies for miss-spelling your name previously). I'm not seeing this. I've updated my examples to embrace the standard source block syntax, and everything seems to be working for me - which probably means I haven't considered your use-case. I've also moved my ob-lilypond documentation to Worg (but appear to have broken the Worg build mechanism, so that is little help here), but it would be useful to know if the examples at http://github.com/mjago/ob-lilypond/examples work for you. Some more detail would be useful - could you provide: - a broken sample - Emacs version - Lilypond version? Also are you using arrange-mode (C-h v ly-arrange-mode . Nil is no). Regarding the `standard source block syntax', ensure that any #+srcname or #+source commands are replaced with #+name, and update to the very latest Org if you leave space in a `:var something = something-else' assignment as I tend to do. Best, Martyn Best wishes, Torsten -- Dr Torsten Anders Course Leader, Music Technology University of Bedfordshire Park Square, Room A315 torsten.and...@beds.ac.uk http://strasheela.sourceforge.net http://www.torsten-anders.de
[O] Subscription to the mailing list
Hi, Is the subscription to the mailing list working at the moment? Because I tried today to subscribe and I didn't get the confirmation mail. I tried a couple of hours ago and still nothing. Thanks, S.
[O] Add publishing with utf8
I use standard org-mode methods to publish my projects to html. However by default they are published with tag meta http-equiv=Content-Type content=text/html;charset=iso-8859-1/, however i need charset to be changed to utf8, as i am using Russian in my blog too. Please make it possible somehow. Best wishes.
Re: [O] [OT]: Search for missing :END:
Nick Dokos nicholas.do...@hp.com writes:
Markus Heller helle...@gmail.com wrote:
Hello all,
I have an OT request that can hopefully be answered by emacs gurus in
less than a minute:
I'm looking for an emacs search expression that finds :PROPERTIES:
*without* a matching :END: ...
If you mean a regexp, you are wasting your time[fn:1]. Regexps are
powerful, but their range of applicability is limited to regular
languages and even then, you have to worry about their efficiency. The
above *is* a regular language: if P stands for :PROPERTIES: and E stands
for :END:, then the regexp is
([^EP]*P[^EP]*E)*
In words, the stuff inside the parens says: 0 or more other things
(non-P and non-E), followed by a P, followed by 0 or more other
things, followed by an E. You can then have 0 or more of the
parenthesized things. This will succeed on well formed sentences and
fail on others. But it might have to backtrack over the inner [^EP]*
matches and then the outer matches, and rescan arbitrarily long
stretches, which in the worst case, can turn your search into an
exponentially slow descent into the abyss. You might be able to write
non-greedy regexps that might behave better in this case. In most cases,
you'd end up with a horrendous-looking regexp: good luck trying to
understand it next week. That's my biggest problem with complicated regexps.
However, a change of tool will simplify the problem enormously. E.g. here's
a simple algorithm that can be used for this kind of problem: start a
nesting depth at 0 - when you see a P, increment the nesting depth by 1;
when you see an E, decrement it by 1. If the nesting depth ever becomes
something other than 0 or 1, you got a problem - also, if at EOF, the
nesting depth is not 0, you got a problem. Easy variations of this will
check well-formedness even when nesting *is* allowed.
You can easily write such a program in any language you are familiar
with (it does not have to be elisp, although you *can* write it in
elisp - personally, I'd use awk).
But assuming that you are getting some error from org, you don't know
where the problem is and you are trying to find it, it will be simpler
to just use egrep:
grep -E -n ':PROPERTIES:|:END:' foo.org
will filter out the relevant lines, so all you have to do is scan the
output by eye and spot any irregularity (consecutive :PROPERTIES: or
consecutive :END: lines). Even if you have hundreds of them, that's
*easy* for humans to do.[fn:2]
Or, if you prefer, you can write trivial validation programs to operate
on the output, e.g.:
grep -E -n ':PROPERTIES:|:END:' foo.org | tee foo.out | grep PROP |
wc -l
grep END foo.out | wc -l
(the counts 'd better be the same).
or
grep -E -n ':PROPERTIES:|:END:' foo.org | foo.awk
where foo.awk implements the nesting depth algorithm above - something
like this:
#! /bin/bash
awk '
BEGIN { d = 0;}
/:PROPERTIES:/ { d++; if (d 1) { print $1, $d; exit; }}
/:END:/{ d--; if (d 0) { print $1, $d; exit; }}
END{ if (d != 0) { print $1, $d; }}'
Even on Windoze, you can probably do all this stuff with cygwin.
Hi Nick,
thanks for this informative reply.
Unfortunately, I cannot install cygwin on my work computer. I'll have
to figure something else out ...
AS for an example, I'm in one of my org files and I do C-TAB and get the
following error:
OVERVIEW
CONTENTS...done
SHOW ALL
if: :END: line missing at position 18720
Quit
Mark set
Where is position 18720? I apologize if this is a stupid question, but
I can't seem to figure this out ...
Thanks again
Markus
Re: [O] Subscription to the mailing list
Well, that message got through to the list :). Chris On Nov 21, 2011, at 8:45 AM, Stelian Iancu wrote: Hi, Is the subscription to the mailing list working at the moment? Because I tried today to subscribe and I didn't get the confirmation mail. I tried a couple of hours ago and still nothing. Thanks, S. - Chris Malone (mal...@ucolick.org) Dept. of Astronomy and Astrophysics UC Santa Cruz 1156 High Street Santa Cruz, CA 95064-1077 phone: 831-459-3809 -
Re: [O] [OT]: Search for missing :END:
My guess is that it's the 18720th byte of the file. To get there, go
to the start of your buffer and type M-x goto-char 18720
On Mon, Nov 21, 2011 at 11:27 PM, Markus Heller helle...@gmail.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
Markus Heller helle...@gmail.com wrote:
Hello all,
I have an OT request that can hopefully be answered by emacs gurus in
less than a minute:
I'm looking for an emacs search expression that finds :PROPERTIES:
*without* a matching :END: ...
If you mean a regexp, you are wasting your time[fn:1]. Regexps are
powerful, but their range of applicability is limited to regular
languages and even then, you have to worry about their efficiency. The
above *is* a regular language: if P stands for :PROPERTIES: and E stands
for :END:, then the regexp is
([^EP]*P[^EP]*E)*
In words, the stuff inside the parens says: 0 or more other things
(non-P and non-E), followed by a P, followed by 0 or more other
things, followed by an E. You can then have 0 or more of the
parenthesized things. This will succeed on well formed sentences and
fail on others. But it might have to backtrack over the inner [^EP]*
matches and then the outer matches, and rescan arbitrarily long
stretches, which in the worst case, can turn your search into an
exponentially slow descent into the abyss. You might be able to write
non-greedy regexps that might behave better in this case. In most cases,
you'd end up with a horrendous-looking regexp: good luck trying to
understand it next week. That's my biggest problem with complicated regexps.
However, a change of tool will simplify the problem enormously. E.g. here's
a simple algorithm that can be used for this kind of problem: start a
nesting depth at 0 - when you see a P, increment the nesting depth by 1;
when you see an E, decrement it by 1. If the nesting depth ever becomes
something other than 0 or 1, you got a problem - also, if at EOF, the
nesting depth is not 0, you got a problem. Easy variations of this will
check well-formedness even when nesting *is* allowed.
You can easily write such a program in any language you are familiar
with (it does not have to be elisp, although you *can* write it in
elisp - personally, I'd use awk).
But assuming that you are getting some error from org, you don't know
where the problem is and you are trying to find it, it will be simpler
to just use egrep:
grep -E -n ':PROPERTIES:|:END:' foo.org
will filter out the relevant lines, so all you have to do is scan the
output by eye and spot any irregularity (consecutive :PROPERTIES: or
consecutive :END: lines). Even if you have hundreds of them, that's
*easy* for humans to do.[fn:2]
Or, if you prefer, you can write trivial validation programs to operate
on the output, e.g.:
grep -E -n ':PROPERTIES:|:END:' foo.org | tee foo.out | grep PROP |
wc -l
grep END foo.out | wc -l
(the counts 'd better be the same).
or
grep -E -n ':PROPERTIES:|:END:' foo.org | foo.awk
where foo.awk implements the nesting depth algorithm above - something
like this:
#! /bin/bash
awk '
BEGIN { d = 0;}
/:PROPERTIES:/ { d++; if (d 1) { print $1, $d; exit; }}
/:END:/ { d--; if (d 0) { print $1, $d; exit; }}
END { if (d != 0) { print $1, $d; }}'
Even on Windoze, you can probably do all this stuff with cygwin.
Hi Nick,
thanks for this informative reply.
Unfortunately, I cannot install cygwin on my work computer. I'll have
to figure something else out ...
AS for an example, I'm in one of my org files and I do C-TAB and get the
following error:
OVERVIEW
CONTENTS...done
SHOW ALL
if: :END: line missing at position 18720
Quit
Mark set
Where is position 18720? I apologize if this is a stupid question, but
I can't seem to figure this out ...
Thanks again
Markus
Re: [O] [OT]: Search for missing :END:
Markus Heller helle...@gmail.com wrote: AS for an example, I'm in one of my org files and I do C-TAB and get the following error: OVERVIEW CONTENTS...done SHOW ALL if: :END: line missing at position 18720 Quit Mark set Where is position 18720? I apologize if this is a stupid question, but I can't seem to figure this out ... M-x goto-char RET 18720 RET will take you there, but it's probably at the very end of the buffer: search backwards for :PROPERTIES: and you should be able to find it (if your diagnosis is indeed correct). Nick
Re: [O] [OT]: Search for missing :END:
Markus Heller helle...@gmail.com wrote: Unfortunately, I cannot install cygwin on my work computer. I'll have to figure something else out ... Just copy the file to a Linux/Unix/OSX/... machine and do the searches there. USB sticks were invented for exactly that purpose :-) AS for an example, I'm in one of my org files and I do C-TAB and get the following error: OVERVIEW CONTENTS...done SHOW ALL if: :END: line missing at position 18720 Quit Mark set Where is position 18720? I apologize if this is a stupid question, but I can't seem to figure this out ... Thanks again Markus
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Dear Sebastien and Eric, Thanks a lot for your kind replies. However, this is not yet quite what I am after. I want to be able to manually execute each code block, but not automatically whenever the whole document is rendered. So, I would always switch on/off eval never. Hm... I will try out the :cache header argument. However, again this does not work so well, because for the languages I am using the :file argument does not work very well (I have to manually change extensions, so I include the resulting file links by hand anyway and set :results to silent. So, I it sounds like few org-babel users is really running larger applications in their code blocks which can delay the export of the whole document considerably. Anyway, thanks a lot for your feedback. Best wishes, Torsten
Re: [O] [OT]: Search for missing :END:
Nick Dokos nicholas.do...@hp.com writes: Markus Heller helle...@gmail.com wrote: AS for an example, I'm in one of my org files and I do C-TAB and get the following error: OVERVIEW CONTENTS...done SHOW ALL if: :END: line missing at position 18720 Quit Mark set Where is position 18720? I apologize if this is a stupid question, but I can't seem to figure this out ... M-x goto-char RET 18720 RET will take you there, but it's probably at the very end of the buffer: search backwards for :PROPERTIES: and you should be able to find it (if your diagnosis is indeed correct). Thanks to Nick and the other posters for an enlightening answer. This worked beautifully :) Thanks again and Cheers Markus, who knew that there was some easy way to solve this but couldn't figure it out himself
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Torsten, Torsten Anders torsten.and...@beds.ac.uk writes: Dear Sebastien and Eric, Thanks a lot for your kind replies. However, this is not yet quite what I am after. I want to be able to manually execute each code block, but not automatically whenever the whole document is rendered. So, I would always switch on/off eval never. Hm... I've just pushed up a patch which adds a new option to the eval header argument. Setting eval to non-export will now allow interactive evaluation, but will inhibit code block evaluation during export. This should address your need as I understand it. I will try out the :cache header argument. However, again this does not work so well, because for the languages I am using the :file argument does not work very well (I have to manually change extensions, so I include the resulting file links by hand anyway and set :results to silent. So, I it sounds like few org-babel users is really running larger applications in their code blocks which can delay the export of the whole document considerably. I would not jump to that conclusion. I have used babel code blocks to cache the results of very long running results, however between the :cache header argument and the ability to manually disassociate generated results from code blocks I have not had any problems inhibiting execution during export. Best -- Eric Anyway, thanks a lot for your feedback. Best wishes, Torsten -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] HTML export and Zotero-friendly headers
At Mon, 21 Nov 2011 13:14:02 -0800, Erik L. Arneson wrote: On Mon, 21 Nov 2011, Christian Moe wrote: Hi, Does Erik Hetzner's zotero-plain work for you? 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 COinS span 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. Hi Erik, There has been some discussion recently of export to ODT with citations. Jambunathan K has outlined a way of doing this using a binary added to zotero-plain, zotcite. This might be repurposed for an HTML export. best, Erik Sent from my free software system http://fsf.org/.
Re: [O] [beamer] Can I just export one frame?
Herbert Sitz hes...@gmail.com writes: zwz zhangweize at gmail.com writes: It takes long to export the whole file when it contains many babel stuff. And in many cases, I just want to check if the current frame is arranged as expected. SO I just want to know if there is some convenient way to export just one frame without tagging all the other frames as :noexport. Have you tried just tagging the tree you want with :export:? Once that select tag is present in the buffer Org will automatically exclude any trees that don't have it. From the docs: Org first checks if any of the select tags is present in the buffer. If yes, all trees that do not carry one of these tags will be excluded. If a selected tree is a subtree, the heading hierarchy above it will also be selected for export, but not the text below those headings. http://orgmode.org/manual/Selective-export.html#index-export_002c-selective-by-tags-or-TODO-keyword-1424 I did not know this! It is what I want. Thanks.
Re: [O] [ANN] Org Elements in contrib
On Tue, Nov 22 2011, Nicolas Goaziou wrote: Hello, I've added org-element.el in contrib directory. It is a complete parser and interpreter for Org syntax. This looks great! Is the eventual idea to use this library for other basic org functionality? It seems ideal for replacing the guts of things like `org-scan-tags' and family. -- GNU Emacs 24.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.24.6) of 2011-11-07 on pellet Org-mode version 7.7 (release_7.7.578.ge3ec9)
Re: [O] [test] Mark tests with missing dependencies as expected to fail
At Sun, 13 Nov 2011 12:31:20 -0700, Eric Schulte wrote: [1 text/plain (7bit)] David Maus dm...@ictsoc.de writes: Hi Eric, At Tue, 18 Oct 2011 10:22:34 -0600, Eric Schulte wrote: Hi David, I agree it would be preferable to note that not all tests are run when dependencies are missing, although I don't think it is extremely important. I think some version of the above would be worthwhile if it could be done in a file-wide manner (as are the current dependency checks) and wouldn't require duplicating the dependency check or changing every test form individually. Perhaps a file-local-variable could be used to expect failures for every form defined in the file? I tried the approach with a file-local variable but it didn't work out: A macro can be expanded at any time, i.e. looks like there is no way to obtain a reference to the buffer where the macro is defined at expansion time. But finally came up with this one: Nice macro, The only downside I see is the requirement to wrap every single deftest form which (to me) is too much overhead for too little payoff. How about the following which will register a failing test for each file of tests not loaded due to missing dependencies. The macro operates not just on a single `ert-deftest' form, but all deftests in BODY. It kind-of works like a file local variable. The current solution does its job, too -- so there's no need to use this macro. Getting feedback about tests not run because of missing dependencies is all I every wanted. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpkNkO2Z5yxV.pgp Description: PGP signature
Re: [O] Bug: Cloning tasks deletes clock time in the original [7.7 (release_7.7-571-gf558105)]
At Sat, 19 Nov 2011 21:37:08 -0500, Bernt Hansen wrote: Consider the following org file: --8---cut here---start-8--- * Orig Task 1 SCHEDULED: 2011-11-19 Sat +1w :LOGBOOK: - Note taken on [2011-11-19 Sat 21:24] \\ foo CLOCK: [2011-11-18 Fri 20:30]--[2011-11-18 Fri 21:24] = 0:54 CLOCK: [2011-11-19 Sat 20:23]--[2011-11-19 Sat 21:23] = 1:00 :END: [2011-11-19 Sat 21:23] --8---cut here---end---8--- This is a repeating task with some clock time on it. Now I need to change the 2nd occurrence from now so I clone the task to create 2 more followed by the repeater as follows: On the task do C-c C-x c 2 RET +1w RET Now I get this so I can edit one of the individual entries --8---cut here---start-8--- * Orig Task 1 SCHEDULED: 2011-11-19 Sat :LOGBOOK: - Note taken on [2011-11-19 Sat 21:24] \\ foo :END: [2011-11-19 Sat 21:23] * Orig Task 1 SCHEDULED: 2011-11-26 Sat :LOGBOOK: - Note taken on [2011-11-26 Sat 21:24] \\ foo :END: [2011-11-26 Sat 21:23] * Orig Task 1 SCHEDULED: 2011-12-03 Sat :LOGBOOK: - Note taken on [2011-12-03 Sat 21:24] \\ foo :END: [2011-12-03 Sat 21:23] * Orig Task 1 SCHEDULED: 2011-12-10 Sat +1w :LOGBOOK: - Note taken on [2011-12-10 Sat 21:24] \\ foo :END: [2011-12-10 Sat 21:23] --8---cut here---end---8--- I have the entries I want but my original clock lines have been deleted. I would expect this behaviour for the newly created clones only - not the original entry. I ran into this for a weekly meeting task I cloned and ended up recovering my clock lines from my hourly git repository but this shouldn't be necessary. I'm also not sure exactly why I get 3 entries when I ask for two -- maybe that's a special case of the repeater in the original task but it feels weird. I can confirm this bug for Org-mode version 7.7 (release_7.7.583.gedef1) GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian Looks like 516b2fbb8763788585ac6a9f60ad7d51c4b0aab3 is the culprit: `template' also contains the original entry. I'll see to provide a fix for this. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpMkJnxOhRnE.pgp Description: PGP signature
