[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
[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
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" 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
Re: [O] [PATH] Speedups to org-table-recalculate
Hello, Michael Brand 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] 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 wrote: > Hello, > > Teika Kazura 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] [bug] Link to filename beginning by a date opens... the agenda
Nick Dokos writes: > Nicolas Goaziou writes: > >> Hello, >> >> Sebastien Vauban >> 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 (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] [PATCH] inline src block results can be removed
"Charles C. Berry" 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: > : @@ > > 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 > 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))) >
Re: [O] [bug] Link to filename beginning by a date opens... the agenda
Nicolas Goaziou writes: > Hello, > > Sebastien Vauban > 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 (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] [PATH] Speedups to org-table-recalculate
Hi Nathaniel On Fri, Nov 14, 2014 at 7:00 PM, Nathaniel Flath 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
[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: http://www.gnu.org/software/emacs/";>Emacs 24.4.1 (http://orgmode.org";>Org 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
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 wrote: > Hi Nathaniel > > On Fri, Nov 14, 2014 at 2:33 PM, Nathaniel Flath > 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
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_[headers]{code} setups are also attached. Discussion inline below. On Thu, 13 Nov 2014, Nicolas Goaziou wrote: Hello, "Charles C. Berry" 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: : @@ 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 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)) @@ -2223,12 +2230
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Nathaniel On Fri, Nov 14, 2014 at 2:33 PM, Nathaniel Flath 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] [bug] Link to filename beginning by a date opens... the agenda
Hello, Sebastien Vauban 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] 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 > wrote: > >> Hello, >> >> Milan Zimmermann 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/)]
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 wrote: > Hello, > > Milan Zimmermann 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] Inline code :results replace not working
Maybe use `org-babel-default-inline-header-args'. On Thu, Nov 13, 2014 at 12:40 PM, Michael wrote: > > > Ista Zahn gmail.com> writes: > >> >> On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke > wisdomandwonder.com> wrote: >> > On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn gmail.com> > wrote: >> >> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry > 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
[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
[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
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 `o
Re: [O] [PATH] Speedups to org-table-recalculate
Aaaand another try. On Thu, Nov 13, 2014 at 12:39 AM, Michael Brand wrote: > Hi Nathaniel > > On Wed, Nov 12, 2014 at 12:51 PM, Nathaniel Flath > 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] How to input | in org tables
Hi, etimecowboy 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
[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] Repeated teaching classes and stopping date
On Friday, 14 Nov 2014 at 10:42, Samuel Loury wrote: > Eric S Fraga 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
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 writes: > Rasmus writes: > >> Nicolas Goaziou 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 . 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] 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] Repeated teaching classes and stopping date
Eric S Fraga 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] 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 writes: > Nicolas Goaziou 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] 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/)]
Nicolas Goaziou 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] Tangling src blocks to files as part of export
Michael Weylandt writes: >> On Nov 13, 2014, at 10:54 AM, Michael Weylandt >> 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: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] [RFC] Change property drawer syntax
Hello, 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 (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] 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 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