Re: [O] source code disappears
Hi all, This is what my patch http://www.mail-archive.com/emacs-orgmode@gnu.org/msg62256.html is meant to fix. @Neil, can you confirm the fix? On Sat, Nov 17, 2012 at 8:41 PM, Bastien wrote: > I will take care of this before the end of the pretest week. -- Le
Re: [O] [PATCH] org-edit-special too much space if starting with empty block
On Fri, Nov 9, 2012 at 8:23 AM, Nicolas Goaziou wrote: > Thank you for your patch. > > Would you mind adding comments in the function in order to explain the > need for two pass. Also, you may want to reverse the if test in order to > get rid of the progn. I've refactored and added comments. > Finally, could you provide the patch as "git format-patch" and add > a changelog entry to it? The patch is now in the requested format. If the commit message and inlined comments still aren't enough to explain the changes, please let me know. Thanks! -- Le org-src.el.patch Description: Binary data
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
2012ko azaroak 17an, Eric Schulte-ek idatzi zuen: > Oh!, thanks for catching this, I just pushed up a fix. This is no longer a (complete) fix for the original problem, though. (A large part of) the slowdown comes from reading the results from a temp file and transforming them into an elispy format, which is handled by the backends. Your code only prevents them from being echoed to the minibuffer. You can see this by trying your original “seq” tests. You should see them taking the same (very long) amount of time. If you set debug-on-quit to t (before evaluating the block) and interrupt emacs with C-g when it hangs, you’ll see a backtrace that goes through ‘org-babel-execute:sh’ and then ‘org-babel-import-elisp-from-file’. The presence of the former in the call stack is why I claim that per-backend fixes are ultimately needed. The latter is where my patch addresses the problem in a temporary way. > > I may be outvoted, but I find this approach too be overly complicated. > Also, size may frequently not be the best proxy for the time which > Emacs will take to ingest the results. I agree that my patch is a stopgap. But until per-backend fixes are available, this allows certain code to run that otherwise wouldn’t (at least not without hacks, such as putting NULL at the end of an R source block so that the “.Last.value” in the block is trivial). -- Aaron Ecay
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
Aaron Ecay writes: > 2012ko azaroak 16an, Eric Schulte-ek idatzi zuen: > >> >> The attached patch adds a "really-silent" results header argument. To >> see the impact compare the running time of the following two code >> blocks. > > Unfortunately, the attached patch doesn’t work correctly. This can be > seen by replacing the “seq” command in your examples with a command that > has side effects – notify-send, aplay, etc. In the :results none” case, > the command is not run at all. > > That’s because the “(funcall cmd body params)” call at l. 574 of ob.el > (patched version) has been put in a branch that is only run if :results > != none. That funcall is responsible for actually evaluating the code > block. > Oh!, thanks for catching this, I just pushed up a fix. > > (The indentation of the patch as applied isn’t correct – the two > branches of the if on l. 565 are indented at the same depth as each > other, and as the if. So it’s possible that the problem is due to a > paren in the wrong place. But I cannot see a way to make this approach > work.) > Yes, sometimes I find this approach to be preferable to make the diffs more readable and to avoid over-indentation in very large functions. > > The code generating the slowdown is in backend-specific files. So, for > example, a new branch needs to be added to the case statements in > org-babel-R-evaluate(-session), to detect the :results none case and not > read the result. I suspect that each backend will need this treatment > (unless some of them share code). > > In the meantime, attached to this email is a patch that implements a > size check on reading results. If the results file is over 10kb, it > asks the user whether to proceed. You can test this by evaluating: > > #+begin_src sh :results silent > seq 1 > #+end_src > > 10kb of results actually doesn’t result in a very serious hang (~5sec on > my system). But I chose the value as more of a sanity check – odds are > (?) that very few people want to see 10k of results in the (mini)buffer. > The value could be made customizable. > > I also chose the polarity of the y-or-n-p so that picking the default > (yes) option does the sensible thing of not hanging emacs, although it > thus does discard data. I’m not sure which is the worse problem. > I may be outvoted, but I find this approach too be overly complicated. Also, size may frequently not be the best proxy for the time which Emacs will take to ingest the results. Best, > > From 1053f3acfc21f24fc994ae85adff6779838b0ce7 Mon Sep 17 00:00:00 2001 > From: Aaron Ecay > Date: Sat, 17 Nov 2012 19:26:43 -0500 > Subject: [PATCH] lisp/ob.el: add a size check to > `org-babel-import-elisp-from-file' > > Reading large results can cause emacs to hang for a long time. Ask the > user whether to proceed in such cases. > > Signed-off-by: Aaron Ecay > --- > lisp/ob.el | 42 -- > 1 file changed, 24 insertions(+), 18 deletions(-) > > diff --git a/lisp/ob.el b/lisp/ob.el > index bf4b455..b2385e9 100644 > --- a/lisp/ob.el > +++ b/lisp/ob.el > @@ -2462,24 +2462,30 @@ appropriate." > (defun org-babel-import-elisp-from-file (file-name &optional separator) >"Read the results located at FILE-NAME into an elisp table. > If the table is trivial, then return it as a scalar." > - (let (result) > -(save-window-excursion > - (with-temp-buffer > - (condition-case err > - (progn > - (org-table-import file-name separator) > - (delete-file file-name) > - (setq result (mapcar (lambda (row) > - (mapcar #'org-babel-string-read row)) > -(org-table-to-lisp > - (error (message "Error reading results: %s" err) nil))) > - (if (null (cdr result)) ;; if result is trivial vector, then scalarize > it > - (if (consp (car result)) > - (if (null (cdr (car result))) > - (caar result) > - result) > - (car result)) > - result > + (let* ((file-size (nth 7 (file-attributes file-name))) > + (can-load (or (< file-size (* 10 1024)) ; 10kb > + (not (y-or-n-p (concat "Displaying the block's large " > + "results may hang emacs; skip " > + "reading them?")) > +(when can-load > + (let (result) > +(save-window-excursion > + (with-temp-buffer > +(condition-case err > +(progn > + (org-table-import file-name separator) > + (delete-file file-name) > + (setq result (mapcar (lambda (row) > + (mapcar #'org-babel-string-read > row)) > + (org-table-to-lisp > + (error (message "Error reading results: %s" err) nil))) > + (if (null (cdr resul
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
2012ko azaroak 16an, Eric Schulte-ek idatzi zuen: > > The attached patch adds a "really-silent" results header argument. To > see the impact compare the running time of the following two code > blocks. Unfortunately, the attached patch doesn’t work correctly. This can be seen by replacing the “seq” command in your examples with a command that has side effects – notify-send, aplay, etc. In the :results none” case, the command is not run at all. That’s because the “(funcall cmd body params)” call at l. 574 of ob.el (patched version) has been put in a branch that is only run if :results != none. That funcall is responsible for actually evaluating the code block. (The indentation of the patch as applied isn’t correct – the two branches of the if on l. 565 are indented at the same depth as each other, and as the if. So it’s possible that the problem is due to a paren in the wrong place. But I cannot see a way to make this approach work.) The code generating the slowdown is in backend-specific files. So, for example, a new branch needs to be added to the case statements in org-babel-R-evaluate(-session), to detect the :results none case and not read the result. I suspect that each backend will need this treatment (unless some of them share code). In the meantime, attached to this email is a patch that implements a size check on reading results. If the results file is over 10kb, it asks the user whether to proceed. You can test this by evaluating: #+begin_src sh :results silent seq 1 #+end_src 10kb of results actually doesn’t result in a very serious hang (~5sec on my system). But I chose the value as more of a sanity check – odds are (?) that very few people want to see 10k of results in the (mini)buffer. The value could be made customizable. I also chose the polarity of the y-or-n-p so that picking the default (yes) option does the sensible thing of not hanging emacs, although it thus does discard data. I’m not sure which is the worse problem. >From 1053f3acfc21f24fc994ae85adff6779838b0ce7 Mon Sep 17 00:00:00 2001 From: Aaron Ecay Date: Sat, 17 Nov 2012 19:26:43 -0500 Subject: [PATCH] lisp/ob.el: add a size check to `org-babel-import-elisp-from-file' Reading large results can cause emacs to hang for a long time. Ask the user whether to proceed in such cases. Signed-off-by: Aaron Ecay --- lisp/ob.el | 42 -- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index bf4b455..b2385e9 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -2462,24 +2462,30 @@ appropriate." (defun org-babel-import-elisp-from-file (file-name &optional separator) "Read the results located at FILE-NAME into an elisp table. If the table is trivial, then return it as a scalar." - (let (result) -(save-window-excursion - (with-temp-buffer - (condition-case err - (progn - (org-table-import file-name separator) - (delete-file file-name) - (setq result (mapcar (lambda (row) - (mapcar #'org-babel-string-read row)) - (org-table-to-lisp - (error (message "Error reading results: %s" err) nil))) - (if (null (cdr result)) ;; if result is trivial vector, then scalarize it - (if (consp (car result)) - (if (null (cdr (car result))) - (caar result) - result) - (car result)) - result + (let* ((file-size (nth 7 (file-attributes file-name))) + (can-load (or (< file-size (* 10 1024)) ; 10kb + (not (y-or-n-p (concat "Displaying the block's large " + "results may hang emacs; skip " + "reading them?")) +(when can-load + (let (result) +(save-window-excursion + (with-temp-buffer +(condition-case err +(progn + (org-table-import file-name separator) + (delete-file file-name) + (setq result (mapcar (lambda (row) + (mapcar #'org-babel-string-read row)) + (org-table-to-lisp + (error (message "Error reading results: %s" err) nil))) + (if (null (cdr result)) ;; if result is trivial vector, then scalarize it + (if (consp (car result)) + (if (null (cdr (car result))) + (caar result) +result) +(car result)) +result)) (defun org-babel-string-read (cell) "Strip nested \"s from around strings." -- 1.8.0 -- Aaron Ecay
Re: [O] [org-e-texinfo] generate menu items
Nicolas Goaziou writes:
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Nicolas Goaziou writes:
>>
>>> t...@tsdye.com (Thomas S. Dye) writes:
>>>
Agreed. Perhaps a new property, OPTIONAL_TITLE? The texinfo back-end
could use this in menus and the latex back-end could pass it to the
sectioning command, e.g., \chapter[optional]{title} (if this isn't
already possible).
>>>
>>> Back-ends can indeed use specific properties (Beamer back-end does it
>>> with "BEAMER_ENV" and so on). Though, I suggest to prefix the property
>>> name with the name of the backend: "TEXINFO_OPTIONAL_TITLE" (perhaps
>>> a bit verbose).
>>>
>>> Then, one can access to it from the headline translator with:
>>>
>>> (org-element-property :texinfo-optional-title headline)
>>>
>>> Anyway, Jonathan Leech-Pepin will decide what to do about that.
>>
>> I looked in org-e-latex.el but didn't find a way to set the optional
>> argument to a sectioning command. Is there currently a way to set this
>> argument?
>
> No there isn't.
>
> I had overlooked the fact that you wanted the property to be effective
> across back-ends. So, it would define how the entry should appear in the
> table of contents in every back-end where it makes sense.
>
> That's a bit of work, because, so far, node-property values are not
> parsed. So it would require to define a new class of node-properties:
> those with a parsed value. But then, how to decide which properties have
> their value parsed are parsed and which have not?
Thanks for the information and explanation. Back-end-specific
properties should work nicely in this case.
I'll wait to see what Jonathan thinks about the original query.
All the best,
Tom
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] [org-e-texinfo] generate menu items
t...@tsdye.com (Thomas S. Dye) writes:
> Nicolas Goaziou writes:
>
>> t...@tsdye.com (Thomas S. Dye) writes:
>>
>>> Agreed. Perhaps a new property, OPTIONAL_TITLE? The texinfo back-end
>>> could use this in menus and the latex back-end could pass it to the
>>> sectioning command, e.g., \chapter[optional]{title} (if this isn't
>>> already possible).
>>
>> Back-ends can indeed use specific properties (Beamer back-end does it
>> with "BEAMER_ENV" and so on). Though, I suggest to prefix the property
>> name with the name of the backend: "TEXINFO_OPTIONAL_TITLE" (perhaps
>> a bit verbose).
>>
>> Then, one can access to it from the headline translator with:
>>
>> (org-element-property :texinfo-optional-title headline)
>>
>> Anyway, Jonathan Leech-Pepin will decide what to do about that.
>
> I looked in org-e-latex.el but didn't find a way to set the optional
> argument to a sectioning command. Is there currently a way to set this
> argument?
No there isn't.
I had overlooked the fact that you wanted the property to be effective
across back-ends. So, it would define how the entry should appear in the
table of contents in every back-end where it makes sense.
That's a bit of work, because, so far, node-property values are not
parsed. So it would require to define a new class of node-properties:
those with a parsed value. But then, how to decide which properties have
their value parsed are parsed and which have not?
Regards,
--
Nicolas Goaziou
Re: [O] Beamer frame with an empty title ?
> There is now a "fullframe" environment. > > No need to be clairvoyant to guess that I'm working on yet another course for next week :-/ So : thanks to be that helpful. Fabrice
Re: [O] [org-e-texinfo] generate menu items
Nicolas Goaziou writes:
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Agreed. Perhaps a new property, OPTIONAL_TITLE? The texinfo back-end
>> could use this in menus and the latex back-end could pass it to the
>> sectioning command, e.g., \chapter[optional]{title} (if this isn't
>> already possible).
>
> Back-ends can indeed use specific properties (Beamer back-end does it
> with "BEAMER_ENV" and so on). Though, I suggest to prefix the property
> name with the name of the backend: "TEXINFO_OPTIONAL_TITLE" (perhaps
> a bit verbose).
>
> Then, one can access to it from the headline translator with:
>
> (org-element-property :texinfo-optional-title headline)
>
> Anyway, Jonathan Leech-Pepin will decide what to do about that.
I looked in org-e-latex.el but didn't find a way to set the optional
argument to a sectioning command. Is there currently a way to set this
argument?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [org-e-texinfo] generate menu items
t...@tsdye.com (Thomas S. Dye) writes:
> Agreed. Perhaps a new property, OPTIONAL_TITLE? The texinfo back-end
> could use this in menus and the latex back-end could pass it to the
> sectioning command, e.g., \chapter[optional]{title} (if this isn't
> already possible).
Back-ends can indeed use specific properties (Beamer back-end does it
with "BEAMER_ENV" and so on). Though, I suggest to prefix the property
name with the name of the backend: "TEXINFO_OPTIONAL_TITLE" (perhaps
a bit verbose).
Then, one can access to it from the headline translator with:
(org-element-property :texinfo-optional-title headline)
Anyway, Jonathan Leech-Pepin will decide what to do about that.
Regards,
--
Nicolas Goaziou
Re: [O] Beamer frame with an empty title ?
Fabrice Popineau writes: > That would be definitely nice. I think it is quite common that you want to > get rid of everything to have more space for a big drawing > (moreover it breaks the monotony of the layout) There is now a "fullframe" environment. Regards, -- Nicolas Goaziou
Re: [O] Beamer frame with an empty title ?
Oh ... it seems you can do it simply this way :
\begin{frame}[plain,t]{}
\includegraphics[width=\textwidth, height=\textheight]{mypicture}
\end{frame}
Fabrice
2012/11/17 Myles English
>
> Hi Fabrice and Nicolas,
>
> Fabrice Popineau writes:
>
> > That would be definitely nice. I think it is quite common that you want
> to
> > get rid of everything to have more space for a big drawing
> > (moreover it breaks the monotony of the layout)
>
> I don't fully understand this thread but to get a full frame photo on a
> slide I once did this, essentially turn the wallpaper on, make a blank
> slide, turn it off again (looks like it used the old, current,
> exporter):
>
> ** Turn on wallpaper
> :B_ignoreheading:
> :PROPERTIES:
> :BEAMER_env: ignoreheading
> :END:
> #+begin_latex
> \setbeamertemplate{background canvas}%
> {\ThisULCornerWallPaper{1.115}%
> {/home/myles/MASSIVE_PHOTO.jpg}}
> #+end_latex
>
> **
> :B_columns:
> :PROPERTIES:
> :BEAMER_env: columns
> :END:
>
> \vskip15pt
>
> ** Turn off wallpaper
> :B_ignoreheading:
> :PROPERTIES:
> :BEAMER_env: ignoreheading
> :END:
>
> #+begin_latex
> \setbeamertemplate{background canvas}{\ClearWallPaper}
> \setbeamercolor{normal text}{bg=gray!30}
> #+end_latex
>
>
> Myles
>
Re: [O] Beamer 2 columns
Fabrice Popineau writes: > Hmmm ... well ... I was mistaken by using BEAMER_envargs because it is for > the old exporter, > but it doesn't work either by using BEAMER_opt which should be recognized > by the new exporter. Indeed, that was a bug in org-e-beamer.el: columns environment didn't accept options. It should be fixed in master. Thank you for reporting this. Regards, -- Nicolas Goaziou
Re: [O] Beamer 2 columns
Hmmm ... well ... I was mistaken by using BEAMER_envargs because it is for
the old exporter,
but it doesn't work either by using BEAMER_opt which should be recognized
by the new exporter.
Fabrice
2012/11/17 Fabrice Popineau
> Another problem I can't wolve with the new exporter :
>
> I have this text for two columns :
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> *** columns :B_columns:
> :PROPERTIES:
> :BEAMER_env: columns
> :BEAMER_envargs: T
> :END:
> [2012-11-17 sam. 17:41]
> columns :BMCOL:
> :PROPERTIES:
> :BEAMER_col: 0.5
> :END:
> some text
>
> columns :BMCOL:
> :PROPERTIES:
> :BEAMER_col: 0.5
> :END:
> [2012-11-17 sam. 17:31]
> some text
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> I want to export it to beamer with the new exporter; but I can't get the
> 'T' parameter in the resulting output. It gives me :
>
> \begin{columns}
> \begin{column}{0.5\textwidth}
> some text
> \end{column}
> \begin{column}{0.5\textwidth}
> some text
> \end{column}
> \end{columns}
>
> Is my source correct ? I'm not even sure it is intended this way with the
> new exporter.
>
> --
> Fabrice
>
>
Re: [O] [org-e-texinfo] generate menu items
Nicolas Goaziou writes:
> Hello,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> An Org manual convention uses title case for the main menu and sentence
>> case for chapter heads, e.g., the chapter "Document structure" shows up
>> in the main menu as "Document Structure".
>>
>> I haven't been able to get the texinfo exporter to do this.
>>
>> Perhaps org-e-texinfo--generate-menu-items could check the EXPORT_TITLE
>> property? Something like this might make sense:
>>
>> * Document structure
>> :PROPERTIES:
>> :DESCRIPTION: A tree works like your brain
>> :EXPORT_TITLE: Document Structure
>> :END:
>
> EXPORT_TITLE property is meant to provide a title for a subtree export.
> This is a wrong way to use it like that.
Agreed. Perhaps a new property, OPTIONAL_TITLE? The texinfo back-end
could use this in menus and the latex back-end could pass it to the
sectioning command, e.g., \chapter[optional]{title} (if this isn't
already possible).
> On the other hand, wouldn't it
> be possible to simply `capitalize' menu entries?
I don't think so. We want either sentence case (Properties and columns)
or title case (Properties and Columns), not capitalized (Properties And
Columns).
All the best,
Tom
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] [org-e-texinfo] generate menu items
Hello, t...@tsdye.com (Thomas S. Dye) writes: > An Org manual convention uses title case for the main menu and sentence > case for chapter heads, e.g., the chapter "Document structure" shows up > in the main menu as "Document Structure". > > I haven't been able to get the texinfo exporter to do this. > > Perhaps org-e-texinfo--generate-menu-items could check the EXPORT_TITLE > property? Something like this might make sense: > > * Document structure > :PROPERTIES: > :DESCRIPTION: A tree works like your brain > :EXPORT_TITLE: Document Structure > :END: EXPORT_TITLE property is meant to provide a title for a subtree export. This is a wrong way to use it like that. On the other hand, wouldn't it be possible to simply `capitalize' menu entries? Regards, -- Nicolas Goaziou
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Nicolas Goaziou writes:
>> I didn't manage to get your (Nicolas') or my own attempt working
>> correctly for exporting matrices. I still think it would be nice.
> It's hard to fix this since you're not very explicit here.
Sorry; you posted a code first which didn't work at all for me; I
tried to fix it, and I posted a code which I though worked but in the
end it didn't. Thus, I though it would be fair to post another
message stating this, if nothing else than for future viewers.
>> I tried to use the regexp
>>(not (string-match "|[\\+-]+|" table))
>> to identify tables without heading separators, but it didn't work
>> properly.
>
> It cannot work in filters. These are applied on back-end ouput, in
> this case LaTeX code, not on Org code.
Aha, that explains a lot. At some point when I don't have so many
assignments I really need to get to know the details of your work.
It's has so many cool features.
> There is no TBLOPTIONS affiliated keyword, but it could go in
> ATTR_LATEX
That a lot more clever. I just made up TBLOPTIONS since I couldn't
think of anywhere better. But you are of right. Such an option would
fit perfectly into ATTR_LATEX.
> If you provide a full description of options and their effect, I
> might try to implement it.
Okay I'll try. I don't know whether something like the below is what
you are thinking of. I use matrices all of the time so it would be
nice for me.
- PROPOSAL: New option(s)for ATTR_LATEX
- :type :: options a lisp translation function or key words
associated with a lisp list translation function.
- Default keyword: table; other known keywords: matrix
- table: current exporter
- matrix: exports to LaTeX matrix determined by the variable
org-export-latex-tables-matrix-default-type or :matrix-type.
Default is: bmatrix or pmatrix (probably bmatrix).
- in general array requires more configuration, but for me
array need not be supported.
- Matrix relevant keywords :: are the following
- If the additional variable ALIGN is set to k ∈ {l,r,c} use
the starred version of
org-export-latex-tables-matrix-default-type or :matrix-type
- If the additional keyword :bordered is t use the typeset
the matrix as \borderedmatrix{&col1&
... &colN\\row1&...\\...\\rowN}. A better example is
here ¹. Also, the default bordermatrix macro is determined
via org-export-latex-tables-matrix-bordered-type s.t. one
can specify kbordermatrix ² or qbordermatrix ³. Perhaps
Org automatically add the respective usepackage if this
option is set to something different from bordermatrix
(i.e. org-export-latex-tables-matrix-bordered-type is a
list of lists where the first element of a list is the
macro name and the second is the needed package).
- If :matrix-pre "string" is set "string" is typeset before
the matrix
- If :matrix-post "string" is set then "string" is typeset
after the matrix.
- Alternatively, CAPTION could be used, but it seems weird.
Are they written before or after the matrix? I'd prefer
CAPTIONs to be ignored typeset when matrices are typeset.
- If the table has a name the matrix is typeset using
equation and given an label. If not it may be typeset
using equation* or \[·\].
- Potentially: an :inline exists s.t. if inline is t the
matrix is typeset inline [i.e. with \(\)]. Perhaps, it
should be smart and use the small verison of
org-export-latex-tables-matrix-default-type. I.e. if
bmatrix use bsmallmatrix. This could be set via
org-export-latex-tables-matrix-inline-small.
Thanks,
Rasmus
Footnotes:
¹ http://www.math.harvard.edu/texman/node25.html
² https://www.hss.caltech.edu/~kcb/LaTeX.shtml
³ https://code.google.com/p/qbordermatrix/
--
When the facts change, I change my mind. What do you do, sir?
[O] [org-e-texinfo] generate menu items
Aloha all, An Org manual convention uses title case for the main menu and sentence case for chapter heads, e.g., the chapter "Document structure" shows up in the main menu as "Document Structure". I haven't been able to get the texinfo exporter to do this. Perhaps org-e-texinfo--generate-menu-items could check the EXPORT_TITLE property? Something like this might make sense: * Document structure :PROPERTIES: :DESCRIPTION: A tree works like your brain :EXPORT_TITLE: Document Structure :END: All the best, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] C# and org-mode
Fabrice Popineau writes: > Hi, > > Given that there is this C# mode : > http://www.emacswiki.org/emacs/csharp-mode.el > is there a way to plug it in org-mode so that > C# becomes part of the languages available for src blocks? > I don't know much about C#. Assuming it is similar to C/C++ you could take a look at tweaking lisp/ob-C.el file in Org-mode to add C# support following the same model used to add C++ support in that file. For more sophisticated interaction with C#-mode you may want to implement a dedicated ob-csharp.el from this template. http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el Best, > > Regards, > > Fabrice -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
Achim Gratz writes: > Andreas Leha writes: >> I would suggest simply "none" for the new "really-silent". > > Yes please, especially since I tried ":results none" two days ago to > achieve that effect and wondered why it wouldn't work. :-) > Great, since "none" seems like the obvious choice I just committed a version of this patch which places this behavior behind ":results none". At some point documentation should be added to the relevant portion of the manual, but at least we now have this for those reading the mailing list and for those who simply try "none" with this behavior in mind. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Beamer frame with an empty title ?
Hi Fabrice and Nicolas,
Fabrice Popineau writes:
> That would be definitely nice. I think it is quite common that you want to
> get rid of everything to have more space for a big drawing
> (moreover it breaks the monotony of the layout)
I don't fully understand this thread but to get a full frame photo on a
slide I once did this, essentially turn the wallpaper on, make a blank
slide, turn it off again (looks like it used the old, current,
exporter):
** Turn on wallpaper :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
#+begin_latex
\setbeamertemplate{background canvas}%
{\ThisULCornerWallPaper{1.115}%
{/home/myles/MASSIVE_PHOTO.jpg}}
#+end_latex
**:B_columns:
:PROPERTIES:
:BEAMER_env: columns
:END:
\vskip15pt
** Turn off wallpaper :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
#+begin_latex
\setbeamertemplate{background canvas}{\ClearWallPaper}
\setbeamercolor{normal text}{bg=gray!30}
#+end_latex
Myles
Re: [O] Beamer frame with an empty title ?
> If such need is common enough, we may provide a special environment, > much like "againframe", which would provide a frame without title. For > example: > > * Headline > :PROPERTIES: > :BEAMER_env: fullframe > :END: > > What do you think about it? > > > That would be definitely nice. I think it is quite common that you want to get rid of everything to have more space for a big drawing (moreover it breaks the monotony of the layout) Fabrice
Re: [O] Beamer frame with an empty title ?
Fabrice Popineau writes:
>> Otherwise, you can define a dummy string, i.e. "NOTITLE", use that as
>> the headline. Then, with the appropriate filter, you can change
>> \begin{frame}[...]{NOTITLE} into \begin{frame}[...]{}.
>>
>>
> But this one will work and is esay enough. Thanks.
If such need is common enough, we may provide a special environment,
much like "againframe", which would provide a frame without title. For
example:
* Headline
:PROPERTIES:
:BEAMER_env: fullframe
:END:
What do you think about it?
Regards,
--
Nicolas Goaziou
Re: [O] Beamer frame with an empty title ?
Would a non-breaking space as the title work?
>
> Nope, because, the space for the title would still be there and I want to
put a full frame image
> Otherwise, you can define a dummy string, i.e. "NOTITLE", use that as
> the headline. Then, with the appropriate filter, you can change
> \begin{frame}[...]{NOTITLE} into \begin{frame}[...]{}.
>
>
> But this one will work and is esay enough. Thanks.
Fabrice
Re: [O] Beamer frame with an empty title ?
Hello,
Fabrice Popineau writes:
> Everything is in the question ...
>
> How to generate :
>
> \begin{frame}[label=...]{}
>
> \end{frame}
>
> It seems that org-requires a non-empty header.
>
> Thanks for any hint,
Would a non-breaking space as the title work?
Otherwise, you can define a dummy string, i.e. "NOTITLE", use that as
the headline. Then, with the appropriate filter, you can change
\begin{frame}[...]{NOTITLE} into \begin{frame}[...]{}.
Regards,
--
Nicolas Goaziou
Re: [O] subtree-export limitations
Philipp Kroos writes: > That said, I'm fine with the situation, but I'ld suggest a note in the > documentation that makes this limitation to subtree-exports clear (and > possibly points out the workarounds). What do you think? Sure. What should be written in that note? Where to put it? Or, better, do you want to provide a patch for that? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
On Sat, Nov 17, 2012 at 03:42:24PM +0100, Nicolas Goaziou wrote: > Toby Cubitt writes: > > > I've replaced the cons cells with additional plist properties, as you > > suggested. The resulting customization ui still isn't wonderful in my > > opinion. But it does the job, and I'm not sure how much scope there is > > for improving it further. If you see a way, by all means feel free to > > make the changes yourself. I really don't mind what format you go with > > for org-time-clocksum-format, as long as it supports the new formatting > > features implemented in the patch. > > Considering I'm not an expert in customize ui, it's good enough as it > is. OK. If someone thinks of a way to improve the customization ui (keeping the same data type), it's easy to change it later without breaking anything. > I've applied your patch (with some small changes in a docstring). Thank > you again for all that work. Glad we finally found a good implementation. Thanks to you for all your helpful feedback. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] Beamer frame with an empty title ?
Everything is in the question ...
How to generate :
\begin{frame}[label=...]{}
\end{frame}
It seems that org-requires a non-empty header.
Thanks for any hint,
--
Fabrice
Re: [O] [PATCH] org-e-latex: Fixes bug introduced by commit 907110e
Hello, Myles English writes: > I forgot the say TINYCHANGE. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Rasmus Pank Roulund writes:
> I didn't manage to get your (Nicolas') or my own attempt working
> correctly for exporting matrices. I still think it would be nice.
It's hard to fix this since you're not very explicit here.
> I tried to use the regexp
>(not (string-match "|[\\+-]+|" table))
> to identify tables without heading separators, but it didn't work
> properly.
It cannot work in filters. These are applied on back-end ouput, in this
case LaTeX code, not on Org code.
> Thinking about it, it might be nice to be able to specify table export
> function more generally. For instance, I might have a matrix with
> labels (in LaTeX a bordermatrix or kbordermatrix). Likewise, it might
> also be nice to specify a header argument to tables s.t. I can specify
> a name, e.g.
>
> #+NAME: P
> #+TBLOPTIONS: :prefix "P=" :type matrix
> | a| b|
> | c| d|
>
> would export to
> \[P=\begin{bmatrix}a&b\\c&d\end{bmatrix}\]
There is no TBLOPTIONS affiliated keyword, but it could go in ATTR_LATEX
since this probably only makes sense in a LaTeX-type output. If you
provide a full description of options and their effect, I might try to
implement it.
Regards,
--
Nicolas Goaziou
Re: [O] [PATCH] org-e-latex: Fixes bug introduced by commit 907110e
I forgot the say TINYCHANGE.
Myles English writes:
> Fixes bug reported to the mailing list with "[O] [BUG] centering export
> of babel results".
>
> From e9e99b22d814c1272475f30e4bc7543cc46603f4 Mon Sep 17 00:00:00 2001
> From: Myles English
> Date: Sat, 17 Nov 2012 15:18:16 +
> Subject: [PATCH] org-e-latex: Fixes bug introduced by commit 907110e
>
> * contrib/lisp/org-e-latex.el: Floating tables get a \centering
> declaration, otherwise the table get wrapped in \begin{center}
> and \end{center} environment.
>
> Thanks to Andreas Leha for reporting it.
> ---
> contrib/lisp/org-e-latex.el | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/contrib/lisp/org-e-latex.el b/contrib/lisp/org-e-latex.el
> index 41513a1..d74c30a 100644
> --- a/contrib/lisp/org-e-latex.el
> +++ b/contrib/lisp/org-e-latex.el
> @@ -2302,20 +2302,22 @@ This function assumes TABLE has `org' as its `:type'
> attribute."
> (if (or org-e-latex-table-caption-above (string= "" caption)) ""
>(concat (org-trim caption) "\n"
> ;; Others.
> - (t (concat (when float-env
> + (t (concat (if float-env
> (concat
> (format "\\begin{%s}%s\n" float-env placement)
> -(if org-e-latex-table-caption-above caption "")))
> - (when org-e-latex-tables-centered "\\centering\n")
> +(if org-e-latex-table-caption-above caption "")
> +(when org-e-latex-tables-centered "\\centering\n"))
> + (when org-e-latex-tables-centered "\\begin{center}\n"))
> (format "\\begin{%s}%s{%s}\n%s\\end{%s}"
> table-env
> (if width (format "{%s}" width) "")
> alignment
> contents
> table-env)
> - (when float-env
> + (if float-env
> (concat (if org-e-latex-table-caption-above "" caption)
> - (format "\n\\end{%s}" float-env
> + (format "\n\\end{%s}" float-env))
> + (when org-e-latex-tables-centered "\n\\end{center}")))
>
> (defun org-e-latex-table--table.el-table (table contents info)
>"Return appropriate LaTeX code for a table.el table.
Re: [O] [BUG] centering export of babel results
Hi Andreas,
Andreas Leha writes:
> Andreas Leha writes:
>
>> Hi all,
>>
>> There is a bug in the newly introduced centering-instead-of-center
>> feature when it comes to babel results.
Thanks for reporting it.
>> Here is the problem (already *unintentionally* centered):
I don't know how to intentionally uncenter tables.
>> #+begin_src R :exports results :colnames yes data.frame(a=1:2, b=3:4)
>> #+end_src
>>
>> #+results:
>> | a | b |
>> |---+---|
>> | 1 | 3 |
>> | 2 | 4 |
>>
>> This remains *unintentionally* centered.
>>
>> Regards,
>> Andreas
>
> I should have added, that a simple work-around would be sth like
>
>
> Here is the problem (already *unintentionally* centered):
> #+LaTeX: { \\%}
> #+begin_src R :exports results :colnames yes
> data.frame(a=1:2, b=3:4)
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 3 |
> | 2 | 4 |
> #+LaTeX: }
>
> This remains *unintentionally* centered.
I have just sent a patch to the mailing list to fix the problem you
hinted at.
Myles
[O] [PATCH] org-e-latex: Fixes bug introduced by commit 907110e
Fixes bug reported to the mailing list with "[O] [BUG] centering export
of babel results".
>From e9e99b22d814c1272475f30e4bc7543cc46603f4 Mon Sep 17 00:00:00 2001
From: Myles English
Date: Sat, 17 Nov 2012 15:18:16 +
Subject: [PATCH] org-e-latex: Fixes bug introduced by commit 907110e
* contrib/lisp/org-e-latex.el: Floating tables get a \centering
declaration, otherwise the table get wrapped in \begin{center}
and \end{center} environment.
Thanks to Andreas Leha for reporting it.
---
contrib/lisp/org-e-latex.el | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/contrib/lisp/org-e-latex.el b/contrib/lisp/org-e-latex.el
index 41513a1..d74c30a 100644
--- a/contrib/lisp/org-e-latex.el
+++ b/contrib/lisp/org-e-latex.el
@@ -2302,20 +2302,22 @@ This function assumes TABLE has `org' as its `:type'
attribute."
(if (or org-e-latex-table-caption-above (string= "" caption)) ""
(concat (org-trim caption) "\n"
;; Others.
- (t (concat (when float-env
+ (t (concat (if float-env
(concat
(format "\\begin{%s}%s\n" float-env placement)
- (if org-e-latex-table-caption-above caption "")))
- (when org-e-latex-tables-centered "\\centering\n")
+ (if org-e-latex-table-caption-above caption "")
+ (when org-e-latex-tables-centered "\\centering\n"))
+ (when org-e-latex-tables-centered "\\begin{center}\n"))
(format "\\begin{%s}%s{%s}\n%s\\end{%s}"
table-env
(if width (format "{%s}" width) "")
alignment
contents
table-env)
- (when float-env
+ (if float-env
(concat (if org-e-latex-table-caption-above "" caption)
- (format "\n\\end{%s}" float-env
+ (format "\n\\end{%s}" float-env))
+ (when org-e-latex-tables-centered "\n\\end{center}")))
(defun org-e-latex-table--table.el-table (table contents info)
"Return appropriate LaTeX code for a table.el table.
--
1.8.0
Re: [O] subtree-export limitations
Nicolas Goaziou writes: > Nicolas Goaziou writes: > >> It might support "Property+" syntax, but it looks like this is >> Babel-specific (no sign of such syntax in org.el, where property API is >> defined). I will look into it (unless you want to do it). > > Well, scratch that: it already support :property+: syntax. I.e. try to > export subtree with: > > * Test export > :PROPERTIES: > :export_latex_header: header1 > :export_latex_header+: header2 > :END: > > Test Amazing! I didn't even know about the property+-syntax... Now that's not as good as it *could* get since the headerlines are separated by space rather than newline, but it's another very useful option for a workaround at least. After all, I think that a complete solution to this problem would break the consistency of properties, like you said, or would have to introduce yet another kind of syntax, what is clearly no option. That said, I'm fine with the situation, but I'ld suggest a note in the documentation that makes this limitation to subtree-exports clear (and possibly points out the workarounds). What do you think? Philipp
Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
Toby Cubitt writes: > I've replaced the cons cells with additional plist properties, as you > suggested. The resulting customization ui still isn't wonderful in my > opinion. But it does the job, and I'm not sure how much scope there is > for improving it further. If you see a way, by all means feel free to > make the changes yourself. I really don't mind what format you go with > for org-time-clocksum-format, as long as it supports the new formatting > features implemented in the patch. Considering I'm not an expert in customize ui, it's good enough as it is. I've applied your patch (with some small changes in a docstring). Thank you again for all that work. Regards, -- Nicolas Goaziou
[O] C# and org-mode
Hi, Given that there is this C# mode : http://www.emacswiki.org/emacs/csharp-mode.el is there a way to plug it in org-mode so that C# becomes part of the languages available for src blocks? Regards, Fabrice
Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
On Sat, Nov 17, 2012 at 09:48:09AM +0100, Nicolas Goaziou wrote:
> Toby Cubitt writes:
>
> > Here's an updated patch. Now both org-time-clocksum-format and
> > org-time-clocksum-fractional-format can be plists, as discussed.
>
> That was quick. Thank you.
>
> > In the org-time-clocksum-format case, I made the values cons cells which
> > specify both a format string and a boolean. The latter indicates whether
> > the time component should always be included in the formatted duration,
> > even if its value is 0. This is needed for the hours component to
> > reproduce the current default format, and I figured I might as well make
> > it general.
>
> I understand. It is a necessary evil. Though, instead of asking for cons
> cells, maybe the boolean could be provided as another property. I.e.
>
> '(:hour "..." :persistent-hour t)
>
> would be a replacement for:
>
> '(:hour ("..." . t))
>
> And, better,
>
> '(:hour "...")
>
> would the become a replacement for
>
> '(:hour ("..." . nil))
>
> What do you think about it? The name of the property is only a
> suggestion.
Good idea. I agree, additional keys are cleaner than cons cells.
> > I used a somewhat complex customization type in the defcustoms,
> > instead of a straight plist, in order to produce a better ui for the
> > customization interface. I'm still not completely satisfied with it.
> > E.g. it would be nice to get rid of the "Cons cell" tag entirely, and
> > use a checkbox for the boolean. But I can't figure out how to do that
> > (without defining new customization types/widgets, which I don't have
> > the patience for).
>
> The advantage of the method above it that it would /de facto/ get rid of
> the "Cons cell" tag.
I've replaced the cons cells with additional plist properties, as you
suggested. The resulting customization ui still isn't wonderful in my
opinion. But it does the job, and I'm not sure how much scope there is
for improving it further. If you see a way, by all means feel free to
make the changes yourself. I really don't mind what format you go with
for org-time-clocksum-format, as long as it supports the new formatting
features implemented in the patch.
> > +(org-add-props (concat (format "%s " (make-string l ?*))
> > + (org-minutes-to-clocksum-string
> > time)
> > + (format "%s" (make-string (- 16 l)
> > ?\ )))
>
> You forgot to change that.
Ooops. Fixed in the attached version.
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
>From 6e87864c125676093d8072111519c37cf9dd126c Mon Sep 17 00:00:00 2001
From: "Toby S. Cubitt"
Date: Sun, 11 Nov 2012 22:20:24 +
Subject: [PATCH] Allow more flexible customization of clocksum format
* lisp/org.el (org-time-clocksum-format, org-time-clocksum-fractional-format):
in addition to a single format string, the clocksum formats can now be
plists specifying separate formats for different time units.
* lisp/org.el (org-minutes-to-clocksum-string): new function to
replace org-minutes-to-hh:mm-string, which converts a number of
minutes to a string according to the customization options.
* lisp/org-colview.el (org-columns-number-to-string): use new
org-minutes-to-clocksum-string function to format clocksum durations.
* lisp/org-clock.el: always call new org-minutes-to-clocksum-string
function when formatting time durations, instead of calling
org-minutes-to-hh:mm-string or passing org-time-clocksum-format
directly to format.
---
lisp/org-clock.el | 51 +-
lisp/org-colview.el |3 +-
lisp/org.el | 190 ---
3 files changed, 198 insertions(+), 46 deletions(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 84eb2fd..54e4018 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -556,28 +556,23 @@ pointing to it."
If an effort estimate was defined for the current item, use
01:30/01:50 format (clocked/estimated).
If not, show simply the clocked time like 01:50."
- (let* ((clocked-time (org-clock-get-clocked-time))
- (h (floor clocked-time 60))
- (m (- clocked-time (* 60 h
+ (let ((clocked-time (org-clock-get-clocked-time)))
(if org-clock-effort
(let* ((effort-in-minutes
(org-duration-string-to-minutes org-clock-effort))
- (effort-h (floor effort-in-minutes 60))
- (effort-m (- effort-in-minutes (* effort-h 60)))
(work-done-str
(org-propertize
- (format org-time-clocksum-format h m)
+ (org-minutes-to-clocksum-string clocked-time)
'face (if (and org-clock-task-overrun (not org-clock-task-overrun-text))
'org-mode-line-clock-overrun 'org-mode-line-clock)))
- (effort-str (format org-time-clocksum-format effort-h effort-m))
+ (effort-str (org-minutes-to-clocksum-string effort-in-minutes))
Re: [O] [FR new exporter] NAME and label
Hello,
Rasmus writes:
> Hi,
>
> I rely on org-special-blocks.el to provide easy access to the LaTeX
> proof environment and such.
org-export.el supersedes org-special-blocks.el: don't use the latter.
> Up till now I have been placing LaTeX
> labels in them manually, but I would like to #+NAME them.
>
> Here's an example
> #+begin_src org
> * section two
> #+NAME:p1
> #+BEGIN_PROPOSITION
> 1+1=2
> #+END_PROPOSITION
>
> By [[p1]] ... #+end_src
>
> This results in
> #+begin_src latex
> \section{section two}
> \label{sec-1}
> \label{p1}
> \begin{proposition}
> 1+1=2
> \end{proposition}
>
> By \ref{p1} \ldots{}
> #+end_src
>
> Basically, I would like to have the label inside the proposition.
Indeed. That should now be the case.
> Also, I think it might be nicer to use \dots as oppose to \ldots, as
> it is slightly more intelligent.
I thought \dots was an alias for \ldots. Isn't there any drawback to
replace \ldots with \dots (i.e. when amsmath isn't used)?
Regards,
--
Nicolas Goaziou
Re: [O] subtree-export limitations
Nicolas Goaziou writes: > It might support "Property+" syntax, but it looks like this is > Babel-specific (no sign of such syntax in org.el, where property API is > defined). I will look into it (unless you want to do it). Well, scratch that: it already support :property+: syntax. I.e. try to export subtree with: * Test export :PROPERTIES: :export_latex_header: header1 :export_latex_header+: header2 :END: Test
[O] [FR new exporter] NAME and label
Hi,
I rely on org-special-blocks.el to provide easy access to the LaTeX
proof environment and such. Up till now I have been placing LaTeX
labels in them manually, but I would like to #+NAME them.
Here's an example
#+begin_src org
* section two
#+NAME:p1
#+BEGIN_PROPOSITION
1+1=2
#+END_PROPOSITION
By [[p1]] ...
#+end_src
This results in
#+begin_src latex
\section{section two}
\label{sec-1}
\label{p1}
\begin{proposition}
1+1=2
\end{proposition}
By \ref{p1} \ldots{}
#+end_src
Basically, I would like to have the label inside the proposition.
Also, I think it might be nicer to use \dots as oppose to \ldots, as
it is slightly more intelligent.
Thanks,
Rasmus
--
When in doubt, do it!
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Nicolas Goaziou writes:
>> I'm doing some stuff where the natural output of my tables are
>> matrices. I found a decent translation function here ¹. However,
>> I'm not very successful in making org use it.
>
> Using the new exporter, something like should replace any table using
> default environment (i.e. no special attribute) and without horizontal
> rules with bmatrix environment. It should also insert it in math mode
> automatically.
I didn't manage to get your (Nicolas') or my own attempt working
correctly for exporting matrices. I still think it would be nice.
I tried to use the regexp
(not (string-match "|[\\+-]+|" table))
to identify tables without heading separators, but it didn't work
properly.
Thinking about it, it might be nice to be able to specify table export
function more generally. For instance, I might have a matrix with
labels (in LaTeX a bordermatrix or kbordermatrix). Likewise, it might
also be nice to specify a header argument to tables s.t. I can specify
a name, e.g.
#+NAME: P
#+TBLOPTIONS: :prefix "P=" :type matrix
| a| b|
| c| d|
would export to
\[P=\begin{bmatrix}a&b\\c&d\end{bmatrix}\]
–Rasmus
--
May the Force be with you
Re: [O] Question re. Bernt's agenda setup
On Fri, Nov 16, 2012 at 6:39 PM, Memnon Anon wrote: > > Manish writes: > > > a way to > > pick out all #+begin_src parts from the .org version? > > (org-babel-tangle &optional ONLY-THIS-BLOCK TARGET-FILE LANG), > bound to `C-c C-v t' by default. > Not all emacs-lisp blocks are set to :tangle yes, though. > > Or use a quick Keyboard macro (info "(emacs)Keyboard Macros") . > Thank you. Last night I went through the .org version trimming it line-by-line. It was not efficient but it forced me to go slow and read carefully. It was so much more enlightening to see the workflow of an org expert. Midway through the file I realized that this _is_ the .emacs I was looking for. :-) =F12 SPC= with =V= is so much better at doing project reviews than anything else I have ever seen. My only gripe is that functions called by =V= and =P= do not refresh the agenda. I am trying to understand enough elisp to be able to call org-agenda-redo and beginning-of-buffer in some right places.. I am officially a fan now. Cheers! --Manish
Re: [O] subtree-export limitations
Hello, Philipp Kroos writes: > Anyway, I'm still curious if it wouldn't be feasible to treat > subtree-options more similar to inbuffer-options? It is feasible but it isn't consistent with Org mode properties. According to manual (section 7.1): Note that a property can only have one entry per Drawer. It might support "Property+" syntax, but it looks like this is Babel-specific (no sign of such syntax in org.el, where property API is defined). I will look into it (unless you want to do it). Regards, -- Nicolas Goaziou
Re: [O] source code disappears
Hi Andy, Andy Moreton writes: >> When I switch to the ELPA version ( "Org-mode version 7.9.2 >> (7.9.2-82-g2aeb28-elpa @ . . . )") this misbehavior is corrected. >> HTH. > > I've filed emacs bug#12905 about this, as it is occurring in on the > emacs-24 branch, and emacs 24.3 is getting close to release. > > Can somebody please update org mode in emacs to bring it up to date. I will take care of this before the end of the pretest week. Thanks, -- Bastien
Re: [O] subtree-export limitations
Ok, thanks to both of you. I'll stick with the workarounds pointed out by Alan for now. Anyway, I'm still curious if it wouldn't be feasible to treat subtree-options more similar to inbuffer-options? Maybe I'll have a look at that in some spare time, though I think my understanding of the concepts might be insufficient yet. Any further clues on this topic are much appreciated therfore! Best regards, Philipp Suvayu Ali writes: > On Fri, Nov 16, 2012 at 04:45:35PM +0100, Philipp Kroos wrote: >> >> So would be any other EXPORT_OPTIONS-line. The responsible function is >> org-export--get-subtree-options, which builds a list of already seen >> keywords. The lists members are then ignored if seen again. >> Is there any particular reason why this is done? >> > > Since Alan gave you a workaround, I will try to answer the why. I > believe the reason behind this behaviour is properties are not designed > to "accumulate" values. I believe there is a special case treatment for > certain babel uses; as I'm hazy on the details, you have to look in the > archives from about a year back (my memory tells me September 2011 to > December 2011). You should look for discussions involving Rainer(?) > and Eric Schulte. > > Hope this helps.
Re: [O] source code disappears
On Fri 16 Nov 2012, Neil Best wrote: > When I switch to the ELPA version ( "Org-mode version 7.9.2 > (7.9.2-82-g2aeb28-elpa @ . . . )") this misbehavior is corrected. > HTH. I've filed emacs bug#12905 about this, as it is occurring in on the emacs-24 branch, and emacs 24.3 is getting close to release. Can somebody please update org mode in emacs to bring it up to date. Thanks, AndyM
Re: [O] [BUG] centering export of babel results
Andreas Leha writes:
> Hi all,
>
> There is a bug in the newly introduced centering-instead-of-center
> feature when it comes to babel results.
>
> Here is the problem (already *unintentionally* centered):
> #+begin_src R :exports results :colnames yes
> data.frame(a=1:2, b=3:4)
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 3 |
> | 2 | 4 |
>
> This remains *unintentionally* centered.
>
> Regards,
> Andreas
I should have added, that a simple work-around would be sth like
Here is the problem (already *unintentionally* centered):
#+LaTeX: { \\%}
#+begin_src R :exports results :colnames yes
data.frame(a=1:2, b=3:4)
#+end_src
#+results:
| a | b |
|---+---|
| 1 | 3 |
| 2 | 4 |
#+LaTeX: }
This remains *unintentionally* centered.
Regards,
Andreas
[O] [BUG] centering export of babel results
Hi all, There is a bug in the newly introduced centering-instead-of-center feature when it comes to babel results. Here is the problem (already *unintentionally* centered): #+begin_src R :exports results :colnames yes data.frame(a=1:2, b=3:4) #+end_src #+results: | a | b | |---+---| | 1 | 3 | | 2 | 4 | This remains *unintentionally* centered. Regards, Andreas
Re: [O] Export to Confluence wiki format
Hello, Sébastien Delafond writes: > I've put together a somewhat crude confluence exporter that's based on > the new exporter (as of 7.9.2). For now it's hosted on github[1]. Thank you for your work. Do not hesitate to ask any technical question on the new export API. Also, if/when you feel it's ready, we can include it in Org contrib/ directory. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
Toby Cubitt writes:
> Here's an updated patch. Now both org-time-clocksum-format and
> org-time-clocksum-fractional-format can be plists, as discussed.
That was quick. Thank you.
> In the org-time-clocksum-format case, I made the values cons cells which
> specify both a format string and a boolean. The latter indicates whether
> the time component should always be included in the formatted duration,
> even if its value is 0. This is needed for the hours component to
> reproduce the current default format, and I figured I might as well make
> it general.
I understand. It is a necessary evil. Though, instead of asking for cons
cells, maybe the boolean could be provided as another property. I.e.
'(:hour "..." :persistent-hour t)
would be a replacement for:
'(:hour ("..." . t))
And, better,
'(:hour "...")
would the become a replacement for
'(:hour ("..." . nil))
What do you think about it? The name of the property is only
a suggestion.
> I used a somewhat complex customization type in the defcustoms, instead
> of a straight plist, in order to produce a better ui for the
> customization interface. I'm still not completely satisfied with it.
> E.g. it would be nice to get rid of the "Cons cell" tag entirely, and use
> a checkbox for the boolean. But I can't figure out how to do that
> (without defining new customization types/widgets, which I don't have the
> patience for).
The advantage of the method above it that it would /de facto/ get rid of
the "Cons cell" tag.
> + (org-add-props (concat (format "%s " (make-string l ?*))
> + (org-minutes-to-clocksum-string
> time)
> + (format "%s" (make-string (- 16 l)
> ?\ )))
You forgot to change that.
Regards,
--
Nicolas Goaziou
