Re: [O] Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]
Hello, Milan Zimmermann milan.zimmerm...@gmail.com writes: Any of the strings in Ex 1) to Ex 4) below, even individually, including the extremely simple example 4, fails the export of the org file to latex and html. The failure appears to happen in the first step (converting to an intermediate format) *Steps to reproduce:* - Open a file containing any of the 4 examples (or this text named as org) - C-c C-e l L - Backtrace is attaches These type of strings on which the failure happens are not unusual to find in documents pasted from mysql or git. Thanks for your report. *Ex 1)* - real life example from git output which fails to export git pull origin master From github.com:airlift-group/cubifier \* branchmaster - FETCH_HEAD Updating 28d0c00..8d3abef Fast-forward grails-app/conf/Aaaa.groovy| 10 +- src/java/org/Bbbb.java | 19 +++ src/java/org/Cccc.java | 30 -- I don't get any error with this example. However, I suggest to wrap such things within a verbatim block, e.g., #+begin_example, so they don't interfere with Org syntax. *Ex 2)* - real life from Mysql output which fails to export (note the misalligned | in the data row - no issues when alligned) +---++---+ | label | long_label | isEnabled | +---++---+ | | 2 | | +---++---+ *Ex 3)* Simple example which fails to export ++--+ *Ex 4)* Simpliest example which fails to export + The three examples describe the same problem. Org has some support for table.el tables. However, it is very bad at recognizing them: both examples 3 and 4 are recognized as table.el tables. Worse, table.el is bad at recognizing table.el tables. Hence, example 2 is /almost/ a table.el table, but table.el itself fails to correctly recognize it. So, even if we improve Org to recognize them better (and there's definitely room for that), we cannot do better than the concerned library itself, which is not perfect either. IMO, it is worth pondering if we should drop the defective support for table.el tables in Org. In the meanwhile, you can also wrap this kind of output in a verbatim block or a fixed-width area. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Change property drawer syntax
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: After heavy testing (on all my Org files, I mean) of the above function, it works perfectly except for the following corner-case (when there are Org properties in quote blocks): * Reference Example of Custom ID: #+begin_verse ,* Some title :PROPERTIES: :CUSTOM_ID: SomeTitle :END: Lorem ipsum #+end_verse will be converted to: * Reference :PROPERTIES: :CUSTOM_ID: SomeTitle :END: Example of Custom ID: #+begin_verse ,* Some title Lorem ipsum #+end_verse upon execution of `org-repair-property-drawers'. Thanks for your feedback. Would the following updated function solve the problem? (defun org-repair-property-drawers () Fix properties drawers in current buffer. Ignore non Org buffers. (when (eq major-mode 'org-mode) (org-with-wide-buffer (goto-char (point-min)) (let ((case-fold-search t) (inline-re (and (featurep 'org-inlinetask) (concat (org-inlinetask-outline-regexp) END[ \t]*$ (org-map-entries (lambda () (unless (and inline-re (org-looking-at-p inline-re)) (save-excursion (let ((end (save-excursion (outline-next-heading) (point (forward-line) (when (org-looking-at-p org-planning-line-re) (forward-line)) (when (and ( (point) end) (not (org-looking-at-p org-property-drawer-re)) (save-excursion (re-search-forward org-property-drawer-re end t) (eq (org-element-type (save-match-data (org-element-at-point))) 'drawer))) (insert (delete-and-extract-region (match-beginning 0) (min (1+ (match-end 0)) end))) (unless (bolp) (insert \n PS- I did not retest (yet) the same thing in #+begin/end_src blocks... as playing with that example files makes my Emacs eat 100% of the CPU (infloop?). Could you provide an ECM for that? Regards, -- Nicolas Goaziou
Re: [O] Tangling src blocks to files as part of export
Michael Weylandt michael.weyla...@gmail.com writes: On Nov 13, 2014, at 10:54 AM, Michael Weylandt michael.weyla...@gmail.com wrote: Is it possible to have certain blocks tangled as part of export so that they are available as input files to later source blocks? E.g., #+BEGIN_SRC python :tangle hello.py print Hello World #+END_SRC #+BEGIN_SRC sh python hello.py #+END_SRC If I tangle before running, then the second code block will work; else, it fails because 'hello.py' is not found. [1] I can run tangle and export in a row (and I have my own function to do just that) but is there a native org way to do so? Adding org-babel-tangle to the org-export-before-processing-hook does the job, but I'd still be interested in knowing if there's a more official method. I think this is the more-or-less official way of doing it - that's what hooks are for: to do pre- and post-processing, which is exactly what you want to do. I like it actually. Do you set the hook as a file local variable, and if yes, how? Because this would be brilliant. Cheers, Rainer -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]
Nicolas Goaziou m...@nicolasgoaziou.fr writes: IMO, it is worth pondering if we should drop the defective support for table.el tables in Org. Fine with me. Last I checked I was not able to get the output of tabel.el tables to be satisfying (e.g. I think I gave up on having them follow booktabs when exporting to LaTeX). What are the advances of table.el? Multicolumns and multiline row? Thanks, Rasmus -- Send from my Emacs
Re: [O] Possible to recalculate tables automatically before exporting?
William Denton wrote: Is it possible to make tables recalculate automatically when exporting? In a file I'm working on now, I have a table with formulas that take two columns of numbers I enter and turn them into two columns of derived numbers. I had missed one line of data, so I entered it, but forgot to recalculate the table, so when I exported some numbers were missing. It was trivial to do by hand, of course, but I looked for a setting that would automate this and didn't see it. Did I overlook it, or is it not there? See https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00347.html Best regards, Fabrice -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]
Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: IMO, it is worth pondering if we should drop the defective support for table.el tables in Org. Fine with me. Last I checked I was not able to get the output of tabel.el tables to be satisfying (e.g. I think I gave up on having them follow booktabs when exporting to LaTeX). What are the advances of table.el? Multicolumns and multiline row? Basically, yes. Note that dropping support for table.el tables in Org doesn't mean it is impossible to add them in an Org buffer: these tables are pretty much major mode agnostic. However, M-q will fill them, C-c ' will not edit them and export will have to be done by hand, using features explained in table.el comments. Regards,
Re: [O] Repeated teaching classes and stopping date
Eric S Fraga e.fr...@ucl.ac.uk writes: On Thursday, 13 Nov 2014 at 11:44, Samuel Loury wrote: [...] and I use sticky agenda views to help avoid unnecessary regeneration. Wow, sticky agenda views are cool! I don't understand how the SD card speed is to be taken into account since org mode by default loads into emacs (and then in memory) all the org files prior to computing the agenda. Are you sure? I had the impression that my org files were not accessed until I asked for the agenda. But maybe they are in which case you are correct that the SD card doesn't matter. Actually, the first agenda generation appears to load all the buffers and next generations only use the existing buffers. Therefore, the SD card matters indeed for the first generation. -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A pgpC6DtalrLvJ.pgp Description: PGP signature
Re: [O] problem with auto-fill-mode in gnus with org
On Thursday, 13 Nov 2014 at 21:07, Nicolas Goaziou wrote: [...] Odd. I'm not able to reproduce it. Not surprising given the amount of customisation I have. Thanks for checking! However, using `org-auto-fill-function' without Org major mode may be asking for trouble (variables not initialized...). Indeed. I have come to same realisation and have turned this off. It's a pity as I found the org filling better than the default, especially for lists. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-558-g83d8a2
Re: [O] Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: IMO, it is worth pondering if we should drop the defective support for table.el tables in Org. Fine with me. Last I checked I was not able to get the output of tabel.el tables to be satisfying (e.g. I think I gave up on having them follow booktabs when exporting to LaTeX). What are the advances of table.el? Multicolumns and multiline row? Basically, yes. So multiline rows doesn't matter. We can collapse columns to not take up too much horizontal space in buffers via NUM. Long lines work out of the box in ox-html and can easily be had via e.g. p-columns in ox-latex. No idea about ox-ascii or ox-odt. Multicolumns would be very nice to have in Org-tables. I'm not at all how feasible this is, though. . . Thus, the only feature we'd lose by dropping tabel.el is multicolumns. Note that dropping support for table.el tables in Org doesn't mean it is impossible to add them in an Org buffer: these tables are pretty much major mode agnostic. Sure. Same with org-table... However, M-q will fill them, C-c ' will not edit them and Makes sense. export will have to be done by hand, using features explained in table.el comments. Meh, they don't follow org-export-· and org-BACKEND-· anyway (I checked this a while ago, maybe things changed). . . If the previous statement is correct, I don't know if Org really supports exporting them. . . Anyway, that's just my €0.02. —Rasmus -- If you can mix business and politics wonderful things can happen!
Re: [O] Repeated teaching classes and stopping date
On Friday, 14 Nov 2014 at 10:42, Samuel Loury wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: On Thursday, 13 Nov 2014 at 11:44, Samuel Loury wrote: [...] and I use sticky agenda views to help avoid unnecessary regeneration. Wow, sticky agenda views are cool! Indeed! And essential for org on slow devices and large files. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-558-g83d8a2
[O] How to input | in org tables
Hello, I want have a org table that contains symbole | in a table element. Org parses | as a field separator and add a new column. Is there any escape method from this. example: | 1 | 2 | 3 | | a | b | | | Cheers, Alan
Re: [O] How to input | in org tables
Hi, etimecowboy etimecow...@gmail.com writes: I want have a org table that contains symbole | in a table element. Org parses | as a field separator and add a new column. Is there any escape method from this. example: | 1 | 2 | 3 | | a | b | | | Maybe: |\vert| I don't know if there's a better way... —Rasmus -- A page of history is worth a volume of logic
Re: [O] [PATH] Speedups to org-table-recalculate
Aaaand another try. On Thu, Nov 13, 2014 at 12:39 AM, Michael Brand michael.ch.br...@gmail.com wrote: Hi Nathaniel On Wed, Nov 12, 2014 at 12:51 PM, Nathaniel Flath flat0...@gmail.com wrote: New patches attached! Now that they apply I found: + Re-applying formulas to full table...(line %d Missing cnt. + (message Re-applying formulas...done cnt)) Superfluous cnt. Michael 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data
Re: [O] [RFC] Change property drawer syntax
Hello Nicolas,
Nicolas Goaziou wrote:
Sebastien Vauban writes:
After heavy testing (on all my Org files, I mean) of the above function,
it works perfectly except for the following corner-case [...].
Thanks for your feedback. Would the following updated function solve the
problem?
(defun org-repair-property-drawers ()
Fix properties drawers in current buffer.
Ignore non Org buffers.
(when (eq major-mode 'org-mode)
(org-with-wide-buffer
(goto-char (point-min))
(let ((case-fold-search t)
(inline-re (and (featurep 'org-inlinetask)
(concat (org-inlinetask-outline-regexp)
END[ \t]*$
(org-map-entries
(lambda ()
(unless (and inline-re (org-looking-at-p inline-re))
(save-excursion
(let ((end (save-excursion (outline-next-heading) (point
(forward-line)
(when (org-looking-at-p org-planning-line-re)
(forward-line))
(when (and ( (point) end)
(not (org-looking-at-p org-property-drawer-re))
(save-excursion
(re-search-forward org-property-drawer-re end
t)
(eq (org-element-type
(save-match-data (org-element-at-point)))
'drawer)))
(insert (delete-and-extract-region
(match-beginning 0)
(min (1+ (match-end 0)) end)))
(unless (bolp) (insert \n
Nope, this one really breaks my Org file. For example:
--8---cut here---start-8---
#+TITLE: X Xx
#+AUTHOR: Xxx Xxx
#+EMAIL: x...@x.xxx
#+LANGUAGE: xx
#+FILETAGS: ::x:
* Xx
** Xxxx Xxx xxx xxx xxx - Xx xx xx xxx
2014-10-09 Thu 10:00
Xxx: Xxxx xx Xx (Xx XX).
* X
** CANX Xxxx xxx xx xxx ( Xx Xx Xxx)
DEADLINE: 2014-10-08 Wed
:LOGBOOK:
- X - [2014-10-09 Thu 18:18]
:END:
[2014-09-30 Tue 11:18]
#+BEGIN_VERSE
Xx x xx x xxx xx. Xxxx x xxx:
- Xxxx x xx xx
- Xx x xxx
- X x xxx
Xx xx , xx :
x Xx xxx xx xxx (xxx xx )
x Xxxx xxx xx xxx (xxx x xx x? ?…)
x Xxxx xxx xx 'x xx xx xxx?
x Xx x xx xxx
X xxx xx (x) xxx (x)?
#+END_VERSE
Xxxx [[http://orgmode.org][X Xx Xx Xxx: {xxx} Xxx: Xxxx x
xxx]]
--8---cut here---end---8---
becomes:
--8---cut here---start-8---
#+TITLE: X Xx
#+AUTHOR: Xxx Xxx
#+EMAIL: x...@x.xxx
#+LANGUAGE: xx
#+FILETAGS: ::x:
* Xx
** Xxxx Xxx xxx xxx xxx - Xx xx xx xxx
2014-10-09 Thu 10:00
Xxx: Xxxx xx Xx (Xx XX).
* X
ANX Xxxx xxx xx xxx ( Xx Xx Xxx)
DEADLINE: 2014-10-08 Wed
** C
:LOGBOOK:
- X - [2014-10-09 Thu 18:18]
:END:
[2014-09-30 Tue 11:18]
#+BEGIN_VERSE
Xx x xx x xxx xx. Xxxx x xxx:
- Xxxx x xx xx
- Xx x xxx
- X x xxx
Xx xx , xx :
x Xx xxx xx xxx (xxx xx )
x Xxxx xxx xx xxx (xxx x xx x? ?…)
x Xxxx xxx xx 'x xx xx xxx?
x Xx x xx xxx
X xxx xx (x) xxx (x)?
#+END_VERSE
Xxxx [[http://orgmode.org][X Xx Xx Xxx: {xxx} Xxx: Xxxx x
xxx]]
--8---cut here---end---8---
Observe that:
- many blank lines are added,
- the TODO keyword (CANX) is broken, and
- a new task is created.
PS- I did not retest (yet) the same thing in #+begin/end_src
blocks... as playing with that example files makes my Emacs eat 100%
of the CPU (infloop?).
Could you provide an ECM for that?
It really was just editing the given example. So, this file:
--8---cut here---start-8---
* Reference
Example of Custom ID:
#+begin_verse
,* Some title
:PROPERTIES:
:CUSTOM_ID: SomeTitle
:END:
Lorem ipsum
#+end_verse
--8---cut here---end---8---
caused me trouble with the initial `org-repair-property-drawers' added
to the `org-mode-hook'!?
Best regards,
Seb
--
Sebastien Vauban
[O] [bug] Link to filename beginning by a date opens... the agenda
Hello, Clicking on such a link: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][2014-11-12-PV.txt]] ... opens the Org agenda for that day -- while it should open my file, right? OTOH, a full link such as: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt]] is opened as expected. You can also notice that the link face is `org-date' on the first link. Best regards, Seb -- Sebastien Vauban
[O] language comparison framework
Hi all, I found a nice comparison of python, R and matlab[1]. This type of comparison is available for other domains as well[2]. Now the sources for these are on github[3]. The markup looks, erhm, unpleasant, i.e. hard to edit, unless you use wikidot[4] - which is what the author uses. Now I was wondering how easy / hard it would be to translate (a subset) of these to org-mode, since it would be much more comfortable to edit. By this I mean e.g. links from row titles to a glossary at the end, table code cells as verbatim, notes typographically different (italic and grey) etc. I do have crude macros and with a little manual tweaking, I can convert the tables to org-tables. This is tedious and I would appreciate any ideas on how you would automate the section linking and table-wide (or column-wide) typesetting instructions (see also my previous post[5]). Also, I am curious about whether someone already cooked up a home grown comparison framework in org-mode. Best Regards, Michael [1] http://hyperpolyglot.org/numerical-analysis [2] http://hyperpolyglot.org/ [3] https://github.com/clarkgrubb/hyperpolyglot [4] http://www.wikidot.com/ [5] http://permalink.gmane.org/gmane.emacs.orgmode/92246
Re: [O] Inline code :results replace not working
Maybe use `org-babel-default-inline-header-args'.
On Thu, Nov 13, 2014 at 12:40 PM, Michael giepe...@gmail.com wrote:
Ista Zahn istazahn at gmail.com writes:
On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke gcr at
wisdomandwonder.com wrote:
On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn istazahn at gmail.com
wrote:
On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry ccberry at
ucsd.edu wrote:
On Mon, 10 Nov 2014, Andreas Leha wrote:
[snip]
Nonetheless, from a literate programming perspective, I think that
replaceable (and raw) inline results are definitely desirable.
Regardless of the state of their implementation in orgmode right
now.
+1.
+1 from me as well. For exactly the reason Andreas illustrated I've
given up on using inline results for the past year or so. Would be
great to see this feature become usable by implementing a system for
replacing them.
My approach here has been to use hidden source blocks that aren't
exported but make it
really easy to see the result during development. These settings
should work on any configuration,
so I didn't include mine here.
✂✂
#+BEGIN_SRC R
a = 10
b = 23
c = a + b
#+END_SRC
#+BEGIN_SRC R :results output silent :exports none
c
#+END_SRC
The user calculated src_R{c}.
✂✂
When you use these functions
http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-
bindings-and-useful-functions
the addition of these hidden blocks hav almost zero cost and give me
what I want.
The problem I have is not that I miss being able to see results of the
inline block in the org-mode buffer. The problem is that I don't want
blocks to be evaluated on export (too time consuming in many cases).
So I turn that off, and either evaluate the blocks one at a time (I'm
aware of the dangers of this, not my point here) or call
org-babel-execute-buffer. Everytime I do that I get duplicate output
from inline code. As far as I can see inline code +
org-babel-execute-buffer is incompatible, which is why I gave up on
the former.
Best,
Ista
+1
First of all nice that something is happening on the issue - happy not to
be the only one missing something.
+ 1
on I also don't bother too much about the eval-on-export functionality as
long as I can evaluate the buffer and get non repeated inline results.
For now I don't use inline blocks anymore.
As an intermediate solution I would like to specify document wide options
for inline code blocks only (:results silent); sorry - cannot find the
example I saw on the net recently on how to do so. I could not get it
working.
I could set results silent argument in every inline src code but don't want
the inline source code to be too long unnecessarily (affects readability of
text).
--
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson
Re: [O] Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]
Hi Nicolas, Thanks for your answers. On the first example from Git - you are right this snippet exports correctly. I had a big file and after removing all tables, the export failed and I thought it pointed to the git section. But I cannot duplicate this now, I apologize for including this example. On the rest of examples that as you said are due to trying to recognize table.el tables: Personally I like the fact tables from Mysql (and perhaps other systems) can be pasted directly and in /most cases/ work through the table.el mechanism. If support for table.el is dropped, is there a way to convert table.el tables to org tables? imho, that would be really helpful precondition to dropping the table.el support. And thanks for the #begin/end_example pointer. Milan On Fri, Nov 14, 2014 at 3:30 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hello, Milan Zimmermann milan.zimmerm...@gmail.com writes: Any of the strings in Ex 1) to Ex 4) below, even individually, including the extremely simple example 4, fails the export of the org file to latex and html. The failure appears to happen in the first step (converting to an intermediate format) *Steps to reproduce:* - Open a file containing any of the 4 examples (or this text named as org) - C-c C-e l L - Backtrace is attaches These type of strings on which the failure happens are not unusual to find in documents pasted from mysql or git. Thanks for your report. *Ex 1)* - real life example from git output which fails to export git pull origin master From github.com:airlift-group/cubifier \* branchmaster - FETCH_HEAD Updating 28d0c00..8d3abef Fast-forward grails-app/conf/Aaaa.groovy| 10 +- src/java/org/Bbbb.java | 19 +++ src/java/org/Cccc.java | 30 -- I don't get any error with this example. However, I suggest to wrap such things within a verbatim block, e.g., #+begin_example, so they don't interfere with Org syntax. *Ex 2)* - real life from Mysql output which fails to export (note the misalligned | in the data row - no issues when alligned) +---++---+ | label | long_label | isEnabled | +---++---+ | | 2 | | +---++---+ *Ex 3)* Simple example which fails to export ++--+ *Ex 4)* Simpliest example which fails to export + The three examples describe the same problem. Org has some support for table.el tables. However, it is very bad at recognizing them: both examples 3 and 4 are recognized as table.el tables. Worse, table.el is bad at recognizing table.el tables. Hence, example 2 is /almost/ a table.el table, but table.el itself fails to correctly recognize it. So, even if we improve Org to recognize them better (and there's definitely room for that), we cannot do better than the concerned library itself, which is not perfect either. IMO, it is worth pondering if we should drop the defective support for table.el tables in Org. In the meanwhile, you can also wrap this kind of output in a verbatim block or a fixed-width area. Regards, -- Nicolas Goaziou
Re: [O] Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]
Please ignore my note about converting table.el to table. There is a C-c ~ . On Fri, Nov 14, 2014 at 10:51 AM, Milan Zimmermann milan.zimmerm...@gmail.com wrote: Hi Nicolas, Thanks for your answers. On the first example from Git - you are right this snippet exports correctly. I had a big file and after removing all tables, the export failed and I thought it pointed to the git section. But I cannot duplicate this now, I apologize for including this example. On the rest of examples that as you said are due to trying to recognize table.el tables: Personally I like the fact tables from Mysql (and perhaps other systems) can be pasted directly and in /most cases/ work through the table.el mechanism. If support for table.el is dropped, is there a way to convert table.el tables to org tables? imho, that would be really helpful precondition to dropping the table.el support. And thanks for the #begin/end_example pointer. Milan On Fri, Nov 14, 2014 at 3:30 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hello, Milan Zimmermann milan.zimmerm...@gmail.com writes: Any of the strings in Ex 1) to Ex 4) below, even individually, including the extremely simple example 4, fails the export of the org file to latex and html. The failure appears to happen in the first step (converting to an intermediate format) *Steps to reproduce:* - Open a file containing any of the 4 examples (or this text named as org) - C-c C-e l L - Backtrace is attaches These type of strings on which the failure happens are not unusual to find in documents pasted from mysql or git. Thanks for your report. *Ex 1)* - real life example from git output which fails to export git pull origin master From github.com:airlift-group/cubifier \* branchmaster - FETCH_HEAD Updating 28d0c00..8d3abef Fast-forward grails-app/conf/Aaaa.groovy| 10 +- src/java/org/Bbbb.java | 19 +++ src/java/org/Cccc.java | 30 -- I don't get any error with this example. However, I suggest to wrap such things within a verbatim block, e.g., #+begin_example, so they don't interfere with Org syntax. *Ex 2)* - real life from Mysql output which fails to export (note the misalligned | in the data row - no issues when alligned) +---++---+ | label | long_label | isEnabled | +---++---+ | | 2 | | +---++---+ *Ex 3)* Simple example which fails to export ++--+ *Ex 4)* Simpliest example which fails to export + The three examples describe the same problem. Org has some support for table.el tables. However, it is very bad at recognizing them: both examples 3 and 4 are recognized as table.el tables. Worse, table.el is bad at recognizing table.el tables. Hence, example 2 is /almost/ a table.el table, but table.el itself fails to correctly recognize it. So, even if we improve Org to recognize them better (and there's definitely room for that), we cannot do better than the concerned library itself, which is not perfect either. IMO, it is worth pondering if we should drop the defective support for table.el tables in Org. In the meanwhile, you can also wrap this kind of output in a verbatim block or a fixed-width area. Regards, -- Nicolas Goaziou
Re: [O] [bug] Link to filename beginning by a date opens... the agenda
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Hello, Clicking on such a link: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][2014-11-12-PV.txt]] ... opens the Org agenda for that day -- while it should open my file, right? OTOH, a full link such as: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt]] is opened as expected. You can also notice that the link face is `org-date' on the first link. I cannot reproduce it on 8.3beta. Regards, -- Nicolas Goaziou
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Nathaniel On Fri, Nov 14, 2014 at 2:33 PM, Nathaniel Flath flat0...@gmail.com wrote: Aaaand another try. I tested them and got an error because of a missing cnt: + (message Re-applying formulas to %d lines...done Michael
Re: [O] [PATCH] inline src block results can be removed
Nicolas,
More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el are
patched.
A few examples of how they render various src_lang[headers]{code} setups
are also attached.
Discussion inline below.
On Thu, 13 Nov 2014, Nicolas Goaziou wrote:
Hello,
Charles C. Berry ccbe...@ucsd.edu writes:
I like the flexibility that macros would allow.
I like it too. Macros are much better than export snippets for the task.
I don't think the usual #+MACRO works here, as the definition would be
found in `org-macro-templates' by the first call and existing stuff
would be expanded instead of being left for babel to remove it. But
setting it up as a document keyword should work, right?
Don't know if there are other gotchas.
Maybe a limited collection of formats could be set up to support basic
markup options and the macro could choose amongst them with a second
arg set by a babel header arg.
I think {{{results()}}} should remain a dumb wrapper itself and not try
to do some formatting (i.e., a simple, hard-coded macro). Formatting
should be on the side of Babel and, possibly, its arguments. Let's not
duplicate features.
Point taken.
Also, the user can customize org-babel-inline-result-wrap to always get
verbatim or otherwise wrap the contents of the macro.
I am not quite sure how to marry this to header args. Maybe the :wrap
header arg should be hijacked for inline src blocks to specify a macro
for the results.
Macro can be the default output. If you don't want a macro, use raw
header. IOW, there is no need for a specific header arg.
I mean, does anyone actually use stuff like src_R[:wrap latex]{1+2}?
The current result cannot be parsed as an export block, AFAICS.
It could evaluate to @@latex:3@@. Parsing can also be solved if
necessary.
`:wrap latex' results in @@latex: ... @@.
`:results latex' results in
: @@LaTeX:
: results@@
which is a bit unsightly, but can be parsed and removed.
I have not touched
- :RESULTS drawers
- lists
- tables
---
I appreciate your coaching/feedback.
Aaron Ecay's suggestion to use a macro was a good one. Thanks Aron.
Best,
Chuck
From b369b0a1e69fd2b91c8f4eb7d824dcd18232917b Mon Sep 17 00:00:00 2001
From: chasberry ccbe...@ucsd.edu
Date: Thu, 13 Nov 2014 20:45:01 -0800
Subject: [PATCH 1/3] lisp/ob-core.el: Replace inline `results' macro call or
export-snippet
* lisp/ob-core.el (org-babel-inline-result-wrap): Default is
{{{results(%s)}}}.
* lisp/ob-core.el (org-babel-insert-result): Delete any `results'
macro or export-snippet immediately following inline src block;
insert current value in 'results' macro or export snippet if :wrap
header argument is given. Escape commas in the result with
backslashes if the macro form is used.
* lisp/ob-core.el (org-babel-delete-babel-snippet): Add function to
delete {{{results(.*)}}} macro calls or @@backend:.*@@ provided
they follow inline src blocks. Adding extra spaces between an
export snippet and its inline src block will protect it from
removal.
---
lisp/ob-core.el | 49 +
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 6c38677..227c8f0 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -156,7 +156,7 @@ See also `org-babel-noweb-wrap-start'.
:group 'org-babel
:type 'string)
-(defcustom org-babel-inline-result-wrap =%s=
+(defcustom org-babel-inline-result-wrap {{{results(%s)}}}
Format string used to wrap inline results.
This string must include a \%s\ which will be replaced by the results.
:group 'org-babel
@@ -2136,8 +2136,9 @@ code the results are extracted in the syntax of the
source
(goto-char (match-end 0))
(insert (if (listp result) \n ))
(point
-(existing-result (unless inlinep
- (org-babel-where-is-src-block-result
+(existing-result (if inlinep
+ (org-babel-delete-babel-snippet)
+(org-babel-where-is-src-block-result
t info hash indent)))
(results-switches
(cdr (assoc :results_switches (nth 2 info
@@ -2216,6 +2217,12 @@ code the results are extracted in the syntax of the
source
((member file result-params)
(when inlinep (goto-char inlinep))
(insert result))
+;; escape commas, e.g. {{{results(a\,b)}}}
+((and inlinep
+ (equal '(replace) result-params)
+ (not (assoc :wrap (nth 2 info
+ (goto-char beg)
+ (insert (replace-regexp-in-string , \\, result nil t)))
(t (goto-char beg) (insert result)))
(when (funcall proper-list-p result) (goto-char
(org-table-end)))
(setq end (point-marker))
@@
Re: [O] [PATH] Speedups to org-table-recalculate
Bleh. Took out the wrong cnt, and that didn't show up in my testing for some reason. On Fri, Nov 14, 2014 at 11:10 PM, Michael Brand michael.ch.br...@gmail.com wrote: Hi Nathaniel On Fri, Nov 14, 2014 at 2:33 PM, Nathaniel Flath flat0...@gmail.com wrote: Aaaand another try. I tested them and got an error because of a missing cnt: + (message Re-applying formulas to %d lines...done Michael 0001-org-table.el-org-table-recalculate-early-returns(1).patch Description: Binary data 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data
[O] Problem with footnote in html export
Aloha all, With the following org file, exporting the subtree to html gives this: ,-- | org-html-footnote-reference: Format specifier doesn't match argument type `-- Here is the org file. To reproduce, move to `* Export subtree to html' then C-c C-e C-s h H: --- #+OPTIONS: html-link-use-abs-url:nil html-postamble:auto #+OPTIONS: html-preamble:t html-scripts:t html-style:t #+OPTIONS: html5-fancy:nil tex:t #+HTML_DOCTYPE: xhtml-strict #+HTML_CONTAINER: div #+HTML_LINK_HOME: #+HTML_LINK_UP: #+HTML_HEAD: #+HTML_HEAD_EXTRA: #+HTML_MATHJAX: #+INFOJS_OPT: #+CREATOR: a href=http://www.gnu.org/software/emacs/;Emacs/a 24.4.1 (a href=http://orgmode.org;Org/a mode 8.3beta) #+LATEX_HEADER: #+AUTHOR: Tom Dye[fn:1] * Export subtree to html Foo bar. * Footnotes [fn:1] The author. --- GNU Emacs 24.4.1 (x86_64-apple-darwin13.2.0, NS apple-appkit-1265.20) of 2014-10-22 on tennine-slave.macports.org Org-mode version 8.3beta (release_8.3beta-561-ge4195f @ /Users/dk/.emacs.d/src/org-mode/lisp/) 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] [PATH] Speedups to org-table-recalculate
Hi Nathaniel On Fri, Nov 14, 2014 at 7:00 PM, Nathaniel Flath flat0...@gmail.com wrote: Bleh. Took out the wrong cnt, and that didn't show up in my testing for some reason. In my opinion the newest patches can be applied, tests passed on my side. Thank you. Michael
Re: [O] [bug] Link to filename beginning by a date opens... the agenda
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Sebastien Vauban sva-n...@mygooglest.com writes: Hello, Clicking on such a link: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][2014-11-12-PV.txt]] ... opens the Org agenda for that day -- while it should open my file, right? OTOH, a full link such as: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt]] is opened as expected. You can also notice that the link face is `org-date' on the first link. I cannot reproduce it on 8.3beta. Clicking on it with a mouse button works but RET (bound to org-return) seems to do what Seb reports. And the face is indeed org-date, not org-link, but that's a different problem probably. Org-mode version 8.3beta (release_8.3beta-432-g2900f1 @ /home/nick/elisp/org-mode/lisp/) -- Nick
Re: [O] [PATCH] inline src block results can be removed
Charles C. Berry ccbe...@ucsd.edu writes:
More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
are patched.
Thanks.
Also, the user can customize org-babel-inline-result-wrap to always
get verbatim or otherwise wrap the contents of the macro.
I don't think this is a good idea.
If we rely on the macro recognition to properly inline results, setting
to anything else would break Org. It should be a defconst or we are
bound to shoot ourselves in the foot.
If a user wants verbatim output, he will have to somehow generate
{{{results:=output=}}}, e.g., through appropriate code or parameters.
`:wrap latex' results in @@latex: ... @@.
I was thinking to {{{results(@@latex:...@@)}}}. A bit more verbose, but
you can also replace :wrap latex results.
`:results latex' results in
: @@LaTeX:
: results@@
which is a bit unsightly, but can be parsed and removed.
It is important to remove the spurious newline character, as it could
break the surrounding structure.
I have not touched
- :RESULTS drawers
- lists
- tables
These have to be ignored. An inline element cannot generate a non-inline
element. At least, we shouldn't make it easy to do that. There are
plenty other ways to generate those.
From b369b0a1e69fd2b91c8f4eb7d824dcd18232917b Mon Sep 17 00:00:00 2001
From: chasberry ccbe...@ucsd.edu
Date: Thu, 13 Nov 2014 20:45:01 -0800
Subject: [PATCH 1/3] lisp/ob-core.el: Replace inline `results' macro call or
export-snippet
* lisp/ob-core.el (org-babel-inline-result-wrap): Default is
{{{results(%s)}}}.
As written earlier, I highly suggest to make it a defconst.
* lisp/ob-core.el (org-babel-insert-result): Delete any `results'
macro or export-snippet immediately following inline src block;
insert current value in 'results' macro or export snippet if :wrap
header argument is given. Escape commas in the result with
backslashes if the macro form is used.
You also need to escape backslash characters before commas, per
(info (org) Macro replacement)
* lisp/ob-core.el (org-babel-delete-babel-snippet): Add function to
delete {{{results(.*)}}} macro calls or @@backend:.*@@ provided
they follow inline src blocks. Adding extra spaces between an
export snippet and its inline src block will protect it from
removal.
With {{{results(@@backend:...@@)}}}, we don't need the extra trick. Even
if it is more verbose, I think a regular syntax is better.
+ ;; escape commas, e.g. {{{results(a\,b)}}}
Missing capital and final dot.
+ ((and inlinep
+(equal '(replace) result-params)
Spurious space.
+(not (assoc :wrap (nth 2 info
`assq'
(cond
((assoc :wrap (nth 2 info))
(let ((name (or (cdr (assoc :wrap (nth 2 info))) RESULTS)))
- (funcall wrap (concat #+BEGIN_ name)
- (concat #+END_ (car (org-split-string name))
+ (if inlinep
+ (funcall wrap (concat @@ name :) @@ nil t)
+ (funcall wrap (concat #+BEGIN_ name)
+(concat #+END_ (car (org-split-string
name)))
((member html result-params)
- (funcall wrap #+BEGIN_HTML #+END_HTML))
- ((member latex result-params)
- (funcall wrap #+BEGIN_LaTeX #+END_LaTeX))
+ (if inlinep
+ (funcall wrap @@HTML: @@)
+ (funcall wrap #+BEGIN_HTML #+END_HTML)))
+ ((member latex result-params)
+ (if inlinep
+ (funcall wrap @@LaTeX: @@)
I'd rather have back-end names lowercase @@html:...@@ and @@latex:...@@
even though they are case insensitive anyway.
Also, you can avoid repeating funcall wrap:
(apply wrap (if inlinep '(@@latex: @@) '(#+begin_latex #+end_latex)))
+(defun org-babel-delete-babel-snippet (optional info)
+ When point is in an inline src block, delete an export-snippet
+or `results' macro call just after it. To protect export snippets
+from removal, add extra spaces between the src block and the
+snippet.
+ (let ((location (org-babel-where-is-src-block-result nil info)))
+(when location
+ (save-excursion
+ (goto-char location)
+ (cond
+ ((looking-at \\([ ]\\{1,2\\}\\)\\(@\\))
+ (goto-char (match-end 1))
+ (let ((export-snippet (org-element-export-snippet-parser)))
Don't call dedicated parser functions directly. The public functions are
`org-element-at-point' and `org-element-context'.
Anyway, this is not useful if we don't write directly export snippets.
+(if export-snippet
+(let ((start (org-element-property :begin export-snippet))
+ (end (org-element-property :end export-snippet)))
+ (delete-region start end)
+ ((looking-at
Re: [O] [bug] Link to filename beginning by a date opens... the agenda
Nick Dokos ndo...@gmail.com writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Sebastien Vauban sva-n...@mygooglest.com writes: Hello, Clicking on such a link: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][2014-11-12-PV.txt]] ... opens the Org agenda for that day -- while it should open my file, right? OTOH, a full link such as: [[file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt][file:~/Projects/Type/Client/Folder/2014-11-12-PV.txt]] is opened as expected. You can also notice that the link face is `org-date' on the first link. I cannot reproduce it on 8.3beta. Clicking on it with a mouse button works but RET (bound to org-return) seems to do what Seb reports. And the face is indeed org-date, not org-link, but that's a different problem probably. Org-mode version 8.3beta (release_8.3beta-432-g2900f1 @ /home/nick/elisp/org-mode/lisp/) And org-return-follows-link is set to t in my case.
Re: [O] Bug (regression) in org-replace-disputed-keys. Bisected.
Hi all, I rather like that `org-read-date` takes over windmove keys during the second or two that I'm using it. By reverting this, I guess I'll have to copy and paste the whole `defvar` just to add `(org-replace-disputed-keys nil)`. May I make a compromise here? Can we make a new defcustom (org-disable-disputed-keys-during-read-date?) that will disable `org-replace-disputed-keys` when setting up `org-read-date-minibuffer-local-map`? Regards, Miro On Mon, Nov 3, 2014 at 9:54 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hello, Teika Kazura te...@gmx.com writes: Now a real fix. There're two candidates: (i) Revert the wrong commit. Since it was in fact done in two separate commits[2], you need another patch, not git-revert. Here it is: diff -u -r org-8.2.7c-orig/lisp/org.el org-8.2.7c/lisp/org.el --- org-8.2.7c-orig/lisp/org.el 2014-09-30 18:10:54.485977061 +0900 +++ org-8.2.7c/lisp/org.el2014-09-30 18:11:24.293602328 +0900 @@ -16220,8 +16220,7 @@ (defvar org-read-date-inactive) (defvar org-read-date-minibuffer-local-map - (let* ((org-replace-disputed-keys nil) - (map (make-sparse-keymap))) + (let* ((map (make-sparse-keymap))) (set-keymap-parent map minibuffer-local-map) (org-defkey map (kbd .) (lambda () (interactive) I think this change is appropriate. Could you provide a patch with git format-patch? Regards, -- Nicolas Goaziou
Re: [O] [PATH] Speedups to org-table-recalculate
Hello, Michael Brand michael.ch.br...@gmail.com writes: In my opinion the newest patches can be applied, tests passed on my side. Thank you. Thanks. However, I get compilation errors, probably due to the macro `org-table-execute-once-per-second'. In particular, using multiple ,t1 isn't a good idea. BTW, Nathaniel, these patches are no tiny changes. Have you signed FSF papers yet? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] inline src block results can be removed
Hi Chuck, Hi Nicolas,
I had a response to Chuck’s earlier message that was sitting around
waiting to be finished...time marches on however. Apologies. I think
the following bit is the only part that’s potentially still relevant:
I don't think the usual #+MACRO works here, as the definition would be
found in `org-macro-templates' by the first call and existing stuff would
be expanded instead of being left for babel to remove it.
I see what you mean. One option might be to do the following in
org-export-as (untested pseudocode):
(org-macro-initialize-templates)
(let (results-macro)
(setq results-macro (assoc results org-macro-templates))
(setq org-macro-templates (remove results-macro org-macro-templates))
(org-macro-replace-all org-macro-templates)
(org-export-execute-babel-code)
(org-macro-replace-all (list (or results-macro
(cons results
org-default-result-macro) ;; new
defcustom or defvar
Back to the present:
2014ko azaroak 14an, Nicolas Goaziou-ek idatzi zuen:
Charles C. Berry ccbe...@ucsd.edu writes:
More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
are patched.
Thanks.
Also, the user can customize org-babel-inline-result-wrap to always
get verbatim or otherwise wrap the contents of the macro.
I don't think this is a good idea.
If we rely on the macro recognition to properly inline results, setting
to anything else would break Org. It should be a defconst or we are
bound to shoot ourselves in the foot.
If a user wants verbatim output, he will have to somehow generate
{{{results:=output=}}}, e.g., through appropriate code or parameters.
This is a step back from the present situation, where a user can get
a custom format applied by default to all inline results by setting
‘org-babel-inline-result-wrap’. I think it’s reasonable for users to
want to set off babel results in a special font (to indicate that
they are automatically generated, e.g.) This proposal would add an
additional overhead for generating this formatting to every inline
call.
I think the method I sketched above will allow users to redefine the
results macro in the same way as any other macro (via #+MACRO), thus
allowing the possibility of user-specified special formatting.
[...]
* lisp/ob-core.el (org-babel-inline-result-wrap): Default is
{{{results(%s)}}}.
As written earlier, I highly suggest to make it a defconst.
Indeed, this seems correct. (The “const” designation is just a hint to
users/developers – it doesn’t affect the ability of people who really
want to customize the value to setq it to something else in their init
file.)
With {{{results(@@backend:...@@)}}}, we don't need the extra trick. Even
if it is more verbose, I think a regular syntax is better.
This doesn’t mesh with the suggestion to allow the results macro to
supply formatting.
--
Aaron Ecay
[O] Coursera class on reproducible research
Thought this might interest the list: - https://www.coursera.org/course/repdata I've taken other Johns Hopkins classes on Data Analysis from Rober Peng and Jeff Leek and found them to be pretty good. They'll be using R, and I'm going to guess they'll be teaching this withing the context of RStudio, though I could be wrong. I obviously use Org, however I plan on at least skimming the lectures for principles/best-practices, as I think they may help in my own efforts to use Org for reproducible research. I guess technically I'm not really publishing anything other than in my company, so oftentimes I'm simply trying to make my reports/analyses reproducible for *my future self*! In any case, just wanted to pass it along as I know there are others who implement these principles in their work on the ML. Best regards, John
[O] project-explorer package forcing new frame... better solution than mine?
Hi, I'm trying the project-explorer package. It uses a persistent window for a browsing tree. This causes a new frame when using any of org-export-dispatch, org-agenda-view menu, ibuffer-other-window, and org-insert-link. (My C-c C-e, C-c C-a, C-x C-b, C-c C-l.) I've made a solution for the export-dispatch (since I use project-explorer and org-export quite a bit for my Jekyll site). The solution is as follows: #+BEGIN_SRC emacs-lisp (add-hook 'project-explorer-mode-hook (lambda () (make-variable-frame-local 'org-export-dispatch-use-expert-ui) (modify-frame-parameters nil '((org-export-dispatch-use-expert-ui . t) #+END_SRC The author of project-explorer asserts that this may be a problem with Org-mode or Emacs. Since this also appears with ibuffer-other-window, is this necessarily worth mentioning to the Emacs newsgroup? Any ideas on a simpler solution than mine? -- Brady
