Re: [O] Math formatting in HTML export - The Org Manual
Have a look at the following variable and note the SNIPPET argument:
,[ C-h v org-latex-packages-alist RET ]
| org-latex-packages-alist is a variable defined in `org.el'.
| Its value is (("" "xcolor")
| ("" "tikz")
| ("" "listings")
| ("version=3" "mhchem")
| ("" "amsmath" t))
|
| Original value was nil
|
| Documentation:
| Alist of packages to be inserted in every LaTeX header.
|
| These will be inserted after `org-latex-default-packages-alist'.
| Each element is either a cell or a string.
|
| A cell is of the format:
|
| ("options" "package" SNIPPET-FLAG)
|
| SNIPPET-FLAG, when non-nil, indicates that this package is also
| needed when turning LaTeX snippets into images for inclusion into
| non-LaTeX output.
|
| A string will be inserted as-is in the header of the document.
|
| Make sure that you only list packages here which:
|
| - you want in every file;
| - do not conflict with the setup in `org-format-latex-header';
| - do not conflict with the default packages in
| `org-latex-default-packages-alist'.
|
| You can customize this variable.
`
--
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)
[O] What about a TOC export filter?
Hi List, in a derived backend it would be OK to let the parent backend (html) export the TOC, but I need to post-process the exported html (wrap it in extra code). Since I did not find suitable functionality for this, I use a kind of workaround: 1. disable default with option toc:nil 2. put a #+TOC: headlines 2 line 3. copy and adapt (i.e. overwrite) the org-html-keyword transcoder but wouldn't a toc-filter make more sense? Did I miss it? -- cheers, Thorsten
Re: [O] export to odt: error in style.xml
Hi, Achim Gratz writes: > Rasmus writes: >>> Could you please rebase or cherry-pick your changes onto the >>> then-current master before committing them? >> However, can you please elaborate on what exactly I did wrong? I have >> checked for the following to understand your criticism: >> >> 1. When I do $ git diff 004332b^ 00433b I get a one line diff (except >> the context). There are no change of white space or other garbage. >> Why is this not cherry-picked? > […] > > This one is, but your earlier commits introduced half a dozen Let's be clear, there are *two* redundant merges. > spurious merges since they were all started at different points on > master. I fail to see the relevance of your remark. >> In principal it is true. However, is it a real issue¹ in practice? > > The script that generates the ChangeLog for the Emacs merge will list > all of these separately and Bastien or who else is doing the merge will > have to manually put them back together. Thanks. I will be more careful on this. Bastien writes: >> I was asking no such thing, only that the author name and email you use >> for your commits are always one and the same. > > Yes: it's important to use the same name and address so that we can > group changelogs under the same person when adding them to Emacs. Thanks. Which file is grouped by author? Looking quickly at ORG-NEWS, it doesn't seem to be grouped by author? Anyway —Rasmus -- C is for Cookie
Re: [O] Sharing: Agenda skip function to remove future-scheduled items
James Harkins wrote: > [...] I realized that I didn't want to see items that are scheduled > for the future, because this is my agenda view for "what tasks are > available right now." For example, if I have a task to update my grade > sheet, it doesn't make sense to do that before I've taught the > lessons -- so I don't want to see the task until it's actually due. > > I didn't find a straightforward way to use a property search such as > "scheduled is nil or scheduled > today," but I did (with some false > starts) hack up a skip function that seems to do the job. I use the following (tricky) settings, which should do what you have in mind, if I'm not mistaken: #+begin_src emacs-lisp ;; Don't show scheduled entries in the global `todo' list. (setq org-agenda-todo-ignore-scheduled 'future) ;; Don't show entries scheduled in the future in the global ;; `todo' list (until they are within the warning period). (setq org-agenda-todo-ignore-deadlines 'near) ;; Honor `todo' list `org-agenda-todo-ignore...' options also ;; in the `tags-todo' list. (setq org-agenda-tags-todo-honor-ignore-options t) #+end_src Best regards, Seb -- Sebastien Vauban
[O] [ob-R] table variable passing broken
Hi all, There seems to be a bug in table passing as variables now using the tangle-friendly version of passing variables. Here is an example (I get an error also with emacs -Q): --8<---cut here---start->8--- * test #+name: testtab | variable | display | unit | |---+---+---| | num_cells | Number of Cells in Well | | | cell_area | Cell Area | μm² | | nucleus_area | Nucleus Area | μm² | | roundness | Cell Roundness| | | ratio_w2l | Cell Width to Length Ratio| | | inten_nuc_dapi_median | Intensity Nucleus DAPI Median | | | dapi_median | Intensity Nucleus DAPI Median | | | edu_median| Intensity edu Median | | | oct4_median | Intensity oct4 Median | | | clump_size| Clump Size| cells | | short_name| Cell Line | | | p_col | Column| | | batch | Batch | | | concentration | Fibronectin Concentration | ugml | | Residual | Residual | | | evaluation_guid | Plate | | | donor | Genotype | | #+BEGIN_SRC R :session *test* :var test=testtab test #+END_SRC #+RESULTS: --8<---cut here---end--->8--- I see this in my R session: --8<---cut here---start->8--- Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, (from testorg.org!917613Wp#22) : line 17 did not have 3 elements --8<---cut here---end--->8--- This is on - GNU Emacs 24.4.50.1 (x86_64-apple-darwin13.3.0, NS appkit-1265.21 Version 10.9.4 (Build 13E28)) of 2014-09-02 on mib106584i.local - Org-mode version 8.3beta (release_8.3beta-470-g087f8e) - ess-version: 14.05 [git: 4283f1304a54502c42707b6a4ba347703f0992dd] Best, Andreas
[O] [RFC] Change property drawer syntax
Hello, As discussed previously, I would like to modify property drawers syntax. The change is simple: they must be located right after a headline and its planning line, if any. Therefore the following cases are valid * Headline :PROPERTIES: :KEY: value :END: * Headline SCHEDULED: <2014-10-14 mar.> :PROPERTIES: :KEY: value :END: but, in the following case, the scheduled keyword will not be recognized * Headline :PROPERTIES: :KEY: value :END: SCHEDULED: <2014-10-14 mar.> When not empty, they also have to contain only node properties. Moreover, node properties' keys can only contain non-whitespace characters and cannot end with a plus sign (which is used for accumulation). Value can contain anything but a newline character. Thus, the following property drawer is invalid * Headline :PROPERTIES: :KEY: value Some text. :END: Any invalid property drawer becomes de facto a regular drawer, with "PROPERTIES" as its name. Besides defining exactly the syntax of property drawers, it should also make the property API faster in some cases. Indeed, there's no need to search through entire (possibly huge) sections in order to find properties attached to a headline. However, it will break some Org documents. In particular, TODO-states changes are usually logged before any drawer, including properties drawers. The following function repairs them. (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))) (insert (delete-and-extract-region (match-beginning 0) (min (1+ (match-end 0)) end))) (unless (bolp) (insert "\n" Internally, changes are somewhat invasive, as they include a rewrite of almost all the property API. They also alter clocking, tags, todo keywords, logging, initialization, hopefully in an invisible manner. I pushed a new branch, "top-properties" in the repository for code review and testing. It includes unit tests, documentation and an ORG-NEWS entry. Feedback welcome. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] [RFC] Change property drawer syntax
Hi Nicolas, My only 'concern' is that it looks awkward or at least unfamiliar when the property drawer is closed (which it is always in my documents). I guess than it would change from *** Call XXX :PROPERTIES:... <2014-10-16 Thu 13:00-14:00> to *** Call XXX <2014-10-16 Thu 13:00-14:00> :PROPERTIES:... which has a folded item 'in the middle of text' rather than right below the heading. I'll get used to that, I guess. Regards, Andreas Nicolas Goaziou writes: > Hello, > > As discussed previously, I would like to modify property drawers syntax. > The change is simple: they must be located right after a headline and > its planning line, if any. Therefore the following cases are valid > > * Headline > :PROPERTIES: > :KEY: value > :END: > > * Headline > SCHEDULED: <2014-10-14 mar.> > :PROPERTIES: > :KEY: value > :END: > > but, in the following case, the scheduled keyword will not be recognized > > * Headline > :PROPERTIES: > :KEY: value > :END: > SCHEDULED: <2014-10-14 mar.> > > When not empty, they also have to contain only node properties. > Moreover, node properties' keys can only contain non-whitespace > characters and cannot end with a plus sign (which is used for > accumulation). Value can contain anything but a newline character. > > Thus, the following property drawer is invalid > > * Headline > :PROPERTIES: > :KEY: value > Some text. > :END: > > Any invalid property drawer becomes de facto a regular drawer, with > "PROPERTIES" as its name. > > Besides defining exactly the syntax of property drawers, it should also > make the property API faster in some cases. Indeed, there's no need to > search through entire (possibly huge) sections in order to find > properties attached to a headline. > > However, it will break some Org documents. In particular, TODO-states > changes are usually logged before any drawer, including properties > drawers. The following function repairs them. > > (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))) > (insert (delete-and-extract-region > (match-beginning 0) > (min (1+ (match-end 0)) end))) > (unless (bolp) (insert "\n" > > Internally, changes are somewhat invasive, as they include a rewrite of > almost all the property API. They also alter clocking, tags, todo > keywords, logging, initialization, hopefully in an invisible manner. > > I pushed a new branch, "top-properties" in the repository for code > review and testing. It includes unit tests, documentation and an > ORG-NEWS entry. > > Feedback welcome. > > > Regards,
Re: [O] [RFC] Change property drawer syntax
Hello, Andreas Leha writes: > My only 'concern' is that it looks awkward or at least unfamiliar when the > property drawer is closed (which it is always in my documents). > > I guess than it would change from > > *** Call XXX > :PROPERTIES:... > <2014-10-16 Thu 13:00-14:00> > > to > > *** Call XXX > <2014-10-16 Thu 13:00-14:00> > :PROPERTIES:... No it wouldn't. PROPERTIES must be right after the deadline. <2014-10-16 Thu 13:00-14:00> is a mere timestamp, not a planning info line (with SCHEDULED, DEADLINE, CLOSED keywords). The second case is not a property drawer. Regards, -- Nicolas Goaziou
[O] etc/ORG-NEWS not updated for one year
etc/ORG-NEWS in emacs-24 has not been updated for ~ one year. If you are going to update it, please do so before thie Friday.
Re: [O] [RFC] Change property drawer syntax
Nicolas Goaziou writes: > Hello, > > As discussed previously, I would like to modify property drawers syntax. > The change is simple: they must be located right after a headline and > its planning line, if any. Therefore the following cases are valid > > * Headline > :PROPERTIES: > :KEY: value > :END: > > * Headline > SCHEDULED: <2014-10-14 mar.> > :PROPERTIES: > :KEY: value > :END: > > but, in the following case, the scheduled keyword will not be recognized > > * Headline > :PROPERTIES: > :KEY: value > :END: > SCHEDULED: <2014-10-14 mar.> > > When not empty, they also have to contain only node properties. > Moreover, node properties' keys can only contain non-whitespace > characters and cannot end with a plus sign (which is used for > accumulation). Value can contain anything but a newline character. > > Thus, the following property drawer is invalid > > * Headline > :PROPERTIES: > :KEY: value > Some text. > :END: > > Any invalid property drawer becomes de facto a regular drawer, with > "PROPERTIES" as its name. > > Besides defining exactly the syntax of property drawers, it should also > make the property API faster in some cases. Indeed, there's no need to > search through entire (possibly huge) sections in order to find > properties attached to a headline. > > However, it will break some Org documents. In particular, TODO-states > changes are usually logged before any drawer, including properties > drawers. The following function repairs them. > > (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))) > (insert (delete-and-extract-region > (match-beginning 0) > (min (1+ (match-end 0)) end))) > (unless (bolp) (insert "\n" > > Internally, changes are somewhat invasive, as they include a rewrite of > almost all the property API. They also alter clocking, tags, todo > keywords, logging, initialization, hopefully in an invisible manner. > > I pushed a new branch, "top-properties" in the repository for code > review and testing. It includes unit tests, documentation and an > ORG-NEWS entry. Sounds like fun! Here's maybe a bug. In this test case: * Here's something ** Second level :PROPERTIES: :ID: 06b778b5-72a5-45b5-aea6-2d0fef0fd24b :END: Calling org-entry-put on the first heading will actually place the property on its child. Reason being that, when org-entry-put calls org-get-property-block, and that calls org-insert-property-drawer, point has already been advanced to the beginning of the "** Second level" line. org-insert-property-drawer examines the child instead of the parent, thinks it doesn't have to insert anything, and returns nil. Code later in org-get-property-block locates the ":END:" belonging to the child, assumes that's the end of the parent's block, and sticks the new property there. (I found this because org-id-get-create placed new ID values in the child's property drawer.) That was a mouthful, but I'm not going to venture a patch at this point! Eric
Re: [O] [RFC] Change property drawer syntax
Hi Nicolas On Tue, Oct 14, 2014 at 4:42 PM, Nicolas Goaziou wrote: > As discussed previously, I would like to modify property drawers syntax. > The change is simple: they must be located right after a headline and > its planning line, if any. Therefore the following cases are valid > > * Headline > :PROPERTIES: > :KEY: value > :END: > > * Headline > SCHEDULED: <2014-10-14 mar.> > :PROPERTIES: > :KEY: value > :END: What about legacy multi line plain timestamp and planning info: * Yearly meeting <2013-09-22 Sun> <2014-10-19 Sun> SCHEDULED: <2015-01-01 Thu> Add next plain timestamp. :PROPERTIES: :KEY: value :END: * Yearly task DEADLINE: <2013-09-22 Sun -2d> DEADLINE: <2014-10-19 Sun -2d> SCHEDULED: <2015-01-01 Thu> Add next deadline. :PROPERTIES: :KEY: value :END: Will they also become invalid as I tend to understand? Can they be reordered as * Yearly meeting SCHEDULED: <2015-01-01 Thu> Add next plain timestamp. :PROPERTIES: :KEY: value :END: <2014-10-19 Sun> <2013-09-22 Sun> * Yearly task [It seems it can not be only reordered.] or will they have to be transformed into sub-headings like * Yearly meeting :PROPERTIES: :KEY: value :END: ** Yearly meeting - 2013 <2013-09-22 Sun> ** Yearly meeting - 2014 <2014-10-19 Sun> ** Yearly meeting - Add next plain timestamp SCHEDULED: <2015-01-01 Thu> * Yearly task :PROPERTIES: :KEY: value :END: ** Yearly task - 2013 DEADLINE: <2013-09-22 Sun -2d> ** Yearly task - 2014 DEADLINE: <2014-10-19 Sun -2d> ** Yearly task - Add next deadline SCHEDULED: <2015-01-01 Thu> ? Michael
Re: [O] [ob-R] table variable passing broken
Andreas Leha med.uni-goettingen.de> writes: > > Hi all, > > There seems to be a bug in table passing as variables now using the > tangle-friendly version of passing variables. > > Here is an example (I get an error also with emacs -Q): > > --8<---cut here---start->8--- > * test > #+name: testtab > | variable | display | unit | > |---+---+---| > | num_cells | Number of Cells in Well | | > | cell_area | Cell Area | μm² | > | nucleus_area | Nucleus Area | μm² | > | roundness | Cell Roundness| | > | ratio_w2l | Cell Width to Length Ratio| | > | inten_nuc_dapi_median | Intensity Nucleus DAPI Median | | > | dapi_median | Intensity Nucleus DAPI Median | | > | edu_median| Intensity edu Median | | > | oct4_median | Intensity oct4 Median | | > | clump_size| Clump Size| cells | > | short_name| Cell Line | | > | p_col | Column| | > | batch | Batch | | > | concentration | Fibronectin Concentration | ugml | > | Residual | Residual | | > | evaluation_guid | Plate | | > | donor | Genotype | | > > #+BEGIN_SRC R :session *test* :var test=testtab > test > #+END_SRC > > #+RESULTS: > --8<---cut here---end--->8--- > > I see this in my R session: > > --8<---cut here---start->8--- > Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, > na.strings, (from > testorg.org!917613Wp#22) : > line 17 did not have 3 elements > --8<---cut here---end--->8--- > I think this is the wrong diagnosis. Did you actually revert to the earlier version of ob-R.el to confirm that this would have run correctly? The reason I ask is that I just tried this with org-babel-R-assign-elisp from org-mode-a5686d87786b1d6514ec85959a2188f703346a06/lisp/ob-R.el and got the same error. Note this: --8<---cut here---start->8--- #+name: testtab2 | variable | display | unit | |--+--+--| | donor| Genotype | | #+BEGIN_SRC emacs-lisp :var test=testtab2 (orgtbl-to-tsv test '(:fmt org-babel-R-quote-tsv-field)) #+END_SRC #+RESULTS: : "donor" "Genotype" #+BEGIN_SRC emacs-lisp :var value=testtab2 ;; from org-babel-R-assign-elisp (mapcar 'length (org-remove-if-not 'sequencep value)) #+END_SRC #+RESULTS: | 3 | --8<---cut here---end--->8--- In particular, the empty table cells are omitted even though `value' or `test' has all lengths as 3. This results in calling read.table ( ..., fill=FALSE) implicitly. Not sure if the fix is to retool org-babel-R-assign-elisp or something in org-table.el. HTH, Chuck
Re: [O] etc/ORG-NEWS not updated for one year
Glenn Morris writes: > etc/ORG-NEWS in emacs-24 has not been updated for ~ one year. > > If you are going to update it, please do so before thie Friday. I will have a look, thanks. There has been no major release since one year, so don't expect major updates. -- Bastien
Re: [O] Math formatting in HTML export - The Org Manual
Thanks Eric.
I have tested this solution that works with imagemagick and html export. I
have added these lines in my init.el :
; Include the latex-exporter
(require 'ox-latex)
;; Add minted to the defaults packages to include when exporting.
;(add-to-list 'org-latex-packages-alist '("" "minted"))
;; Tell the latex export to use the minted package for source
;; code coloration.
(setq org-latex-listings 'minted)
;; Let the exporter use the -shell-escape option to let latex
;; execute external programs.
;; This obviously and can be dangerous to activate!
(setq org-latex-pdf-process
'("xelatex -shell-escape -interaction nonstopmode -output-directory
%o %f"))
and it works.
But now it does not work in my Gnus if I want to include some png images of
proofs... I have to deleted these "dangerous lines"...
I do not understand why I need minted and shell-escape...
Best wishes
Jo.
2014-10-14 9:25 GMT+02:00 Eric S Fraga :
> Have a look at the following variable and note the SNIPPET argument:
>
> ,[ C-h v org-latex-packages-alist RET ]
> | org-latex-packages-alist is a variable defined in `org.el'.
> | Its value is (("" "xcolor")
> | ("" "tikz")
> | ("" "listings")
> | ("version=3" "mhchem")
> | ("" "amsmath" t))
> |
> | Original value was nil
> |
> | Documentation:
> | Alist of packages to be inserted in every LaTeX header.
> |
> | These will be inserted after `org-latex-default-packages-alist'.
> | Each element is either a cell or a string.
> |
> | A cell is of the format:
> |
> | ("options" "package" SNIPPET-FLAG)
> |
> | SNIPPET-FLAG, when non-nil, indicates that this package is also
> | needed when turning LaTeX snippets into images for inclusion into
> | non-LaTeX output.
> |
> | A string will be inserted as-is in the header of the document.
> |
> | Make sure that you only list packages here which:
> |
> | - you want in every file;
> | - do not conflict with the setup in `org-format-latex-header';
> | - do not conflict with the default packages in
> | `org-latex-default-packages-alist'.
> |
> | You can customize this variable.
> `
>
>
> --
> Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)
>
Re: [O] Math formatting in HTML export - The Org Manual
Joseph Vidal-Rosset writes:
> Thanks Eric.
>
> I have tested this solution that works with imagemagick and html export. I
> have added these lines in my init.el :
>
> ; Include the latex-exporter
> (require 'ox-latex)
> ;; Add minted to the defaults packages to include when exporting.
> ;(add-to-list 'org-latex-packages-alist '("" "minted"))
> ;; Tell the latex export to use the minted package for source
> ;; code coloration.
> (setq org-latex-listings 'minted)
> ;; Let the exporter use the -shell-escape option to let latex
> ;; execute external programs.
> ;; This obviously and can be dangerous to activate!
> (setq org-latex-pdf-process
> '("xelatex -shell-escape -interaction nonstopmode -output-directory %o
> %f"))
>
> and it works.
>
> But now it does not work in my Gnus if I want to include some png
> images of proofs... I have to deleted these "dangerous lines"...
>
> I do not understand why I need minted and shell-escape...
>
I don't know why you need minted (I have not followed the conversation),
but to use minted you *need* -shell-escape: minted requires running an
external program (pygments), but tex does not like doing that for
security reasons - the -shell-escape option gives tex permission to run
such an external program.
Nick
[O] [PATCH] contrib/lisp/org-velocity: Fix failure for big window
Hi list, hi Paul, thanks for your org-velocity contribution! I just discovered org-velocity and immediately liked it. I found a bug which might not have occurred in the past since the monitors were smaller. The bug shows up when the number of lines of the match window exceeds the number of available indexes (which is 61). I think the patch (which is just a switch from 'greater than' to 'smaller than') in the attachment is a way to go. Please let me know what you think. Best regards, Marco -- http://www.wahlzone.de GPG: 0x0A3AE6F2 >From c867eda9b60736b0d3ae50d5a5f889e80cf25a81 Mon Sep 17 00:00:00 2001 From: Marco Wahl Date: Tue, 14 Oct 2014 20:07:31 +0200 Subject: [PATCH] contrib/lisp/org-velocity: Fix failure for big window * contrib/lisp/org-velocity.el (org-velocity-incremental-read): Reversed the estimation against window-height. --- contrib/lisp/org-velocity.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/lisp/org-velocity.el b/contrib/lisp/org-velocity.el index 3631a59..e6788c6 100644 --- a/contrib/lisp/org-velocity.el +++ b/contrib/lisp/org-velocity.el @@ -671,7 +671,7 @@ Stop searching once there are more matches than can be displayed." ;; Truncate the index to the size of the buffer to be ;; displayed. (with-selected-window match-window - (if (> (window-height) (length org-velocity-index)) + (if (< (window-height) (length org-velocity-index)) ;; (subseq org-velocity-index 0 (window-height)) (let ((hints (copy-sequence org-velocity-index))) (setcdr (nthcdr (window-height) hints) nil) -- 2.1.2
Re: [O] [ob-R] table variable passing broken
Charles Berry writes: > Andreas Leha med.uni-goettingen.de> writes: > >> >> Hi all, >> >> There seems to be a bug in table passing as variables now using the >> tangle-friendly version of passing variables. >> >> Here is an example (I get an error also with emacs -Q): >> >> --8<---cut here---start->8--- >> * test >> #+name: testtab >> | variable | display | unit | >> |---+---+---| >> | num_cells | Number of Cells in Well | | >> | cell_area | Cell Area | μm² | >> | nucleus_area | Nucleus Area | μm² | >> | roundness | Cell Roundness| | >> | ratio_w2l | Cell Width to Length Ratio| | >> | inten_nuc_dapi_median | Intensity Nucleus DAPI Median | | >> | dapi_median | Intensity Nucleus DAPI Median | | >> | edu_median| Intensity edu Median | | >> | oct4_median | Intensity oct4 Median | | >> | clump_size| Clump Size| cells | >> | short_name| Cell Line | | >> | p_col | Column| | >> | batch | Batch | | >> | concentration | Fibronectin Concentration | ugml | >> | Residual | Residual | | >> | evaluation_guid | Plate | | >> | donor | Genotype | | >> >> #+BEGIN_SRC R :session *test* :var test=testtab >> test >> #+END_SRC >> >> #+RESULTS: >> --8<---cut here---end--->8--- >> >> I see this in my R session: >> >> --8<---cut here---start->8--- >> Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, >> na.strings, (from >> testorg.org!917613Wp#22) : >> line 17 did not have 3 elements >> --8<---cut here---end--->8--- >> > > I think this is the wrong diagnosis. I agree. Saving the table as tsv (via org-table-export) results in a file that cannot be read from R either. > > Did you actually revert to the earlier version of ob-R.el to confirm that > this would have run correctly? I did not revert. But that org file used to work. I won't be able to bisect any time soon. > > The reason I ask is that I just tried this with org-babel-R-assign-elisp > from > > org-mode-a5686d87786b1d6514ec85959a2188f703346a06/lisp/ob-R.el > > and got the same error. Note this: > > > #+name: testtab2 > | variable | display | unit | > |--+--+--| > | donor| Genotype | | > > > #+BEGIN_SRC emacs-lisp :var test=testtab2 > (orgtbl-to-tsv test '(:fmt org-babel-R-quote-tsv-field)) > #+END_SRC > > #+RESULTS: > : "donor" "Genotype" > exactly. That also causes the org-table-export to fail. > > #+BEGIN_SRC emacs-lisp :var value=testtab2 > ;; from org-babel-R-assign-elisp > (mapcar 'length (org-remove-if-not 'sequencep value)) > #+END_SRC > > #+RESULTS: > | 3 | > > In particular, the empty table cells are omitted even though > > `value' or `test' has all lengths as 3. This results in > calling read.table ( ..., fill=FALSE) implicitly. > > Not sure if the fix is to retool org-babel-R-assign-elisp or something > in org-table.el. > I am the wrong person to answer that. But it looks to me to be an issue for org-table.el. Thanks for your better analysis. Regards, Andreas
Re: [O] Math formatting in HTML export - The Org Manual
On Tuesday, 14 Oct 2014 at 19:23, Joseph Vidal-Rosset wrote: [...] > But now it does not work in my Gnus if I want to include some png images of > proofs... I have to deleted these "dangerous lines"... Sorry, I missed this the first time around. What does gnus have to do with this? You were talking about exporting to HTML but never mentioned gnus in the original post. If you are trying to write an html based email, you should be looking at different functionality than exporting. Check out org-mime-htmlize, for instance. Exporting creates files which reference other files (for images). Messages are different. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-450-gbc9a58
[O] Bug: `org-capture-templates' file+headline target does not accept string variable [8.2.10 (8.2.10-elpa @ c:/Users/louis/AppData/Roaming/.emacs.d/elpa/org-20141013/)]
Having a template inside `org-capture-templates`, which uses the
file+headline target, with a string variable as its third argument (the
node headline), makes the command `org-capture` fail (specifically, when
selecting this particular template that uses this target).
The heading I have chosen, "Tasks", does exist within the file selected
within the template. When I use a variable that contains the string
"Tasks", the command fails. However, when I use the literal string
"Tasks" instead, the command succeeds and works fine.
Emacs : GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
of 2013-03-17 on MARVIN
Package: Org-mode version 8.2.10 (8.2.10-elpa @
c:/Users/louis/AppData/Roaming/.emacs.d/elpa/org-20141013/)
current state:
==
(setq
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-hide-inline-tasks org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-babel-pre-tangle-hook '(save-buffer)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-capture-templates '(("t" "Todo" entry
(file+headline main-org-file tasks-heading)
"* TODO %?\n %i\n %a")
)
org-default-notes-file "~/org/main.org"
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-show-block-all append
local]
5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-indent-mode)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-agenda-files '("~/org/main.org")
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-confirm-shell-link-function 'yes-or-no-p
)
Re: [O] [RFC] Change property drawer syntax
Hello, Eric Abrahamsen writes: > Sounds like fun! Here's maybe a bug. In this test case: > > * Here's something > ** Second level >:PROPERTIES: >:ID: 06b778b5-72a5-45b5-aea6-2d0fef0fd24b >:END: Good catch. Fixed, thank you. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Change property drawer syntax
Hello, Michael Brand writes: > What about legacy multi line plain timestamp and planning info: > > * Yearly meeting > <2013-09-22 Sun> > <2014-10-19 Sun> > SCHEDULED: <2015-01-01 Thu> Add next plain timestamp. > :PROPERTIES: > :KEY: value > :END: This is invalid, and has been so for a long time. Quoting first footnote in (info "(org) Inserting deadline/schedule"): The ‘SCHEDULED’ and ‘DEADLINE’ dates are inserted on the line right below the headline. Don’t put any text between this line and the headline. This footnote was inserted in c431fef47a7cbcc6ea79e3a945bc22cca4b4be96, which is dating back from march 2011. > * Yearly task > DEADLINE: <2013-09-22 Sun -2d> > DEADLINE: <2014-10-19 Sun -2d> > SCHEDULED: <2015-01-01 Thu> Add next deadline. > :PROPERTIES: > :KEY: value > :END: This is also invalid, per the footnote above. Also, you cannot have some text on the planning line. > Will they also become invalid as I tend to understand? They are already. My proposal doesn't change anything about it. > Can they be reordered as > > * Yearly meeting > SCHEDULED: <2015-01-01 Thu> Add next plain timestamp. > :PROPERTIES: > :KEY: value > :END: > <2014-10-19 Sun> > <2013-09-22 Sun> If you remove "Add next plain timestamp.", this is perfectly valid. * Yearly meeting SCHEDULED: <2015-01-01 Thu> :PROPERTIES: :KEY: value :END: <2014-10-19 Sun> <2013-09-22 Sun> > or will they have to be transformed into sub-headings like > > * Yearly meeting > :PROPERTIES: > :KEY: value > :END: > ** Yearly meeting - 2013 ><2013-09-22 Sun> > ** Yearly meeting - 2014 ><2014-10-19 Sun> > ** Yearly meeting - Add next plain timestamp >SCHEDULED: <2015-01-01 Thu> > > * Yearly task > :PROPERTIES: > :KEY: value > :END: > ** Yearly task - 2013 >DEADLINE: <2013-09-22 Sun -2d> > ** Yearly task - 2014 >DEADLINE: <2014-10-19 Sun -2d> > ** Yearly task - Add next deadline >SCHEDULED: <2015-01-01 Thu> I don't understand this. Again, there is one possible planning info line per entry. If there is one, the property drawer has to be inserted right below it. Otherwise, it needs to be right after the headline itself. This has nothing to do with plain timestamps, i.e., <2014-10-19 Sun> and <2013-09-22 Sun> in your example. I hope this is clearer now. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org-capture-place-item better alignment for new lists.
Hello, Andrew Burgess writes: > I've revised the patch (below) so that I now use org-indent-line to > establish the best indentation if we're starting a new list, this has > resulted in slightly more churn, but hopefully not too much. Thanks. I applied it. Note that you needed to add "TINYCHANGE" at the end of your patch. Since you are close to the loc limit, you will need to sign FSF papers for another one. Regards, -- Nicolas Goaziou
Re: [O] Bug: `org-capture-templates' file+headline target does not accept string variable [8.2.10 (8.2.10-elpa @ c:/Users/louis/AppData/Roaming/.emacs.d/elpa/org-20141013/)]
Hello, Louis Chan writes: > Having a template inside `org-capture-templates`, which uses the > file+headline target, with a string variable as its third argument (the > node headline), makes the command `org-capture` fail (specifically, when > selecting this particular template that uses this target). > The heading I have chosen, "Tasks", does exist within the file selected > within the template. When I use a variable that contains the string > "Tasks", the command fails. However, when I use the literal string > "Tasks" instead, the command succeeds and works fine. Nothing, in the manual or in `org-capture-templates' docstring, pretends that variables are supported there. You are expected to provide a string. I don't see any bug here. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] key-binding for all plotting styles
Here is the updated patch.
To see the result:
- cd to org-mode tree root
- make info
- launch Emacs
- C-u C-h i doc/org RET
- search for "Org-Plot" chapter
Regards
Thierry
Le 13/10/2014 18:24, Nicolas Goaziou a écrit :
>
> Some comments follow.
> ...
>
> It should be
>
> @kbd{M-x org-plot/gnuplot @key{RET}}
> @kbd{M-x orgtbl-ascii-plot @key{RET}}
> @samp{too small} or @samp{too large}.
> @samp{12}
Fixed
> Note there is also the macro
>
> @orgcmd{C-c " g,org-plot/gnuplot}
This macro is used as bullet items in a @table
I cannot use it in the middle of a text.
> BTW is-it ASCII-art or ascii-art?
Changed to capitals.
>From 5168483137640a896501c88740052fe5112bed54 Mon Sep 17 00:00:00 2001
From: Thierry Banel
Date: Tue, 14 Oct 2014 22:34:54 +0200
Subject: [PATCH] Document ASCII-art plot
* doc/org.texi: Extend Gnuplot chapter to ASCII-art plotting.
* etc/ORG-NEWS: Document ASCII-art plot.
---
doc/org.texi | 57 -
etc/ORG-NEWS | 2 ++
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 05df0eb..767fa1a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3258,11 +3258,17 @@ functions.
@cindex plot tables using Gnuplot
@cindex #+PLOT
-Org-Plot can produce 2D and 3D graphs of information stored in org tables
-using @file{Gnuplot} @uref{http://www.gnuplot.info/} and @file{gnuplot-mode}
+Org-Plot can produce graphs of information stored in org tables, either
+graphically or in ASCII-art.
+
+@subheading Graphical plots using @file{Gnuplot}
+
+Org-Plot produces 2D and 3D graphs using @file{Gnuplot}
+@uref{http://www.gnuplot.info/} and @file{gnuplot-mode}
@uref{http://xafs.org/BruceRavel/GnuplotMode}. To see this in action, ensure
that you have both Gnuplot and Gnuplot mode installed on your system, then
-call @code{org-plot/gnuplot} on the following table.
+call @kbd{C-c " g} or @kbd{M-x org-plot/gnuplot @key{RET}} on the following
+table.
@example
@group
@@ -3280,8 +3286,8 @@ call @code{org-plot/gnuplot} on the following table.
Notice that Org Plot is smart enough to apply the table's headers as labels.
Further control over the labels, type, content, and appearance of plots can
be exercised through the @code{#+PLOT:} lines preceding a table. See below
-for a complete list of Org-plot options. For more information and examples
-see the Org-plot tutorial at
+for a complete list of Org-plot options. The @code{#+PLOT:} lines are
+optional. For more information and examples see the Org-plot tutorial at
@uref{http://orgmode.org/worg/org-tutorials/org-plot.html}.
@subsubheading Plot Options
@@ -3337,6 +3343,47 @@ may still want to specify the plot type, as that can impact the content of
the data file.
@end table
+@subheading ASCII bar plots
+
+While the cursor is on a column, typing @kbd{C-c \" a} or
+@kbd{M-x orgtbl-ascii-plot @key{RET}} create a new column containing an
+ASCII-art bars plot. The plot is implemented through a regular column
+formula. When the source column changes, the bar plot may be updated by
+refreshing the table, for example typing @kbd{C-u C-c *}.
+
+@example
+@group
+| Sede | Max cites | |
+|---+---+--|
+| Chile |257.72 | |
+| Leeds |165.77 | WWWh |
+| Sao Paolo | 71.00 | WWW; |
+| Stockholm |134.19 | WW: |
+| Morelia |257.56 | WWWH |
+| Rochefourchat | 0.00 | |
+#+TBLFM: $3='(orgtbl-ascii-draw $2 0.0 257.72 12)
+@end group
+@end example
+
+The formula is an elisp call:
+@lisp
+(orgtbl-ascii-draw COLUMN MIN MAX WIDTH)
+@end lisp
+
+@table @code
+@item COLUMN
+ is a reference to the source column.
+
+@item MIN MAX
+ are the minimal and maximal values displayed. Sources values
+ outside this range are displayed as @samp{too small}
+ or @samp{too large}.
+
+@item WIDTH
+ is the width in characters of the bar-plot. It defaults to @samp{12}.
+
+@end table
+
@node Hyperlinks
@chapter Hyperlinks
@cindex hyperlinks
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 0a5af68..e94dec6 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -96,6 +96,8 @@ would throw an error. A new variable
~org-table-formula-create-columns~ was added to adjust this
behavior. It is now possible to silently add new columns, to do so
with a warning or to explicitly ask the user each time.
+*** ASCII plot
+Ability to plot values in a column through ASCII-art bars.
** Miscellaneous
*** File names in links accept are now compatible with URI syntax
Absolute file names can now start with =///= in addition to =/=. E.g.,
--
1.9.1
Re: [O] [PATCH] key-binding for all plotting styles
Hello, Thierry Banel writes: > Here is the updated patch. [...] >> BTW is-it ASCII-art or ascii-art? > Changed to capitals. __ _ _ / \ _ __ _ __ | (_) ___ __| | / _ \ | '_ \| '_ \| | |/ _ \/ _` | / ___ \| |_) | |_) | | | __/ (_| |_ /_/ \_\ .__/| .__/|_|_|\___|\__,_(_) |_| |_| Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] key-binding for all plotting styles
Le 14/10/2014 23:08, Nicolas Goaziou a écrit : > __ _ _ >/ \ _ __ _ __ | (_) ___ __| | > / _ \ | '_ \| '_ \| | |/ _ \/ _` | > / ___ \| |_) | |_) | | | __/ (_| |_ > /_/ \_\ .__/| .__/|_|_|\___|\__,_(_) > |_| |_| > > > _ _(\ (_)\ \ \ \ ) ) _ / / (_)/ / (_/
Re: [O] org-export-format-source-code-or-example: End of Buffer
Hi Bastien, According to Andreas, this is an org-mode issue: https://answers.launchpad.net/python-mode/+question/248031 Thanks, Mish On Fri, Apr 18, 2014 at 7:57 AM, Bastien wrote: > Hi Mishal, > > Mishal Awadah writes: > > > I added the sample code that generates the error for me on > > > http://stackoverflow.com/questions/22565379/emacs-org-mode-python-source-blocks-dont-export-with-python-mode-el > > I see Andreas made this python-mode bug report for it: > https://bugs.launchpad.net/python-mode/+bug/1295825 > > So I hope this will be sorted there. > > Best, > > -- > Bastien >
[O] How to change a link?
Hi list, assume that I have a link object (e.g., I'm in the ellipsis part of this: (org-element-map (org-element-parse-buffer 'object) 'link (lambda (elt) ... )) What I want to do is this: 1. check whether it is an internal link, and 2. if it is, change it so that it points to the analogous place in another file. Any hints about how to do these things? (The rationale is that I'm writing a function which splits a single Org file into a bunch of smaller ones, and I want to preserve links.) Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] Sharing: Agenda skip function to remove future-scheduled items
Sebastien Vauban writes: > I use the following (tricky) settings, which should do what you have in > mind, if I'm not mistaken: > > #+begin_src emacs-lisp > ;; Don't show scheduled entries in the global `todo' list. > (setq org-agenda-todo-ignore-scheduled 'future) > > ;; Don't show entries scheduled in the future in the global > ;; `todo' list (until they are within the warning period). > (setq org-agenda-todo-ignore-deadlines 'near) > > ;; Honor `todo' list `org-agenda-todo-ignore...' options also > ;; in the `tags-todo' list. > (setq org-agenda-tags-todo-honor-ignore-options t) > #+end_src Interesting. How would I apply those settings to only one custom agenda command, while leaving the others with the default behavior of showing future schedules? hjh
Re: [O] [RFC] Change property drawer syntax
Nicolas Goaziou writes: > Hello, > > As discussed previously, I would like to modify property drawers syntax. > The change is simple: they must be located right after a headline and > its planning line, if any. Therefore the following cases are valid Is there any chance this has messed up file-local #+TODO: keyword definitions? Specifically, it looks like, if there are more than one of those options lines, they aren't parsed or applied in this test branch. This works in both master and top-properties: #+TODO: FIX | BREAK * FIX My car This works in master but *not* top-properties: #+TODO: FIX | BREAK #+TODO: EMAIL | REPLY * FIX My car * EMAIL My dad In the second case, none of the TODO keywords are recognized as valid keywords. The lines don't appear to be parsed at all -- usually lines like that override the globally-defined keyword list, but in this case the global definitions are in effect. The docs still say multiple lines are permitted... Thanks, Eric
Re: [O] Math formatting in HTML export - The Org Manual
2014-10-14 19:51 GMT+02:00 Nick Dokos : > I don't know why you need minted (I have not followed the conversation), > but to use minted you *need* -shell-escape: minted requires running an > external program (pygments), but tex does not like doing that for > security reasons - the -shell-escape option gives tex permission to run > such an external program. > Thanks for this explanatio Nick. I need minted, strangely, in order to get png images in html export. If I try to avoid the use of minted, the png images are corrupted... Best wishes Jo.
Re: [O] Math formatting in HTML export - The Org Manual
2014-10-14 21:09 GMT+02:00 Eric S Fraga : > > But now it does not work in my Gnus if I want to include some png images > of > > proofs... I have to deleted these "dangerous lines"... > > Sorry, I missed this the first time around. What does gnus have to do > with this? You were talking about exporting to HTML but never mentioned > gnus in the original post. > > If you are trying to write an html based email, you should be looking at > different functionality than exporting. Check out org-mime-htmlize, for > instance. Exporting creates files which reference other files (for > images). Messages are different. Yes, I'm using precisely org-mime-htmlize with gnus when want to send messages with png images. But with minted in my setup (to export correctly html), the preview function does not work and then org-mime-htmlize fails... Again thanks ! Best wishes Jo.
