Re: [O] Org 8 Bug in interactive formula editing mode?
Hi, I confirm at least some variant of this. I start emacs using the command line emacs -Q -l .e2 with .e2 being: #+begin_src elisp (setq load-path (cons ~/.emacs.d/org-mode/lisp load-path)) (add-to-list 'auto-mode-alist '(\\.\\(org\\|org_archive\\|txt\\)$ . org-mode)) #+end_src org-mode version is git maint as of this morning. For my test file (attached) when I open the first headline and type C-c ' in one of the first table rows, I get shown the lines up to and including Dan. Now, as long, as I navigate in formulas concerning the visible rows, the table is visible in the org files buffer window and the fields used by the formula are highlighted. Now, when I go down to the first formula whose referenced field(s) are not visible, the cursor in the org file jumps to the end of the file which is then displayed at the upper end of the tabletest.org buffer window. In sufficient long org files the visible cursor jumps to the end of the org file buffer as soon as you navigate to a line with a formula in the *Edit Formulae* buffer window. PS: I've seen this for at least two weeks ago, but forgot about it again. Best regards Robert On 07/21/2014 09:36 PM, Thorsten Grothe wrote: New test: I set up a minimal .emcas only for orgmode like this: (package-initialize) (add-to-list 'load-path ~/.emacs.d/src/org-mode/lisp) (require 'org) (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (add-hook 'LaTeX-mode-hook 'orgtbl-mode) (add-hook 'message-mode-hook 'turn-on-orgtbl) My .emacs.d folder contains only the downloaded org files from git, same error :-) Regards Th. Grothe tabletest.org Description: Lotus Organizer
Re: [O] [bug?, org-element] latex-environment delimiters must be at BOL
Hello,
Rasmus ras...@gmx.us writes:
Thanks for your patch.
Turns out that I also had to modify the regexp in
org-element--current-element as this kicks off
org-element-latex-environment-parser (correct me if I am wrong).
Correct.
In the patch I define new regexps and use them everywhere.
Org-element.el seems to rather use spelled-out regexps. If desirable,
I can use this practice rather than defining new regexps.
IMO, the way to go would be to define regexps as constants everywhere in
org-element.el, but that would introduce duplicates with some
constants in org.el. IOW, there's no clear design about it. Situation
may change when the parser gets more integrated into core.
Meanwhile, it can't hurt to use constants in org-element.el.
[BTW: Is there a way to test performance systematically?]
I don't think so.
The change in org-element-paragraph-parser, namely using the mentioned
regexp, may be redundant.
That's fine by me.
This patch does not change the manual as I did not find any direct
discussion of newlines and LaTeX environments.
OK.
From f21ae57759ca5a1d4f19424c4eb0be8db4dcbfb5 Mon Sep 17 00:00:00 2001
From: Rasmus w...@pank.eu
Date: Fri, 18 Jul 2014 17:01:53 +0200
Subject: [PATCH] org-element.el: allow one-line LaTeX environments
Allow
* org-element.el (org-elment--latex-begin-environment,
org-element--latex-end-environment): New regexps identifying begining
and ending of LaTeX environment.
beginning
(org-element-latex-environment-parser, org-element-paragraph-parser,
org-element--current-element): use org-elment--latex-begin-environment
and org-element--latex-end-environment
Use and a full stop. Also, elment - element
* test-org-element.el (test-org-element/latex-environment-parser):
test for one-line LaTeX environments.
(test-org-element/latex-environment-parser): test different start tag
and end tag.
Add tests. is sufficient.
Latex Environment
+(defconst org-elment--latex-begin-environment
+ [ \t]*begin{\\([A-Za-z0-9*]+\\)}\\(\\[.*?\\]\\|{.*?}\\)*[ \t]*?
+ Holds regexp matching beginning of LaTeX environments.)
There should be a blank line below Latex Environment. Also, the
docstring should be Regexp matching
The regexp is wrong. It must start at the beginning of line. Also, you
can skip the optional part since you don't intend to analyze it.
^[ \t]*begin{\\([A-Za-z0-9*]+\\)}
Also, elment - element.
+
+(defconst org-element--latex-end-environment
+ [ \t]*end{%s}[ \t]*
+ Holds regexp matching ending of LaTeX environments.)
Likewise, the end of line is mandatory here, and the optional
whitespaces at the beginning of line not necessary.
end{%s}[ \t]*$
Note that it isn't a regexp per se, but a format string used to build
a regexp. Maybe the docstring should be explicit about this.
(let ((case-fold-search t)
(code-begin (point)))
- (looking-at [ \t]*begin{\\([A-Za-z0-9]+\\*?\\)})
- (if (not (re-search-forward (format ^[ \t]*end{%s}[ \t]*$
+ (looking-at org-elment--latex-begin-environment)
elment - element
;; Stop at valid latex environments.
- (and (looking-at
-[ \t]*begin{\\([A-Za-z0-9]+\\*?\\)})
+ (and (looking-at org-elment--latex-begin-environment)
elment - element
- ((looking-at
-[ \t]*begin{[A-Za-z0-9*]+}\\(\\[.*?\\]\\|{.*?}\\)*[ \t]*$)
+ ((looking-at org-elment--latex-begin-environment)
elment - element
Regards,
--
Nicolas Goaziou
Re: [O] François Pinard RIP
Nick Dokos ndo...@gmail.com writes: I just found out that François Pinard (author of org grep among other tools and frequent contributor to this list) died recently: https://plus.google.com/118038589019918324505/posts/DFuvYBrh4th From his interaction with this list François seemed like a great guy. RIP. —Rasmus -- Dobbelt-A
Re: [O] minted question
Manfred Lotz manfred.l...@arcor.de writes:
Hi Thomas,
On Mon, 21 Jul 2014 10:48:14 -1000
t...@tsdye.com (Thomas S. Dye) wrote:
Hi Manfred,
Manfred Lotz manfred.l...@arcor.de writes:
Hi Tom,
On Mon, 21 Jul 2014 09:53:41 -1000
t...@tsdye.com (Thomas S. Dye) wrote:
Aloha Manfred,
You should be able to use attr_latex (untested).
Manfred Lotz manfred.l...@arcor.de writes:
#+ATTR_LATEX: :options linenos=true frame=single
#+BEGIN_SRC perl
#! /usr/bin/perl
use strict;
use warnings;
use 5.010;
say 'hey';
#+END_SRC
Unfortunately, that doesn't work.
Yes, when I tried a slightly modified version here I got incorrect
LaTeX output:
\begin{minted}[,linenos=true, frame=single]{perl}
#! /usr/bin/perl
use strict;
use warnings;
use 5.010;
say 'hey';
\end{minted}
Note the extraneous comma in the optional argument before linenos.
I get what looks to be correct LaTeX export if I set options in the
variable org-latex-minted-options, as shown in the emacs-lisp code
block below.
#+ATTR_LATEX: :options linenos=true, frame=single
#+BEGIN_SRC perl
#! /usr/bin/perl
use strict;
use warnings;
use 5.010;
say 'hey';
#+END_SRC
#+begin_src emacs-lisp
(require 'ox-latex)
(add-to-list 'org-latex-packages-alist '( minted))
(setq org-latex-listings 'minted)
(setq org-latex-minted-options
'((linenos true) (frame single)))
#+end_SEC
Are you getting an extraneous comma with the #+attr_latex line?
All the best,
Tom
I do not get any extraneous comma. When using the #+attr_latex line
there is just nothing in the latex output.
Same here.
I'm also confused about the emacs-lisp code snippet. I only get it
working if I either put it into my .emacs or evaluate it in the scratch
buffer. The way you wrote it the lisp code shows up in my document.
I messed around with :results but to no avail.
Try putting it into its own :noexport: section (I also fixed the typo
below):
--8---cut here---start-8---
* Setup :noexport:
#+begin_src emacs-lisp
(require 'ox-latex)
(add-to-list 'org-latex-packages-alist '( minted))
(setq org-latex-listings 'minted)
(setq org-latex-minted-options
'((linenos true) (frame single)))
#+end_src
--8---cut here---end---8---
Nick
Re: [O] Org 8 Bug in interactive formula editing mode?
Now, when I go down to the first formula whose referenced field(s) are not visible, the cursor in the org file jumps to the end of the file which is then displayed at the upper end of the tabletest.org buffer window. In sufficient long org files the visible cursor jumps to the end of the org file buffer as soon as you navigate to a line with a formula in the *Edit Formulae* buffer window. I'm glad to hear that I'm not the only one who has this problem. I tested the file with the same result. Editing formulas works fine until line @4$4 see link with uploaded screenshot 1: http://www.zimagez.com/zimage/bildschirmfoto-22072014-100459.php from @5$4 to the end emacs jumps to the end of buffer see link with uploaded screenshot 2: http://www.zimagez.com/zimage/bildschirmfoto-22072014-100751.php Regards Th. Grothe
Re: [O] Org 8 Bug in interactive formula editing mode?
Robert Klein rokl...@roklein.de writes: I confirm at least some variant of this. I start emacs using the command line emacs -Q -l .e2 with .e2 being: #+begin_src elisp (setq load-path (cons ~/.emacs.d/org-mode/lisp load-path)) (add-to-list 'auto-mode-alist '(\\.\\(org\\|org_archive\\|txt\\)$ . org-mode)) #+end_src org-mode version is git maint as of this morning. For my test file (attached) when I open the first headline and type C-c ' in one of the first table rows, I get shown the lines up to and including Dan. Now, as long, as I navigate in formulas concerning the visible rows, the table is visible in the org files buffer window and the fields used by the formula are highlighted. I can't reproduce any of this. When I open the first headline I get the first section (Lorem ipsum ...): no table shown (partial or total). When I open the second headline headline, I get the table: all of it. C-c ' works. Now, when I go down to the first formula whose referenced field(s) are not visible, the cursor in the org file jumps to the end of the file which is then displayed at the upper end of the tabletest.org buffer window. In sufficient long org files the visible cursor jumps to the end of the org file buffer as soon as you navigate to a line with a formula in the *Edit Formulae* buffer window. PS: I've seen this for at least two weeks ago, but forgot about it again. This is from maint: Org-mode version 8.2.7b (release_8.2.7b-2-g798733 @ /home/nick/src/emacs/org/org-mode/lisp/) My suggestion would be to `make clean', `make autoloads' and try again: maybe there is some cruft in your tree that causes problems? Can anybody else reproduce this? Nick
[O] Repeat task a fixed number of times
This repeats an event on the first of the month forever: --8---cut here---start-8--- * Attend Monthly Meeting 2014-05-01 +1m --8---cut here---end---8--- How do I indicate that the event should be repeated monthly for 6 months only? Time-shift?
Re: [O] Org 8 Bug in interactive formula editing mode?
Thorsten Grothe i...@th-grothe.de writes: Now, when I go down to the first formula whose referenced field(s) are not visible, the cursor in the org file jumps to the end of the file which is then displayed at the upper end of the tabletest.org buffer window. In sufficient long org files the visible cursor jumps to the end of the org file buffer as soon as you navigate to a line with a formula in the *Edit Formulae* buffer window. I'm glad to hear that I'm not the only one who has this problem. I tested the file with the same result. Editing formulas works fine until line @4$4 see link with uploaded screenshot 1: http://www.zimagez.com/zimage/bildschirmfoto-22072014-100459.php from @5$4 to the end emacs jumps to the end of buffer see link with uploaded screenshot 2: http://www.zimagez.com/zimage/bildschirmfoto-22072014-100751.php OK, I can see the problem too: - make sure you have a sufficiently small frame (with Robert's test file, a frame of about 30 lines long should do it) - open the first headline - open the second headline with the table - navigate to somewhere inside the table - C-c ' - navigate among the formulas - see cursor jump in the original buffer between a row of the table and the end of the buffer If the frame is bigger than about 50 lines (so that after C-c ', it's big enough to show the whole table, including the formula and the empty line underneath it) then I don't see the problem. Nick
Re: [O] [bug?, org-element] latex-environment delimiters must be at BOL
Hi,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
IMO, the way to go would be to define regexps as constants everywhere in
org-element.el, but that would introduce duplicates with some
constants in org.el. IOW, there's no clear design about it. Situation
may change when the parser gets more integrated into core.
Sounds like an daunting, but worthwhile task.
Meanwhile, it can't hurt to use constants in org-element.el.
Good to know.
The attached patch hopefully addresses all of the issues you pointed
out. Sorry about those typos before!
Thanks,
Rasmus
--
Sådan en god dansk lagereddike kan man slet ikke bruge mere
From b34f2199a648f6eafd6917662ec0d6c56e12bc8b Mon Sep 17 00:00:00 2001
From: Rasmus ras...@gmx.us
Date: Fri, 18 Jul 2014 17:01:53 +0200
Subject: [PATCH] org-element.el: Allow one-line LaTeX environments
* org-element.el (org-element--latex-begin-environment,
org-element--latex-end-environment): New format strings to identify
beginning and ending of LaTeX environments.
(org-element-latex-environment-parser, org-element-paragraph-parser,
org-element--current-element): Use `org-element--latex-begin-environment'
and `org-element--latex-end-environment'.
* test-org-element.el (test-org-element/latex-environment-parser):
Add tests.
---
lisp/org-element.el | 29 ++---
testing/lisp/test-org-element.el | 22 +-
2 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 850ed94..147432e 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2084,6 +2084,23 @@ CONTENTS is nil.
Latex Environment
+(defconst org-element--latex-begin-environment
+ ^[ \t]*begin{\\([A-Za-z0-9*]+\\)}
+ ;; The following format string also matches optional arguments:
+ ;; ^[ \t]*begin{\\([A-Za-z0-9*]+\\)}\\(\\[.*?\\]\\|{.*?}\\)*[ \t]*?
+ Format string matching the beginning of a LaTeX environment.
+
+Usage example:
+ (format org-element--latex-begin-environment ENV)
+where ENV is a LaTeX environment.
+
+See also `org-element--latex-end-environment'.)
+
+(defconst org-element--latex-end-environment
+ end{%s}[ \t]*$
+ Format string matching the ending of a LaTeX environment.
+See also `org-element--latex-begin-environment'.)
+
(defun org-element-latex-environment-parser (limit affiliated)
Parse a LaTeX environment.
@@ -2100,8 +2117,8 @@ Assume point is at the beginning of the latex environment.
(save-excursion
(let ((case-fold-search t)
(code-begin (point)))
- (looking-at [ \t]*begin{\\([A-Za-z0-9]+\\*?\\)})
- (if (not (re-search-forward (format ^[ \t]*end{%s}[ \t]*$
+ (looking-at org-element--latex-begin-environment)
+ (if (not (re-search-forward (format org-element--latex-end-environment
(regexp-quote (match-string 1)))
limit t))
;; Incomplete latex environment: parse it as a paragraph.
@@ -2219,11 +2236,10 @@ Assume point is at the beginning of the paragraph.
(org-match-string-no-properties 1)))
limit t)))
;; Stop at valid latex environments.
- (and (looking-at
- [ \t]*begin{\\([A-Za-z0-9]+\\*?\\)})
+ (and (looking-at org-element--latex-begin-environment)
(save-excursion
(re-search-forward
- (format ^[ \t]*end{%s}[ \t]*$
+ (format org-element--latex-end-environment
(regexp-quote
(org-match-string-no-properties 1)))
limit t)))
@@ -3707,8 +3723,7 @@ element it has to parse.
(goto-char (car affiliated))
(org-element-keyword-parser limit nil))
;; LaTeX Environment.
- ((looking-at
- [ \t]*begin{[A-Za-z0-9*]+}\\(\\[.*?\\]\\|{.*?}\\)*[ \t]*$)
+ ((looking-at org-element--latex-begin-environment)
(org-element-latex-environment-parser limit affiliated))
;; Drawer and Property Drawer.
((looking-at org-drawer-regexp)
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 04ef1ce..0ca0f8a 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -1310,9 +1310,29 @@ e^{i\\pi}+1=0
(eq 'latex-environment
(org-test-with-temp-text \\begin{env}{arg}\nvalue\n\\end{env}
(org-element-type (org-element-at-point)
+ ;; Allow environments without newline after \begin{.}.
+ (should
+ (eq 'latex-environment
+ (org-test-with-temp-text \\begin{env}{arg}something\nvalue\n\\end{env}
+ (org-element-type (org-element-at-point)
+ ;; Allow one-line environments.
+ (should
+ (eq 'latex-environment
+ (org-test-with-temp-text \\begin{env}{arg}something\\end{env}
+ (org-element-type (org-element-at-point)
+ ;; Should not allow different tags.
+ (should-not
+ (eq 'latex-environment
+ (org-test-with-temp-text \\begin{env*}{arg}something\\end{env}
+(org-element-type (org-element-at-point)
+ ;; LaTeX environments must be on separate lines.
+ (should-not
+ (eq
Re: [O] Repeat task a fixed number of times
SabreWolfy sabrewo...@gmail.com writes: This repeats an event on the first of the month forever: * Attend Monthly Meeting 2014-05-01 +1m How do I indicate that the event should be repeated monthly for 6 months only? Time-shift? I think so: C-c C-x c (org-clone-subtree-with-time-shift) Nick
[O] A way to show time effort estimates in the org-clock-report
Is there a way to show time effort estimates in the org-clock-report? I found only that :properties (Effort) could be specified, but it does not work neither for one level, nor for summing children nodes' estimations. -- Alexander Artemenko (a.k.a. Svetlyak 40wt) Blog: http://dev.svetlyak.ru Jabber: svetlyak.4...@gmail.com
Re: [O] [PATCH] ox-latex.el: add out-of-the-box fontification for makefile source block
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Rainer M Krug rai...@krugs.de writes: THis patch adds out-of-the-box fontification of makefile source code blocks when using the package listings. As the makefile code blocks are named =makefile= and the name of the language definition in the package =listings= is m=make= the value (makefile make) is added to the variable org-latex-listings-langs. Thank you for the patch. Since you modify the default value of a defcustom, could you also add :version and :package-version keywords to the variable? See `org-latex-known-warnings' for an example. Will do so but only next week. Thanks, Rainer Regards, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgp0eICErZYVE.pgp Description: PGP signature
Re: [O] outorg edition of mails and drafts
On 2014-07-21 11:32, Thorsten Jolitz tjol...@gmail.com writes: These message-drafts are really redundant and a bit annoying, but I have no idea about the inner workings of gnus and doing , | C-h f gnus-draft- TAB | C-h v gnus-draft- TAB ` did not enlighten me any further. So I will ask on the gnus mailing list right now and report any helpful answers here. Thanks, I'll subscribe to that group as well and read the answers there. Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 pgpuFvvTCFudG.pgp Description: PGP signature
Re: [O] [bug?, org-element] latex-environment delimiters must be at BOL
Rasmus ras...@gmx.us writes:
The attached patch hopefully addresses all of the issues you pointed
out. Sorry about those typos before!
Thanks for the update. Some more comments below.
+(defconst org-element--latex-begin-environment
+ ^[ \t]*begin{\\([A-Za-z0-9*]+\\)}
I overlooked this in the previous patch. This regexp is not correct, as
it matches, e.g.
\begin{ab*cd}
A more accurate regexp is
^[ \t]*begin{\\([A-Za-z0-9]+\\*?\\)}
I realize that `org-element--current-element' is wrong here. I fixed it
in maint, which probably means that you will need to deal with a merge
conflict.
+ ;; The following format string also matches optional arguments:
+ ;; ^[ \t]*begin{\\([A-Za-z0-9*]+\\)}\\(\\[.*?\\]\\|{.*?}\\)*[ \t]*?
I think this comment is not necessary.
+ Format string matching the beginning of a LaTeX environment.
+
+Usage example:
+ (format org-element--latex-begin-environment ENV)
+where ENV is a LaTeX environment.
`org-element--latex-begin-environment' is not a format string.
`org-element--latex-end-environment' is.
You can remove this part. Add that the environment is put in group 1,
though.
Otherwise, the patch looks good. Feel free to apply it with suggested
changes.
Regards,
--
Nicolas Goaziou
Re: [O] François Pinard RIP
Rasmus ras...@gmx.us writes: Nick Dokos ndo...@gmail.com writes: I just found out that François Pinard (author of org grep among other tools and frequent contributor to this list) died recently: This is sad news. Somehow, whenever I had an idea for a *brandnew*, cooluseful little Org library and went ahead implementing it, it turned out that François had this idea before and already had implemented his own version of the library. This happened first when I announced Outorg, only to find out that he had announced Poporg a few weeks ago. Then someone requested a feature for Outshine that shows the number of hidden lines in folded headlines, which I implemented and then factored out as the small 'org-hlc.el' library (Org hidden-lines-cookies). Only to find out a bit later that there was 'org-weights.el' by - guess whom. The completely different implementations show that all these libraries were developed completely independently, but nevertheless - François was very kind and friendly all the time, not a sign of anger that somebody 'stole ideas' or 'doubled efforts' or so. It actually became a kind of internal joke between us that for whatever project I started, he already had an implementation in his back-catalogue, and I used to send him a PM first before starting a new project. While its normally a pretty frustrating thing to write a library that already exists, it turned out that our implementations complemented each other rather than competed with each other (see our joint article http://orgmode.org/worg/org-tutorials/org-outside-org.html on Worg). So nowadays I tend to use his Poporg (https://github.com/pinard/poporg) for editing doc-strings of functions and variables in Org-mode, and my own Outorg for editing whole subtrees and (outshine) buffers in Org-mode. Its sad that this extremely friendly competition between Org library writers cannot continue. RIP -- cheers, Thorsten
Re: [O] François Pinard RIP
Thorsten Jolitz tjol...@gmail.com writes: Rasmus ras...@gmx.us writes: Nick Dokos ndo...@gmail.com writes: I just found out that François Pinard (author of org grep among other tools and frequent contributor to this list) died recently: This is sad news. Somehow, whenever I had an idea for a *brandnew*, cooluseful little Org library and went ahead implementing it, it turned out that François had this idea before and already had implemented his own version of the library. This happened first when I announced Outorg, only to find out that he had announced Poporg a few weeks ago. Then someone requested a feature for Outshine that shows the number of hidden lines in folded headlines, which I implemented and then factored out as the small 'org-hlc.el' library (Org hidden-lines-cookies). Only to find out a bit later that there was 'org-weights.el' by - guess whom. The completely different implementations show that all these libraries were developed completely independently, but nevertheless - François was very kind and friendly all the time, not a sign of anger that somebody 'stole ideas' or 'doubled efforts' or so. It actually became a kind of internal joke between us that for whatever project I started, he already had an implementation in his back-catalogue, and I used to send him a PM first before starting a new project. While its normally a pretty frustrating thing to write a library that already exists, it turned out that our implementations complemented each other rather than competed with each other (see our joint article http://orgmode.org/worg/org-tutorials/org-outside-org.html on Worg). So nowadays I tend to use his Poporg (https://github.com/pinard/poporg) for editing doc-strings of functions and variables in Org-mode, and my own Outorg for editing whole subtrees and (outshine) buffers in Org-mode. Its sad that this extremely friendly competition between Org library writers cannot continue. Thanks for this, Thorsten.
Re: [O] Multi-line links
Nicolas, thank you for reply. Due to some health issues I’m only responding now. On So, 2014-07-06 at 21:28 +0200, Nicolas Goaziou wrote: Tobias Getzner tobias.getz...@gmx.de writes: If there is some strong reason for a hard-coded limit, would it be possible to expose the limit as a user-definable variable, and to fix the :path truncation issue? I don't think there is a strong reason for that limitation. RFC 3986 (Appendix C) suggests how to handle multi-lines URI. We could use it to handle such links. Note that there is more than org-element.el to change though (e.g., `org-make-link-regexps') and some parts of Org relying only on regexps to extract the path, may not work properly with such links. Do you want to work on such a patch? I’m afraid given my nigh complete inexperience with elisp it is unlikely I’ll be able to provide a good, generic solution for this. My original hope was that for someone familiar with the code, there wouldn’t be many changes needed, since multi-line descriptions seemed to be working (though only for 3 lines) and since the raw-path seemed to contain the needed line-breaks already. But if I understand you correctly, the complication is that the path parsing is the same across different link types, and so one cannot simply fix it up so that :path is equivalent to :raw-path, just with the link prefix stripped of? When I experimented with making multi-line BibTeX links work, I tried working around the issue of the path being truncated by using raw-path instead. But it seems that this breaks when doing export, since the handler seems to only be given the normal (truncated) path as an argument. Is there any way to make the exporter call the export handler with the raw-path as an argument, currently? Best regards, T.
Re: [O] [bug?, org-element] latex-environment delimiters must be at BOL
Hi,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
+(defconst org-element--latex-begin-environment
+ ^[ \t]*begin{\\([A-Za-z0-9*]+\\)}
I overlooked this in the previous patch. This regexp is not correct, as
it matches, e.g.
\begin{ab*cd}
A more accurate regexp is
^[ \t]*begin{\\([A-Za-z0-9]+\\*?\\)}
Note that the maint/master version of org-element--current-element
does not including a trailing ^. I
I realize that `org-element--current-element' is wrong here. I fixed it
in maint, which probably means that you will need to deal with a merge
conflict.
I'm not sure the location of stars matter much in a technical sense,
though I have never come across any environments using stars other
than for the last character.
This document compiles fine, although it is an exercise is obscurity:
\documentclass{minimal}
\newenvironment{ab*cd}[1]{\bfseries{#1}}{}
\newenvironment{*abcd}[1]{\bfseries{#1}}{}
\begin{document}
\begin{ab*cd} x \end{ab*cd}
\begin{*abcd} x \end{*abcd}
\end{document}
I'm happy to accept only stars in the end, though.
+ ;; The following format string also matches optional arguments:
+ ;; ^[ \t]*begin{\\([A-Za-z0-9*]+\\)}\\(\\[.*?\\]\\|{.*?}\\)*[ \t]*?
I think this comment is not necessary.
It's a nice regexp. . .
+ Format string matching the beginning of a LaTeX environment.
+
+Usage example:
+ (format org-element--latex-begin-environment ENV)
+where ENV is a LaTeX environment.
`org-element--latex-begin-environment' is not a format string.
`org-element--latex-end-environment' is.
True.
You can remove this part. Add that the environment is put in group 1,
though.
Otherwise, the patch looks good. Feel free to apply it with suggested
changes.
Sorry, I can't push to Org-git. But a patch is attached.
Thanks again,
Rasmus
--
This is the kind of tedious nonsense up with which I will not put
From fce1bff7789f90a9fa16cc318233166faf961a29 Mon Sep 17 00:00:00 2001
From: Rasmus ras...@gmx.us
Date: Tue, 22 Jul 2014 15:09:03 +0200
Subject: [PATCH] org-element.el: Allow one-line LaTeX environments
* org-element.el (org-element--latex-begin-environment,
org-element--latex-end-environment): New format strings to identify
beginning and ending of LaTeX environments.
(org-element-latex-environment-parser, org-element-paragraph-parser,
org-element--current-element): Use `org-element--latex-begin-environment'
and `org-element--latex-end-environment'.
* test-org-element.el (test-org-element/latex-environment-parser):
Add tests.
---
lisp/org-element.el | 23 +--
testing/lisp/test-org-element.el | 22 +-
2 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index bfbba5e..75fccc5 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2084,6 +2084,18 @@ CONTENTS is nil.
Latex Environment
+(defconst org-element--latex-begin-environment
+ ^[ \t]*begin{\\([A-Za-z0-9]+\\*?\\)}
+ Regexp matching the beginning of a LaTeX environment.
+The environment is captured by the first group.
+
+See also `org-element--latex-end-environment'.)
+
+(defconst org-element--latex-end-environment
+ end{%s}[ \t]*$
+ Format string matching the ending of a LaTeX environment.
+See also `org-element--latex-begin-environment'.)
+
(defun org-element-latex-environment-parser (limit affiliated)
Parse a LaTeX environment.
@@ -2100,8 +2112,8 @@ Assume point is at the beginning of the latex environment.
(save-excursion
(let ((case-fold-search t)
(code-begin (point)))
- (looking-at [ \t]*begin{\\([A-Za-z0-9]+\\*?\\)})
- (if (not (re-search-forward (format ^[ \t]*end{%s}[ \t]*$
+ (looking-at org-element--latex-begin-environment)
+ (if (not (re-search-forward (format org-element--latex-end-environment
(regexp-quote (match-string 1)))
limit t))
;; Incomplete latex environment: parse it as a paragraph.
@@ -2219,11 +2231,10 @@ Assume point is at the beginning of the paragraph.
(org-match-string-no-properties 1)))
limit t)))
;; Stop at valid latex environments.
- (and (looking-at
- [ \t]*begin{\\([A-Za-z0-9]+\\*?\\)})
+ (and (looking-at org-element--latex-begin-environment)
(save-excursion
(re-search-forward
- (format ^[ \t]*end{%s}[ \t]*$
+ (format org-element--latex-end-environment
(regexp-quote
(org-match-string-no-properties 1)))
limit t)))
@@ -3707,7 +3718,7 @@ element it has to parse.
(goto-char (car affiliated))
(org-element-keyword-parser limit nil))
;; LaTeX Environment.
- ((looking-at [ \t]*begin{\\([A-Za-z0-9]+\\*?\\)})
+ ((looking-at org-element--latex-begin-environment)
(org-element-latex-environment-parser limit affiliated))
;; Drawer and Property Drawer.
((looking-at org-drawer-regexp)
diff --git
Re: [O] org-redisplay-inline-images and export to HTML
Nick Dokos ndo...@gmail.com writes: I think you'd be better off with the tip that Rick Frankel posted in the same thread: #+BEGIN_SRC emacs-lisp (add-hook 'org-babel-after-execute-hook (lambda () (org-display-inline-images nil t))) #+END_SRC Thanks Nick (and Rick). I changed this to use the re version: #+BEGIN_SRC emacs-lisp (add-hook 'org-babel-after-execute-hook (lambda () (org-redisplay-inline-images))) #+END_SRC and it works great! -Brett. pgp_IbEYy8Wl6.pgp Description: PGP signature
Re: [O] org-redisplay-inline-images and export to HTML
Brett Viren b...@bnl.gov writes: Nick Dokos ndo...@gmail.com writes: I think you'd be better off with the tip that Rick Frankel posted in the same thread: #+BEGIN_SRC emacs-lisp (add-hook 'org-babel-after-execute-hook (lambda () (org-display-inline-images nil t))) #+END_SRC Thanks Nick (and Rick). I changed this to use the re version: #+BEGIN_SRC emacs-lisp (add-hook 'org-babel-after-execute-hook (lambda () (org-redisplay-inline-images))) #+END_SRC and it works great! It should work with the non-re version as well (and it is more efficient that way - particularly if you call it with refresh == t). Nick
Re: [O] org-mime-org-buffer-htmlize sending hangs ...
On 2014-07-21 19:45, Peter Davis p...@pfdstudio.com writes: Alas, despite years of emacs abuse, I have not managed to master even the rudiments of emacs lisp, and don't even know how to edebug. To get you started, you could try the following. - set up two emacs frames - in one frame, do a M-x describe-function then type the name of the function of interest (smtpmail-send-it iirc) - there will be a link to smtpmail.el, follow it - this will take you to the definition of the function, there type C-u C-M-x to tell emacs you want to edebug it - now in the other frame, do what you need to do to trigger the bug - when the function is called, you should see a small triangle in the fringe showing the point being executed. You can step through the different instructions by hitting space, and you will see in the echo area the results of the computations You can interrupt the debugging at any time by hitting 'q'. And if you no longer want to debug that function, hit C-M-x while in the function's source code, or restart emacs. Try it, it's fun! ;-) Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 pgpGDmMDt8dt5.pgp Description: PGP signature
Re: [O] org-mime-org-buffer-htmlize sending hangs ...
Alan Schmitt alan.schm...@polytechnique.org writes: On 2014-07-21 19:45, Peter Davis p...@pfdstudio.com writes: Alas, despite years of emacs abuse, I have not managed to master even the rudiments of emacs lisp, and don't even know how to edebug. To get you started, you could try the following. - set up two emacs frames - in one frame, do a M-x describe-function then type the name of the function of interest (smtpmail-send-it iirc) - there will be a link to smtpmail.el, follow it - this will take you to the definition of the function, there type C-u C-M-x to tell emacs you want to edebug it - now in the other frame, do what you need to do to trigger the bug - when the function is called, you should see a small triangle in the fringe showing the point being executed. You can step through the different instructions by hitting space, and you will see in the echo area the results of the computations You can interrupt the debugging at any time by hitting 'q'. And if you no longer want to debug that function, hit C-M-x while in the function's source code, or restart emacs. Try it, it's fun! ;-) This sounds like something even I could do! Thanks, Alan. I'll give it a shot. -pd
Re: [O] Org 8 Bug in interactive formula editing mode?
If the frame is bigger than about 50 lines (so that after C-c ', it's
big enough to show the whole table, including the formula and the empty
line underneath it) then I don't see the problem.
Thank you very much for your instructions!
yes you are right for the org file. I tested Roberts example with your
instructions and after resizing the formula frame a bit it works but
unfortunately this does not work with my attached tex file. For the first table
it works but for the two other tables it does not work even not if I try to
resize the formula window, so that I can see the whole table and the formula
line, sorry about that :-) I throws me to the end of the buffer again, funny
thing :-)
Regards
Th. Grothe\documentclass[%
fontsize=11pt,
fleqn,
parskip=half*,
toc=flat,
%DIV=15
]{scrartcl}
% Schriften
\usepackage{kpfonts}
%\usepackage{libertine}
% Optischer Randausgleich
%\usepackage{microtype}
% Datenbank
\usepackage[pointsonright,forcolorpaper,links,usexkv,
nospacetowork,useforms,allowrandomize,usecustomdesign,
cfg=datenbank,
% nosolutions
answerkey
]{eqexam}
\usepackage{atbdb}
%\vspacewithkeyOn
% Titel
\subject[Rewe]{Rechnungswesen}
\title[USt/VSt]{Umsatzsteuer}
\keywords{}
\author{Th. Grothe}
\begin{document}
\maketitle
\vspace{2cm}
\tableofcontents
\begin{exam}{ReweUS}{\large\bfseries\textcolor{blue}{Umsatzsteuer}}
\section{Umsatzsteuer}
\ID*{ATB_ee538a82_edb3_4526_a4b6_bb16d9ce3f1a}
\begin{problem*}[\auto]
\begin{parts}
\item\PTs{6} \ldots die folgenden Geschäftsfälle
\begin{orgtab}
\label{sec-umsatzsteuer}
#+TBLNAME: sec-umsatzsteuer
#+ORGTBL: SEND sec-umsatzsteuer orgtbl-to-latex :skip 2 :splice t :lend \\SThiderow
| Wert | UST/VST | gesamt |
|---+-+|
| 1 |1900 | 11900 |
| 2 |3800 | 23800 |
#+TBLFM: $2=round($1*19/100,2)::$3=$1+$2
$
\end{orgtab}
\begin{solution}\\
\begin{orgtab}
\label{sec-umsatzsteuer-3}
#+TBLNAME: sec-umsatzsteuer-3
#+ORGTBL: SEND sec-umsatzsteuer-3 orgtbl-to-latex :skip 2 :splice t
|| Kto | Soll | Haben |
|+---+---+---|
|| AW. Rohstoffe | 1 | |
|| Vorsteuer | 1900 | |
| an | Vall | | 11900 |
#+TBLFM: @2$3=remote(sec-umsatzsteuer,@2$1)::@3$3=remote(sec-umsatzsteuer,@2$2)::@4$4=remote(sec-umsatzsteuer,@2$3)
\label{sec-umsatzsteuer-5}
#+TBLNAME: sec-umsatzsteuer-5
#+ORGTBL: SEND sec-umsatzsteuer-5 orgtbl-to-latex :skip 2 :splice t :hline \\cmidrule(lr){2-2}
|| Kto| Soll | Haben |
|++---+---|
|| Bank | 23800 | |
| an | Umsatzerl. | | 2 |
| an | Umsatzst. | | 3800 |
#+TBLFM: @2$3=remote(sec-umsatzsteuer,@3$3)::@3$4=remote(sec-umsatzsteuer,@3$1)::@4$4=remote(sec-umsatzsteuer,@3$2)
\end{orgtab}
\end{solution}
\end{parts}
\end{problem*}
\endID
\end{exam}
\end{document}
Re: [O] minted question
Nick Dokos ndo...@gmail.com writes: Are you getting an extraneous comma with the #+attr_latex line? All the best, Tom I do not get any extraneous comma. When using the #+attr_latex line there is just nothing in the latex output. Same here. Then none of us gets the result noted in the manual. The latter allows to specify options relative to the package used to highlight code in the output (e.g., ‘listings’). This is the local counterpart to ‘org-latex-listings-options’ and ‘org-latex-minted-options’ variables, which see. #+ATTR_LATEX: :options commentstyle=\bfseries #+BEGIN_SRC emacs-lisp (defun Fib (n) ; Count rabbits. (if ( n 2) n (+ (Fib (- n 1)) (Fib (- n 2) #+END_SRC All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Org 8 Bug in interactive formula editing mode?
Thorsten Grothe i...@th-grothe.de writes: If the frame is bigger than about 50 lines (so that after C-c ', it's big enough to show the whole table, including the formula and the empty line underneath it) then I don't see the problem. Thank you very much for your instructions! yes you are right for the org file. I tested Roberts example with your instructions and after resizing the formula frame a bit it works but unfortunately this does not work with my attached tex file. For the first table it works but for the two other tables it does not work even not if I try to resize the formula window, so that I can see the whole table and the formula line, sorry about that :-) I throws me to the end of the buffer again, funny thing :-) I didn't mean that as a workaround. I meant it as a partial characterization of the problem that might give somebody in the know an idea of where to go looking for it. I believe that you'll have to live with the problem for a while: it might be easy to fix or it might be difficult but until somebody takes a deeper look, we won't know for sure. But IIUC, the problem is a display problem only: you don't see the table while you are editing the formulas, but once you finish and C-c C-c out of the formula editing buffer, everything should be updated properly (well, maybe the table needs to be recalculated - not sure whether that happens automatically or not - but the formulas *should* be updated to reflect your editing). Is my understanding correct? Nick
[O] Bug: [PATCH] Make org-narrow-to-subtree usable out of Org mode [8.2.7b (release_8.2.7b-6-g07d470 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Hello all,
org-narrow-to-subtree is very nice, and I now have C-x n s hard-wired
into my fingers, but it doesn't work when outline-regexp is too
different from org-outline-regexp in Outline-but-non-Org mode buffers.
It looked pretty easy to fix, so here is my suggestion, below. It should
be rather harmless since it only affects non-Org buffers (and might have
the nice side effect of allowing other commands to run in those buffers
-- but I haven't checked.)
From 70ccd90f98d07762d7ae228d67c387d674a69cee Mon Sep 17 00:00:00 2001
From: Nicolas Richard theonewiththeevill...@yahoo.fr
Date: Tue, 22 Jul 2014 18:29:00 +0200
Subject: [PATCH] Make org-get-limited-outline-regexp usable outside of org.
This allows org-narrow-to-subtree to function in Outline mode.
* lisp/org-macs.el (org-get-limited-outline-regexp): Use
outline-regexp instead of org-outline-regexp when not in Org mode.
---
lisp/org-macs.el | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 96265ec..78174df 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -352,11 +352,16 @@ point nowhere.
(defun org-get-limited-outline-regexp ()
Return outline-regexp with limited number of levels.
The number of levels is controlled by `org-inlinetask-min-level'
- (if (or (not (derived-mode-p 'org-mode)) (not (featurep 'org-inlinetask)))
- org-outline-regexp
-(let* ((limit-level (1- org-inlinetask-min-level))
- (nstars (if org-odd-levels-only (1- (* limit-level 2)) limit-level)))
- (format \\*\\{1,%d\\} nstars
+ (cond ((not (derived-mode-p 'org-mode))
+outline-regexp)
+ ((not (featurep 'org-inlinetask))
+org-outline-regexp)
+ (t
+(let* ((limit-level (1- org-inlinetask-min-level))
+ (nstars (if org-odd-levels-only
+ (1- (* limit-level 2))
+ limit-level)))
+ (format \\*\\{1,%d\\} nstars)
(defun org-format-seconds (string seconds)
Compatibility function replacing format-seconds.
--
2.0.2
[O] Agenda/report of all headlines with clocked time
Hi, I'm looking to develop an agenda or even a list that will report the following for a buffer Or for agenda-files: All headlines with time clocked for the specified time range, or without time clocked for specified time range IE by day or week Must include headlines without a TODO status The list in the *Clock Task Select* buffer is close, but not quite there Thanks! Subhan Michael Tindall Program Analyst - FamilyCare Health Plans 825 NE Multnomah St, Suite 1400; Portland OR 97232 Direct: 503-471-3127 Fax: 503-471-3177 Email: subh...@familycareinc.orgmailto:subh...@familycareinc.org [Email-Signature-Logos June 20143] This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you.
Re: [O] Org 8 Bug in interactive formula editing mode?
Nick Dokos ndo...@gmail.com writes: Thorsten Grothe i...@th-grothe.de writes: If the frame is bigger than about 50 lines (so that after C-c ', it's big enough to show the whole table, including the formula and the empty line underneath it) then I don't see the problem. Thank you very much for your instructions! yes you are right for the org file. I tested Roberts example with your instructions and after resizing the formula frame a bit it works but unfortunately this does not work with my attached tex file. For the first table it works but for the two other tables it does not work even not if I try to resize the formula window, so that I can see the whole table and the formula line, sorry about that :-) I throws me to the end of the buffer again, funny thing :-) BTW, I played with your file[fn:1] a bit and I can get around the problem by resizing the windows so that the file window is more than 100 lines and the formula editing window is about a dozen lines (I can get about 132 lines on a monitor rotated into portrait mode - even more by reducing the font size, but my eyes start complaining at around that point). So I'm pretty sure that the characerization stands: if the frame (and the file window) is big enough then the problem is not visible. Nick
Re: [O] Org 8 Bug in interactive formula editing mode?
I made some quick tests with different org versions; the first one I see this issue is git commit 30220ffcdcef45c0237f80a2347d4da19877f64a (release_8.2.6-77-g30220f). I don't see the patch causing this, yet; have to look further. Best regards Robert On 07/22/2014 09:01 PM, Nick Dokos wrote: Nick Dokos ndo...@gmail.com writes: Thorsten Grothe i...@th-grothe.de writes: If the frame is bigger than about 50 lines (so that after C-c ', it's big enough to show the whole table, including the formula and the empty line underneath it) then I don't see the problem. Thank you very much for your instructions! yes you are right for the org file. I tested Roberts example with your instructions and after resizing the formula frame a bit it works but unfortunately this does not work with my attached tex file. For the first table it works but for the two other tables it does not work even not if I try to resize the formula window, so that I can see the whole table and the formula line, sorry about that :-) I throws me to the end of the buffer again, funny thing :-) BTW, I played with your file[fn:1] a bit and I can get around the problem by resizing the windows so that the file window is more than 100 lines and the formula editing window is about a dozen lines (I can get about 132 lines on a monitor rotated into portrait mode - even more by reducing the font size, but my eyes start complaining at around that point). So I'm pretty sure that the characerization stands: if the frame (and the file window) is big enough then the problem is not visible. Nick
Re: [O] Org 8 Bug in interactive formula editing mode?
Robert Klein rokl...@roklein.de writes: I made some quick tests with different org versions; the first one I see this issue is git commit 30220ffcdcef45c0237f80a2347d4da19877f64a (release_8.2.6-77-g30220f). I don't see the patch causing this, yet; have to look further. Absolutely right, that looks like the culprit: , | commit 30220ffcdcef45c0237f80a2347d4da19877f64a | Author: Bastien Guerry b...@altern.org | Date: Thu Jun 12 12:04:24 2014 +0200 | | Prefer `set-window-start' over `recenter' in some places. | | * org-agenda.el (org-agenda-show-1): | * org-table.el (org-table-show-reference):this change | * org.el (org-fix-ellipsis-at-bol) | (org-first-headline-recenter): Use `set-window-start' instead | of `recenter'. | | * org-agenda.el (org-recenter-heading): Delete. ` -- Nick
Re: [O] Org 8 Bug in interactive formula editing mode?
Nick Dokos ndokos at gmail.com writes: Nope - I tried to reproduce it with latest (both master and maint) and could not, so I suspect an error in your configuration. I experience the same issue. http://article.gmane.org/gmane.emacs.orgmode/88610 /Luke
[O] bug in lisp code blocks
Greetings.
This is probably a bug:
#+BEGIN_SRC lisp :results output
(format t Hello world.)
;; comment after, causes crash when block is evaluated with C-c C-c
#+END_SRC
Debugger message:
#+BEGIN_QUOTE
end of file on #SB-IMPL::STRING-INPUT-STREAM {1003F862D3}
[Condition of type END-OF-FILE]
#+END_QUOTE
org-version: Org-mode version 8.3beta (release_8.3beta-51-g02f2d5 @
/home/mark/opt/org-mode/lisp)
Re: [O] Org 8 Bug in interactive formula editing mode?
Nick Dokos ndokos atzgmail.com writes: Can anybody else reproduce this? /me raises hand.
Re: [O] Org 8 Bug in interactive formula editing mode?
Nick Dokos ndo...@gmail.com writes: Robert Klein rokl...@roklein.de writes: I made some quick tests with different org versions; the first one I see this issue is git commit 30220ffcdcef45c0237f80a2347d4da19877f64a (release_8.2.6-77-g30220f). I don't see the patch causing this, yet; have to look further. Absolutely right, that looks like the culprit: , | commit 30220ffcdcef45c0237f80a2347d4da19877f64a | Author: Bastien Guerry b...@altern.org | Date: Thu Jun 12 12:04:24 2014 +0200 | | Prefer `set-window-start' over `recenter' in some places. | | * org-agenda.el (org-agenda-show-1): | * org-table.el (org-table-show-reference):this change | * org.el (org-fix-ellipsis-at-bol) | (org-first-headline-recenter): Use `set-window-start' instead | of `recenter'. | | * org-agenda.el (org-recenter-heading): Delete. ` The diff was , | diff --git a/lisp/org-table.el b/lisp/org-table.el | index 1d6bee0..6d649ab 100644 | --- a/lisp/org-table.el | +++ b/lisp/org-table.el | @@ -3863,9 +3863,10 @@ With prefix ARG, apply the new formulas to the table. | (push org-table-current-begin-pos org-show-positions) | (let ((min (apply 'min org-show-positions)) | (max (apply 'max org-show-positions))) | - (goto-char min) (recenter 0) | + (set-window-start (selected-window) (point-min)) | (goto-char max) | - (or (pos-visible-in-window-p max) (recenter -1 | + (or (pos-visible-in-window-p max) | + (set-window-start (selected-window) (point-max) |(select-window win | | (defun org-table-force-dataline () ` I suspect that instead of (point-min), it should be just min and instead of point-max, it should be just max (or possibly the beginning of the next line if it exists). Nick
Re: [O] Org 8 Bug in interactive formula editing mode?
I believe that you'll have to live with the problem for a while: it might be easy to fix or it might be difficult but until somebody takes a deeper look, we won't know for sure. Of course I can live with that, we are on open source here and here are many people like you doing a great big job!! It was only important for me to report this strange behavior :-) Regards Th. Grothe
[O] Test failure
I just pulled (HEAD is 02f2d5b42aabe9e272a5967ad0483b38750a8392)
and got this test failure:
,
| Test test-org-element/latex-environment-parser backtrace:
| (if (not (unwind-protect (setq value-102202 (apply fn-102200 args-10
| (let (form-description-102204) (if (not (unwind-protect (setq value-
| (let ((value-102202 (quote ert-form-evaluation-aborted-102203))) (le
| (let ((fn-102200 (function eq)) (args-102201 (list (quote latex-envi
| (lambda nil (let ((value-102183 (cl-gensym ert-form-evaluation-abor
| #[0 \306\307!r\211q\210\310\311\312\313\314\315!\316\\317\320%DC
| funcall(#[0 \306\307!r\211q\210\310\311\312\313\314\315!\316\\31
| ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
| #[0 r\304 q\210\305 )\306\307\310\311\312\313!\314\\315\316%DC\2
| funcall(#[0 r\304 q\210\305 )\306\307\310\311\312\313!\314\\315\
| ert-run-test([cl-struct-ert-test test-org-element/latex-environment-
| ert-run-or-rerun-test([cl-struct-ert--stats \\(org\\|ob\\) [[cl-st
| ert-run-tests(\\(org\\|ob\\) #[385 \306\307\\203D\211\211G\310
| ert-run-tests-batch(\\(org\\|ob\\))
| ert-run-tests-batch-and-exit(\\(org\\|ob\\))
| (let ((org-id-track-globally t) (org-test-selector (if org-test-sele
| org-test-run-batch-tests(\\(org\\|ob\\))
| eval((org-test-run-batch-tests org-test-select-re))
| command-line-1((--eval (setq vc-handled-backends nil org-startup-
| command-line()
| normal-top-level()
| Test test-org-element/latex-environment-parser condition:
| (ert-test-failed
| ((should-not
|(eq 'latex-environment
| (org-test-with-temp-text \\begin{env}{arg}
something\nvalue\n\\end{env} ...)))
| :form
| (eq latex-environment latex-environment)
| :value t))
|FAILED 282/523 test-org-element/latex-environment-parser
`
Nick
Re: [O] Org 8 Bug in interactive formula editing mode?
Can you please try this patch out and report whether it works or not and whether it causes any other problems? I'm not sure if Bastien is around to vet it, but if it seems to work for you, I can push it and deal with any other breakage later. --8---cut here---start-8--- diff --git a/lisp/org-table.el b/lisp/org-table.el index bfe396e..f19c027 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -3859,10 +3859,10 @@ With prefix ARG, apply the new formulas to the table. (push org-table-current-begin-pos org-show-positions) (let ((min (apply 'min org-show-positions)) (max (apply 'max org-show-positions))) - (set-window-start (selected-window) (point-min)) + (set-window-start (selected-window) min) (goto-char max) (or (pos-visible-in-window-p max) - (set-window-start (selected-window) (point-max) + (set-window-start (selected-window) max (select-window win (defun org-table-force-dataline () --8---cut here---end---8--- Thanks, Nick
Re: [O] Org 8 Bug in interactive formula editing mode?
Thorsten Grothe i...@th-grothe.de writes: I believe that you'll have to live with the problem for a while: it might be easy to fix or it might be difficult but until somebody takes a deeper look, we won't know for sure. Of course I can live with that, we are on open source here and here are many people like you doing a great big job!! It was only important for me to report this strange behavior :-) For which, many thanks (particularly for insisting: Luke Crook reported it a few days ago, but afaict, he didn't get any response - I don't even remember seeing his post). But as you must have seen elsewhere in the thread, Robert Klein identified the culprit and I posted a patch that, just possibly, solves this problem. Let me know what you find out. Thanks, Nick
Re: [O] Test failure
Hi Nick,
Nick Dokos ndo...@gmail.com writes:
I just pulled (HEAD is 02f2d5b42aabe9e272a5967ad0483b38750a8392)
and got this test failure:
,
| Test test-org-element/latex-environment-parser backtrace:
| (if (not (unwind-protect (setq value-102202 (apply fn-102200 args-10
| (let (form-description-102204) (if (not (unwind-protect (setq value-
| (let ((value-102202 (quote ert-form-evaluation-aborted-102203))) (le
| (let ((fn-102200 (function eq)) (args-102201 (list (quote latex-envi
| (lambda nil (let ((value-102183 (cl-gensym ert-form-evaluation-abor
| #[0 \306\307!r\211q\210\310\311\312\313\314\315!\316\\317\320%DC
| funcall(#[0 \306\307!r\211q\210\310\311\312\313\314\315!\316\\31
| ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
| #[0 r\304 q\210\305 )\306\307\310\311\312\313!\314\\315\316%DC\2
| funcall(#[0 r\304 q\210\305 )\306\307\310\311\312\313!\314\\315\
| ert-run-test([cl-struct-ert-test test-org-element/latex-environment-
| ert-run-or-rerun-test([cl-struct-ert--stats \\(org\\|ob\\) [[cl-st
| ert-run-tests(\\(org\\|ob\\) #[385 \306\307\\203D\211\211G\310
| ert-run-tests-batch(\\(org\\|ob\\))
| ert-run-tests-batch-and-exit(\\(org\\|ob\\))
| (let ((org-id-track-globally t) (org-test-selector (if org-test-sele
| org-test-run-batch-tests(\\(org\\|ob\\))
| eval((org-test-run-batch-tests org-test-select-re))
| command-line-1((--eval (setq vc-handled-backends nil org-startup-
| command-line()
| normal-top-level()
| Test test-org-element/latex-environment-parser condition:
| (ert-test-failed
| ((should-not
|(eq 'latex-environment
| (org-test-with-temp-text \\begin{env}{arg}
something\nvalue\n\\end{env} ...)))
| :form
| (eq latex-environment latex-environment)
| :value t))
|FAILED 282/523 test-org-element/latex-environment-parser
`
Nicolas removed the $ at the end of the regexps identifying LaTeX
environments here:
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=ec0e3cf70ba353ea59a5e66235462f659c99
There a current thread discussion of this behavior on this list called
something like:
[bug?, org-element] latex-environment delimiters...
I think tests are corrected in the patch in that thread.
—Rasmus
--
Hooray!
Re: [O] Test failure
Rasmus ras...@gmx.us writes: Nicolas removed the $ at the end of the regexps identifying LaTeX environments here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=ec0e3cf70ba353ea59a5e66235462f659c99 There a current thread discussion of this behavior on this list called something like: [bug?, org-element] latex-environment delimiters... I think tests are corrected in the patch in that thread. Good to know - thanks!
[O] [patch, ERT] emacs -q friendly interactive instructions
Hi, Here's a patch to the testing/README-documentation on the interactive part. I found that I had to do a couple of extra steps to run tests interactively from emacs -q. Thanks, Rasmus -- Hooray! From 1368f47b72e4a7f90888e5f3e6860afbee438cec Mon Sep 17 00:00:00 2001 From: Rasmus ras...@gmx.us Date: Fri, 18 Jul 2014 17:19:01 +0200 Subject: [PATCH] testing/README: Changes to Interactive testing * testing/README: Changes in Interactive testing instructions. --- testing/README | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/testing/README b/testing/README index c7e352b..34f6fcd 100644 --- a/testing/README +++ b/testing/README @@ -47,18 +47,26 @@ load and run the test suite with the following commands. (require 'org-test) #+END_SRC -2) Disable babel evaluation confirmation +2) Load required Babel languages #+BEGIN_SRC emacs-lisp - (setq org-confirm-babel-evaluate) + (org-babel-do-load-languages + 'org-babel-load-languages + (and + (mapc (lambda (lang) (add-to-list 'org-babel-load-languages (cons lang t))) + '(emacs-lisp shell org)) + org-babel-load-languages)) #+END_SRC -3) Then run the test suite, +3) Then run the test suite. Babel evaluation confirmation is disabled + and ~C-c C-c~ is enabled while running the tests. #+BEGIN_SRC emacs-lisp - (org-test-run-all-tests) + (let (org-babel-no-eval-on-ctrl-c-ctrl-c + org-confirm-babel-evaluate) + (org-test-run-all-tests)) #+END_SRC - or when a test fails run it interactively and investigate the - problem in the ERT results buffer. + When a test fails, run it interactively and investigate the problem + in the ERT results buffer. How to run one test: Use this as a demo example of a failing test -- 2.0.2
[O] Possible to use src block to generate org headlines for export?
I am attempting to use a babel code snippet to generate org headlines for export. However, I seem to be running into a corner case here. AFAICT, the only way to generate headlines safely with babel is to wrap them in a :RESULTS: drawer. Take the following example: --8---cut here---start-8--- #+BEGIN_SRC perl :export results :results output org drawer print * Headline One\n; print * Headline Two\n; print * Headline Three\n; #+END_SRC --8---cut here---end---8--- If I hit the source block, it creates wraps the output in a drawer. This protects the results, so when executing the source block again, babel correctly detects the drawer and replaces the output rather than multiplying it indefinitely, as it does with raw. --8---cut here---start-8--- #+RESULTS: :RESULTS: * Headline One * Headline Two * Headline Three :END: --8---cut here---end---8--- The problem with the results drawer is that org-element (and thus ox.el) does not recognize it as a drawer and thus includes :RESULTS: in the export. The html output looks like this: --8---cut here---start-8--- p :RESULTS: /p div id=outline-container-sec-1 class=outline-2 h2 id=sec-1span class=section-number-21/span Headline One/h2 /div div id=outline-container-sec-2 class=outline-2 h2 id=sec-2span class=section-number-22/span Headline Two/h2 /div div id=outline-container-sec-3 class=outline-2 h2 id=sec-3span class=section-number-23/span Headline Three/h2 div class=outline-text-2 id=text-3 /div /div /div --8---cut here---end---8--- In short, is there a more graceful and export-friendly way to use babel to generate org headlines for export? Or is there an easy way to get the export backend to delete the opening part of the drawer (i.e., :RESULTS:)? Any advice would be greatly appreciated. Thanks, Matt
Re: [O] Possible to use src block to generate org headlines for export?
Matt Lundin m...@imapmail.org writes: I am attempting to use a babel code snippet to generate org headlines for export. However, I seem to be running into a corner case here. AFAICT, the only way to generate headlines safely with babel is to wrap them in a :RESULTS: drawer. Take the following example: #+BEGIN_SRC perl :export results :results output org drawer print * Headline One\n; print * Headline Two\n; print * Headline Three\n; #+END_SRC If I hit the source block, it creates wraps the output in a drawer. This protects the results, so when executing the source block again, babel correctly detects the drawer and replaces the output rather than multiplying it indefinitely, as it does with raw. #+RESULTS: :RESULTS: * Headline One * Headline Two * Headline Three :END: The problem with the results drawer is that org-element (and thus ox.el) does not recognize it as a drawer and thus includes :RESULTS: in the export. The html output looks like this: p :RESULTS: /p div id=outline-container-sec-1 class=outline-2 h2 id=sec-1span class=section-number-21/span Headline One/h2 /div div id=outline-container-sec-2 class=outline-2 h2 id=sec-2span class=section-number-22/span Headline Two/h2 /div div id=outline-container-sec-3 class=outline-2 h2 id=sec-3span class=section-number-23/span Headline Three/h2 div class=outline-text-2 id=text-3 /div /div /div In short, is there a more graceful and export-friendly way to use babel to generate org headlines for export? Or is there an easy way to get the export backend to delete the opening part of the drawer (i.e., :RESULTS:)? Any advice would be greatly appreciated. No solace for your pain alas. See http://thread.gmane.org/gmane.emacs.orgmode/88557 My suggestion (as it was for Ronald, except that he had already rejected it :-) ) would be to use raw: you lose the idempotency of results production, but I don't know of any other problems. -- Nick
[O] Evaluating inline source blocks on export issue
Good evening, From [org-scraps] I pasted this example into a buffer: ,—- ━ #+name: square #+begin_src emacs-lisp :var it=0 (* it it) #+end_src Here is a call_square(it=4), stuck in the middle of some prose. ━ `—- When I export the buffer I get: ,—- ╭ │ (* it it) ╰ Here is a , stuck in the middle of some prose. `—- I expected a 16 to have appeared there. I did double check that inline call blocks work on export: ╭ │ (list org-export-babel-evaluate) ╰ #+NAME: | inline-only | Clearly I am missing something. What am I doing wrong here? My environment: ╭ │ (format %S (emacs-version)) ╰ #+NAME: #+begin_example GNU Emacs 24.3.1 (x86_64-apple-darwin13.2.0, Carbon Version 1.6.0 AppKit 1265.2) of 2014-07-03 on orion #+end_example ╭ │ (format %S (org-version)) ╰ #+NAME: #+begin_example 8.2.7a #+end_example Kind regards, gcr [org-scraps] https://raw.githubusercontent.com/eschulte/org-scraps/master/scraps.org
Re: [O] Possible to use src block to generate org headlines for export?
Nick Dokos ndo...@gmail.com writes: In short, is there a more graceful and export-friendly way to use babel to generate org headlines for export? Or is there an easy way to get the export backend to delete the opening part of the drawer (i.e., :RESULTS:)? Any advice would be greatly appreciated. No solace for your pain alas. See http://thread.gmane.org/gmane.emacs.orgmode/88557 My suggestion (as it was for Ronald, except that he had already rejected it :-) ) would be to use raw: you lose the idempotency of results production, but I don't know of any other problems. Thanks for the link. My ignorance of it shows how far behind I am on orgmode ML reading! I agree with Nicolas's argument that only headlines can contain headlines. That said, having the ability to generate org copy for export also seems useful. I wonder whether org-babel might take advantage of COMMENT headlines for org output: E.g. * COMMENT Here beginneth the results for code block named do-some-magic * COMMENT Here endeth the results for code block named do-some-magic Obviously, this could wreak havoc on ones outline structure, so some extra magic would be needed to set the correct headline level. However, since the headlines I'm generating are always at the end of the file, I've hacked my way to a solution with the following: --8---cut here---start-8--- #+BEGIN_SRC emacs-lisp :exports none :results none (save-excursion (goto-char (point-min)) (while (re-search-forward #\\+RESULTS: generate-blog-summary nil t) (beginning-of-line) (delete-region (point) (point-max #+END_SRC #+NAME: generate-blog-summary #+BEGIN_SRC perl :exports results :results output org raw print * Headline One\n; print * Headline Two\n; print * Headline Three\n; #+END_SRC --8---cut here---end---8--- Thus, each time I export, the emacs-lisp snippet nicely deletes the old results, making space for the new ones. Let's hope the real blog (when I get around to publishing it) is more interesting than the example above. ;) Best, Matt
Re: [O] Collecting unique selling proposition (USP) of Org-mode
Von: Karl Voit devn...@karl-voit.at Organisation: www.karl-voit.at Antworten an: Karl Voit news1...@karl-voit.at Datum: Tue, 1 Jul 2014 21:07:32 +0200 An: emacs-orgmode@gnu.org Betreff: Re: [O] Collecting unique selling proposition (USP) of Org-mode I think the best thing to compare different tools is making a list with features and mark which tools support which ones. I assume there is already such a list https://en.wikipedia.org/wiki/List_of_personal_information_managers OK, the list is there, but it is not comparing features directly. A very good example is the features comparison of docear with some of its alternatives: http://www.docear.org/2014/01/15/comprehensive-comparison-of-reference-manag ers-mendeley-vs-zotero-vs-docear/ Martin
Re: [O] Evaluating inline source blocks on export issue
Aloha Grant, Grant Rettke g...@wisdomandwonder.com writes: Good evening, From [org-scraps] I pasted this example into a buffer: ,—- ━ #+name: square #+begin_src emacs-lisp :var it=0 (* it it) #+end_src Here is a call_square(it=4), stuck in the middle of some prose. ━ `—- When I export the buffer I get: ,—- ╭ │ (* it it) ╰ To get rid of the source code block in the export buffer, you can put it under a heading that is tagged with :noexport:. I keep a heading at the end of most documents to hold source code blocks and find it convenient. Here is a , stuck in the middle of some prose. `—- I'm not certain if this will fix your problem (untested), but I set :results raw in this situation. I use properties for this so the call_foo() part stays a reasonable length: * Description of the Hawaiian Stone Axes :PROPERTIES: :RESULTS: raw :END: hth, Tom I expected a 16 to have appeared there. I did double check that inline call blocks work on export: ╭ │ (list org-export-babel-evaluate) ╰ #+NAME: | inline-only | Clearly I am missing something. What am I doing wrong here? My environment: ╭ │ (format %S (emacs-version)) ╰ #+NAME: #+begin_example GNU Emacs 24.3.1 (x86_64-apple-darwin13.2.0, Carbon Version 1.6.0 AppKit 1265.2) of 2014-07-03 on orion #+end_example ╭ │ (format %S (org-version)) ╰ #+NAME: #+begin_example 8.2.7a #+end_example Kind regards, gcr [org-scraps] https://raw.githubusercontent.com/eschulte/org-scraps/master/scraps.org -- Thomas S. Dye http://www.tsdye.com
Re: [O] Possible to use src block to generate org headlines for export?
Correction below... Matt Lundin m...@imapmail.org writes: #+BEGIN_SRC emacs-lisp :exports none :results none (save-excursion (goto-char (point-min)) (while (re-search-forward #\\+RESULTS: generate-blog-summary nil t) (when ... (beginning-of-line) (delete-region (point) (point-max #+END_SRC
