Re: [O] [ANN] ASCII back-end for new export engine
Hello, Samuel Wales samolog...@gmail.com writes: In 22, latest git: downcase: Args out of range: image-keep-calm, 651500, 651505 match-string(1 image-keep-calm) (downcase (match-string 1 val)) (concat :macro- (downcase (match-string 1 val))) (intern (concat :macro- (downcase ...))) (plist-put nil (intern (concat :macro- ...)) (match-string 2 val)) [...] I've pushed a patch so macro detection is more careful about corner cases. Please tell me if it works for you. Also, judging by the backtrace, it seems that you are using a strange syntax for defining macros. Would you mind telling me what your #+macro: line is like, and what you do expect from it? Regards, -- Nicolas Goaziou
[O] [BUG][PATCH] document number of stars limitation with respect to org-clock-sum (was: Re: org-clock-sum cannot handle headings with more than 29 stars)
Hi Nick, org developers, * Nick Dokos nicholas.do...@hp.com [14. Jan. 2012]: Gregor Zattler telegr...@gmx.net wrote: while preparing a minimal example of my problem I finally realised that 61 was the deepest level of indentation of some inline tasks in my org file. When I wrote them I only remembered inline tasks as with more than x stars and so I provided more than enough :-) But this also applies to normal headings. My Minimal org file to demonstrate the bug is now: * dog ** dog *** dog dog * dog ** dog *** dog dog * dog ** dog *** dog dog * dog ** dog *** dog dog * dog ** dog *** dog dog * dog ** dog *** dog dog * dog ** dog *** dog dog * dog ** ant doing M-x org-clock-display (which in turn execs org-clock-sum) will fail. It will not fail, with the last line removed. I searched a bit in the sources (max.*level) but did not find documentation regarding the maximum number of stars in org files. Perhaps it has to be documented or lmax raised in the sources. Thanks for your help though, I first changed lmax as you proposed and it fixed the problem. * Nick Dokos nicholas.do...@hp.com [12. Jan. 2012]: Nick Dokos nicholas.do...@hp.com wrote: Gregor Zattler telegr...@gmx.net wrote: Debugger entered--Lisp error: (args-out-of-range [49569 49569 49569 39957 3= 9957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 61) aref([49569 49569 49569 39957 39957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0= 0 0 0 0 0 0] 61) This tries to get the 61st element of a vector that has at most 30 or so elements, hence the complaint. But of course, that's hardly enlightening. However, the backtrace shows that this code is inside the function org-clock-sum (in org-clock.el). And if you look at that function, you see (where I have elided large swathes of code): (let* (... (lmax 30) (ltimes (make-vector lmax 0)) ... So ltimes is a vector with *exactly* 30 elements. I would change that 30 to 100 or so (something greater than 61 in any case) and retest. If that fixes it, then we know the culprit and then we can dedice which is the unreasonable one: the code or your subtree :-) Or maybe that 61 is way off base. After all, there are only 5 non-trivial entries in the vector. The code that sets the level seems suspect to me: (let* ((headline-forced (get-text-property (point) :org-clock-force-headline-inclusion)) (headline-included (or (null headline-filter) (save-excursion (save-match-data (funcall headline-filter)) (setq level (- (match-end 1) (match-beginning 1))) What do match-beginning/match-end return if headline-filter is nil? The save-match-data is not done, so we get the results of whatever random search was done last before this code executed. So I guess that despite my suspicions this code works (although I need to understand how). As for the failure, your example is of course highly unlikely in the above form[fn:1], but much more likely in the inline task case that bit you originally. But since expanding the vector to 100 elements or so fixes the problem and seems to be both cheap and expedient, I'd vote for that fix to go in and be done with it (perhaps with a footnote in the clock section of the manual to identify the limit). Since I don't know if the hardcoded lmax value `30' serves other purposes too I don't change it but document the fact in org-inlinetask.el and the manual. Ciao, Gregor
[O] [PATCH 2/3] Document max number of stars in headings in manual
Clocking only works with headings indented with less than `30' stars
(hardcoded `lmax' value in `org-clock-sum').
---
doc/org.texi |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index b238210..9e873ea 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -1164,7 +1164,8 @@ Headlines define the structure of an outline tree. The
headlines in Org
start with one or more stars, on the left margin@footnote{See the variables
@code{org-special-ctrl-a/e}, @code{org-special-ctrl-k}, and
@code{org-ctrl-k-protect-subtree} to configure special behavior of @kbd{C-a},
-@kbd{C-e}, and @kbd{C-k} in headlines.}. For example:
+@kbd{C-e}, and @kbd{C-k} in headlines.} @footnote{Clocking only works with
+headings indented less then 30 stars.}. For example:
@example
* Top level headline
--
1.7.8.3
[O] [PATCH 1/3] Document max number of stars in headings in docstring of org-inlinetask-minlevel
Clocking only works with headings indented with less than `30' stars (hardcoded `lmax' value in `org-clock-sum'). Since especially inline tasks may dupe someone into using more stars, document the limit in the docsring of `org-inlinetask-min-level'. --- lisp/org-inlinetask.el |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el index a14e404..b8e8437 100644 --- a/lisp/org-inlinetask.el +++ b/lisp/org-inlinetask.el @@ -90,6 +90,9 @@ (defcustom org-inlinetask-min-level 15 Minimum level a headline must have before it is treated as an inline task. +Don't set it to something higher than `29' or clocking will break since this +is the hardcoded maximum number of stars `org-clock-sum' will work with. + It is strongly recommended that you set `org-cycle-max-level' not at all, or to a number smaller than this one. In fact, when `org-cycle-max-level' is not set, it will be assumed to be one less than the value of smaller than -- 1.7.8.3
[O] [PATCH 3/3] Document max number of stars in clocking section
Clocking only works with all headings indented with less than `30'
stars (hardcoded `lmax' value in `org-clock-sum').
---
doc/org.texi | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 9e873ea..46aa1e2 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5917,12 +5917,14 @@ created for this purpose, it is described in
@ref{Structure editing}.
@cindex time clocking
Org mode allows you to clock the time you spend on specific tasks in a
-project. When you start working on an item, you can start the clock.
-When you stop working on that task, or when you mark the task done, the
-clock is stopped and the corresponding time interval is recorded. It
-also computes the total time spent on each subtree of a project. And it
-remembers a history or tasks recently clocked, to that you can jump quickly
-between a number of tasks absorbing your time.
+project. When you start working on an item, you can start the clock. When
+you stop working on that task, or when you mark the task done, the clock is
+stopped and the corresponding time interval is recorded. It also computes
+the total time spent on each subtree@footnote{Clocking only works if all
+headings are indented with less than 30 stars. This is a hardcoded
+limitation of `lmax' in `org-clock-sum'.} of a project. And it remembers a
+history or tasks recently clocked, to that you can jump quickly between a
+number of tasks absorbing your time.
To save the clock history across Emacs sessions, use
@lisp
--
1.7.8.3
Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas Nicolas Goaziou n.goaz...@gmail.com writes: Hello, I've commited an ASCII back-end for new export engine. Assuming contrib directory is in your load-path, you just need to (require 'org-export) to have both LaTeX and ASCII exporters ready to boot. You can then access to the dispatcher with M-x org-export-dispatch and test various configurations from there. [...] I've been playing with (org-export-dispatch) with regard to some simple source blocks and have a couple of observations (apologies in advance if source blocks are not fully implemented yet). The test code is: --8---cut here---start-8--- * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 --8---cut here---end---8--- 1) The commented out `# :exports both' appears to be exported as uncommented and relevant (actually, this appears to be true of the original exporter too). 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), as shown above, then the exporter appears to export the in-buffer results /and/ the export-generated results (where :exports is results or both) resulting in two sets of identical results in the export. For the record, I much prefer your new Ascii layout, over that provided by the original exporter. HTH Best, Martyn
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Martyn Jago martyn.j...@btinternet.com writes: I've been playing with (org-export-dispatch) with regard to some simple source blocks and have a couple of observations (apologies in advance if source blocks are not fully implemented yet). The test code is: * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 1) The commented out `# :exports both' appears to be exported as uncommented and relevant (actually, this appears to be true of the original exporter too). I cannot reproduce it. Anyway, see my comments below. 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), as shown above, then the exporter appears to export the in-buffer results /and/ the export-generated results (where :exports is results or both) resulting in two sets of identical results in the export. It's out of exporter's scope. When you ask to export some buffer, what is really parsed is a copy of the current buffer with `org-export-blocks-preprocess' applied to it. So, simply apply that function in your test buffer, and you will see what is sent to the parser. That will explain why the results appear twice. In other words, tweaking the output of `org-export-blocks-preprocess' will automatically change the outcome of the export process. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
On 2012-01-22, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Also, judging by the backtrace, it seems that you are using a strange syntax for defining macros. Would you mind telling me what your #+macro: line is like, and what you do expect from it? I always export a subtree and not a file. That macro definition was elsewhere and there were no macro calls. As the old exporter didn't complain, I didn't know there was a malformed macro. Now getting an invalid search bound error, will report at some point. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
I've commited an ASCII back-end for new export engine.
Assuming contrib directory is in your load-path, you just need to
(require 'org-export) to have both LaTeX and ASCII exporters ready to
boot.
You can then access to the dispatcher with M-x org-export-dispatch and
test various configurations from there.
As a reminder, you can ask for a table of contents, list of tables and
list of listings with, respectively, #+toc: headlines, #+toc: tables
and #+toc: listings. Also, drawers[1] are exported transparently by
default.
Feedback is welcome.
Regards,
[1] properties drawers excepted: those are different elements anyway.
Aloha Nicolas,
I think there might be a problem with the regular expression for
captions on line 703 or org-e-latex.el. I have a dim understanding of
regular expressions and the various parsers, but I suspect the problem
is in this part: [^][].
At any rate, this input:
#+CAPTION: [An example photograph]{An example photograph}.
#+LABEL: fig:photo
yields this (unexpected) output:
\caption{\label{fig:photo}[An example photograph]\{An example photograph\}.}
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes:
I think there might be a problem with the regular expression for
captions on line 703 or org-e-latex.el. I have a dim understanding of
regular expressions and the various parsers, but I suspect the problem
is in this part: [^][].
At any rate, this input:
#+CAPTION: [An example photograph]{An example photograph}.
#+LABEL: fig:photo
The regexp isn't the problem here. But this all means that I'm breaking
a golden rule: never parse something already parsed.
Anyway, I have switched caption keyword to the dual keywords
category. That means is syntax is now like results keywords' which can
have an optional string (a hash in this case) before their main value.
To put it simply, caption syntax can now be:
#+caption: long name
#+caption[]: long name
#+caption[short name]: long name
much like
#+results[hash]: name
Though,
#+caption[something]:
is equivalent to no caption since the main value is mandatory.
As a side note, #+label has been deprecated in favor of #+name (though
the former is immediately translated into the latter at parse time).
Regards,
--
Nicolas Goaziou
Re: [O] Syntax error warnings? (Especially important with :noweb-ref's)
Hi Eric, Eric Schulte wrote: there are two related functions which should help. ,[org-babel-view-src-block-info] bound to C-c C-v I | org-babel-view-src-block-info is an interactive Lisp function in | `ob.el'. | | (org-babel-view-src-block-info) | | Display information on the current source block. | This includes header arguments, language and name, and is largely | a window into the `org-babel-get-src-block-info' function. ` and ,[org-babel-check-src-block] bound to C-c C-v c | org-babel-check-src-block is an interactive Lisp function in `ob.el'. | | (org-babel-check-src-block) | | Check for misspelled header arguments in the current code block. ` When checking for suspicious header arguments on[1]: #+name: mean #+begin_src emacs-lisp :var lst=() (let ((num (car lst)) (nums (cdr lst))) (/ (float (+ num (apply #'+ nums))) (1+ (length nums #+end_src it reports: supplied header var is suspiciously close to dir Can you enlighten me on what's suspicious here? Best regards, Seb Footnotes: [1] which is supposed to be used in the following table: | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 3.5 | #+TBLFM: @7$1='(sbe mean (lst @1..@6)) -- Sebastien Vauban
Re: [O] New issue with capture
For the benefit of future archive-reading generations, I isolated the issue to a bug in the emacs head revision at the time I built it. Re-fetching and building fixed it. On Mon, Jan 9, 2012 at 20:17, Ido Magal i...@idomagal.com wrote: This is GNU Emacs 24.0.92.1 (i386-apple-darwin11.2.0, NS apple-appkit-1138.23) I've reduced my .emacs to the following: = (setq org-capture-templates '((t Task entry (file+datetree ~/org/tasks.org) ** next %?))) = ~/org/tasks.org may not exist for this to repro. It repros either way. Repro steps: 1. M-x org-capture 2. enter anything 3. C-c C-c Result: byte-code: To bind the key M-DEL, use \M-\d, not [M-DEL] 4. C-c C-c again. Result: save-restriction: Wrong type argument: integer-or-marker-p, nil 5. Kill the 'CAPTURE-tasks.org' buffer. (C-x k) 6. repeat steps 1-3 Result: Success(!?) Thanks for investigating! On Mon, Jan 9, 2012 at 02:57, Bastien b...@altern.org wrote: Hi Ido, Ido Magal i...@idomagal.com writes: When I attempt to org-capture-finalize, I get Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil) org-capture-bookmark-last-stored-position() org-capture-finalize(nil) call-interactively(org-capture-finalize nil nil) I cannot (even try to) reproduce this. Please provide a complete and minimal example -- a test file and the relevant part of your configuration. Thanks, -- Bastien
[O] Side-by-side support (was:Re: [ODT] image scaling overridden by long caption)
On 2012-01-20 05:03, Jambunathan K wrote: side-by-side has surfaced in the list for the second time, I think it deserves to be supported out of the box. I strongly support this, since I have a lot of files with side-by-side content. The first question is of course how does the org source look like. In my case, I have simply separated the columns by a tab character and set the tab-width to a sensible value for nice on-screen display. These are 'text' and 'translation of that text' side-by-side, sometimes interrupted by section headers, notes and so on. Therefore I end up with multiple 'tables', which will need to have the same width throughout the document. Therefore for this use-case, I would like to see a global setting for the relative width of these columns. All the best, Christian Christian Wittern, Kyoto
[O] customize agenda time boundaries
Hello. Is it possible to display a week (for example) in agenda, but not from Monday till Sunday, but from 3 days ago from today till 3 days forward? -- sergio.
Re: [O] customize agenda time boundaries
sergio mail...@sergio.spb.ru writes: Is it possible to display a week (for example) in agenda, but not from Monday till Sunday, but from 3 days ago from today till 3 days forward? Hi Sergio, (setq org-agenda-start-on-weekday nil) C-c a a j -3 w Regards, Bernt
Re: [O] customize agenda time boundaries
On 01/23/2012 07:17 AM, Bernt Hansen wrote: (setq org-agenda-start-on-weekday nil) C-c a a j -3 w OK, it works. But it's complicated and week was just an example. How to do the same for 3 days? For one day (show 12 hours before, and 12 after the current moment)? -- sergio.
Re: [O] [ANN] ASCII back-end for new export engine
Aloha Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
A quick question and a couple of comments on the LaTeX exporter.
With the old exporter I set (setq org-export-latex-hyperref-format
\\ref{%s}) so a link to a headline would cross reference properly in
LaTeX. How do I achieve this with the new exporter? I want my text to
read, e.g., In section 1 ... So far with the new exporter, I've only
been able to get In section First headline ...
Indeed, it seems that I forgot to create that variable in the new
exporter. I don't mind adding it, but I'm not sure about where it should
apply.
At the moment, \\hyperref[%s]{%s} format string is applied to id,
custom-id, target, radio, fuzzy/target and fuzzy/headline links.
Changing all those links with just a single variable seems wrong to me.
Maybe it should replace the default value only for id, custom-id and
fuzzy/headline. And since it would only apply to headlines, it could be
renamed `org-e-latex-link-to-headline-format' or something alike.
What do you think about all of this?
I think that your understanding of the new exporter architecture is
intimate and secure. I'm happy to follow your lead here.
My initial impression is the new exporter is extremely fast.
Unfortunately, it's only an impression. It will be slower than the
current exporter in most cases.
I'm sure the difference (which I haven't detected) will be outweighed by
the benefits of the new exporter.
Oh, by the way, it reminds me that I implemented something in the LaTeX
back-end that you had asked for a while ago. If you didn't notice it,
you can try a LaTeX export on the following test buffer:
#+latex_header: \usepackage{paralist}
* Head 1
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
#+attr_latex: inparaenum i.
- item 1
- item 2
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
There is support for the following keywords: inparaenum, asparaenum,
inparaitem, asparaitem, inparadesc, asparadesc, all accepting an
optional bullet argument.
I hadn't noticed this yet. It looks like a terrific example of the
power of your parser. Many thanks for this functionality.
It will take me a while to understand the practical implications of the
level to which you have abstracted Org mode, but I look forward to the
challenge.
I also look forward to the pleasure of using the new LaTeX exporter.
Thanks again for your good work.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Aloha Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
t...@tsdye.com (Thomas S. Dye) writes:
I think there might be a problem with the regular expression for
captions on line 703 or org-e-latex.el. I have a dim understanding of
regular expressions and the various parsers, but I suspect the problem
is in this part: [^][].
At any rate, this input:
#+CAPTION: [An example photograph]{An example photograph}.
#+LABEL: fig:photo
The regexp isn't the problem here. But this all means that I'm breaking
a golden rule: never parse something already parsed.
Anyway, I have switched caption keyword to the dual keywords
category. That means is syntax is now like results keywords' which can
have an optional string (a hash in this case) before their main value.
To put it simply, caption syntax can now be:
#+caption: long name
#+caption[]: long name
#+caption[short name]: long name
much like
#+results[hash]: name
Though,
#+caption[something]:
is equivalent to no caption since the main value is mandatory.
This input:
#+CAPTION[An example photograph]: An example photograph.
#+NAME: fig:photo
for me, yields:
\caption{\label{fig:photo}An example photograph}
I was expecting:
\caption[An example photograph]{\label{fig:photo}An example photograph}
As a side note, #+label has been deprecated in favor of #+name (though
the former is immediately translated into the latter at parse time).
I agree it is a good idea to abstract this from the LaTeX backend.
Regards,
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
[O] org-e-latex remove logfiles
Aloha Nicolas, The documentation string for org-e-latex-remove-logfiles might better be: Non-nil means remove files with the extensions listed in org-e-latex-extensions. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [bug] Tables in lists not exported to ODT
Jambunathan K kjambunat...@gmail.com writes: Btw, I was trying to make the tables cute-looking Just pushed a fix whereby one can control the width of the tables. , commit f9d242 | Customize table width using :rel-width option. For example, to create a | table of width 60% use: | | #+attr_odt: :rel-width 60 | | | A | B | | |---+---| | | | | ` --
Re: [O] [ANN] ASCII back-end for new export engine
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
#+CAPTION[An example photograph]: An example photograph.
#+NAME: fig:photo
for me, yields:
\caption{\label{fig:photo}An example photograph}
I was expecting:
\caption[An example photograph]{\label{fig:photo}An example
photograph}
I get the expected caption command in that case, even from a fresh emacs
-q. You may need to reload Org, or even Emacs.
Regards,
--
Nicolas Goaziou
