Re: [O] Displaying time (not just date) in timeline?
Jonathan Coupe writes: > Is this possible? If so, could someone explain how? It seems an odd > thing for a timeline not to be able to show time, but I've searched > the manual and the net and can't find anything. (It might be worth > adding a note to the manual that timeline can only show date, not > times, if this is the case?) > I doubt it. I'm not sure whether anything has been done to the timeline view over the past few years, but already in 2011, Carsten had this to say: , | - The timeline was the first agenda-like view I implemented, | it used to be (many years ago) the only way to see what was | coming up. That is why it only listed the future, and included | the past when used with e prefix argument (I believe). | | - Since then the agenda view came along, with vastly better | properties for being used as a planning tool for the coming | day an d week. It also included the possibility to look | at several files, which made the timelines view of a single | file look poor. Since then, the timeline has been a more | or less orphaned feature, and this is why it does not | work well with stuff like repeaters (repeaters where added | MUCH later). ` The full history is at http://thread.gmane.org/gmane.emacs.orgmode/39368/focus=40038 -- Nick
[O] Displaying time (not just date) in timeline?
Is this possible? If so, could someone explain how? It seems an odd thing for a timeline not to be able to show time, but I've searched the manual and the net and can't find anything. (It might be worth adding a note to the manual that timeline can only show date, not times, if this is the case?)
Re: [O] use of 'system in ox-odt.el
On May 20, 2015 1:43 PM, "Suvayu Ali" wrote: > > On Wed, May 20, 2015 at 01:21:34PM +0200, Rasmus wrote: > > Suvayu Ali writes: > > > > > On Wed, May 20, 2015 at 11:50:03AM +0200, Rasmus wrote: > > >> Suvayu Ali writes: > > >> > > > > > >> > Do you have a mailcap which says otherwise? That's what I would suspect > > >> > given the doc string for org-file-apps and the default value of > > >> > org-file-apps-defaults-gnu on my system. > > >> > > >> I have this in my mailcap > > >> > > >> application/msword; antiword %s; > > >> application/pdf;evince %s; > > >> application/vnd.lotus-organizer; emacsclient -ca '' %s; > > >> application/zip file-roller %s; > > >> > > >> Org does not open my html and odt files. It does open pdf files. This is > > >> using emacs -q. I use Gnome 3.16 and xdg-open works as expected from the > > >> terminal. > > > > > > There should also be a system-wide setting in /etc/mailcap. On my > > > Fedora machine, the system-wide settings all look like this: > > > > > > text/html; /usr/bin/xdg-open %s ; copiousoutput > > > > > > If yours doesn't, you could override it in ~/.mailcap. If that doesn't > > > fix things, I'm out of ideas :-|. > > > > Now it get the message > > > > Running /usr/bin/xdg-open /tmp/test.html ...done > > > > But it doesn't actually open the file... The same happens when I mark the > > file in dired and says & xdg-open. From the terminal it works fine. > > You are on Gnome, rt? I think there is a long standing "bug" in > gvfs-open (which is called by xdg-open). > > See the following: > http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html > https://bugzilla.gnome.org/show_bug.cgi?id=652262 > > I came across this a long time ago trying to investigate why xdg-open > didn't work when running asynchronously like your example. > > http://thread.gmane.org/gmane.emacs.help/93430 > > Hope this helps, > > -- > Suvayu I think those bug reports describe the problem precisely. I am also on gnome and have much the same problem. > > Open source is the future. It sets us free. >
Re: [O] A Microsoftesque detail in org
Rasmus writes: > The attached patch re-enables breaks in region four of > org-complex-heading-regexp, i.e. from the cookie up to tags. A quick test > suggests it works nicely. Pushed. Let me know if it's worse than before. Rasmus -- Need more coffee. . .
Re: [O] [patch] org-delete-indentation
Rasmus writes: > Nicolas Goaziou writes: > >> Also, shouldn't the final (delete-indentation ARG) be in the "else" part >> of the `if'? > > It was, at least on my disk. I did not check the patch. > >>> +(ert-deftest test-org-delete-indentation () >>> + "Test M-^ (`org-delete-indentation') specification." >> >> I suggest to omit binding in the description. That's one thing less we >> have to keep up-to-date if it ever changes. > > OK. > > The attached patch is updated and seems pretty good. It also handles tags > and entities according to org-auto-align-tags. Pushed. > The second patch (0003) adds support for tables in the sense that Not pushed. I'm still uncertain if this makes sense unless a some key enables breaking table cells. Rasmus -- 9000!
[O] How to elegantly and effectively quote org fragments?
Hello. So far, the main motivation for me is to be able to insert into an org file some org fragments found on the Internet, without their interacting with the org file. Sorry if these are easy questions -- I did spend time with the manual, the FAQ, the list archive, and the web. The best I found is to use an org SRC block, but I do not find it satisfactory. Plus I cannot even have it work properly. (1) Say I have have this in my org file (star in 1st column): * a regular headline: writing org examples #+BEGIN_SRC org ,* a headline only for the example ,** a subheadline text #+END_SRC Is it the best that one can do to quote some org code? Since I use (org-startup-indented t), I would expect to have the corresponding indentation. Also, if not possible to avoid the escaping commas, I would like to at least have them for each line, not only for the headlines. So I would like something like this: * a regular headline: writing org examples #+BEGIN_SRC org ,* a headline only for the example , * a subheadline ,text #+END_SRC Is (some of) this at all doable? (2) Now, if in the org edit buffer I do 'C-c C-d' (org-deadline), insert a DEADLINE:, and go back to my org file, the block now looks like: #+BEGIN_SRC org ,* a headline only for the example ,** a subheadline DEADLINE: <2015-05-21 Thu> text #+END_SRC If I do 'M-x org-agenda RET a', I get the following line in the Org agenda buffer: todo: Deadline: a regular headline: writing org examples Is this normal? Since the deadline is part of the block, I would expect no entry in the agenda; I tried to escape the DEADLINE with a comma, but it does not change anything. So, is there a way to *quote* a DEADLINE:, i.e., without having an associated entry in the agenda? Thank you for your help. [8.2.10 (8.2.10-40-gc763fa-elpa @ /home/cochard/.emacs.d/elpa/org-20150518/)] GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.14.12) of 2015-04-17 on buildvm-04.phx2.fedoraproject.org
Re: [O] [PATCH] ob-core: Fix indented cached result returning nil
Hello, Bjarte Johansen writes: > Fix a problem where a source block would return nil if the result was > cached and it was indented. Thank you. Some comments follow. > * lisp/ob-core.el (org-babel-execute-src-block): Move point to the the > first character of the result instead of the beginning of the line. > > * testing/lisp/test-ob.el > (test-org-babel/indented-cached-org-bracket-link): Added test to > to see if the indented cached result returns what it should return. You need to add TINYCHANGE at the end of the commit message if you haven't signed FSF papers yet. > - (end-of-line 1) (forward-char 1) > + (end-of-line 1) (forward-char (1+ (current-indentation))) Slightly better: (forward-line) (forward-char (current-indentation)) > +(ert-deftest test-org-babel/indented-cached-org-bracket-link () > + "When the result of a source block is indentend, a link and "a cached indented link" > +cached it should still return the link." > + (let ((test-block (concat "* Test\n" > + " #+BEGIN_SRC sh :file test.txt :cache yes\n" > + "echo 'text'\n" > + " #+END_SRC\n" > + "\n" > + " > #+RESULTS[be4fa2f590a6bc5b6c1f2a6747a067404506]:\n" > + " [[file:test.txt]]"))) > +(with-temp-buffer > + (insert test-block) > + (search-backward "BEGIN_SRC") > + (org-mode) > + (should (string= (concat default-directory "test.txt") > +(org-babel-execute-src-block)) You should use `org-test-with-temp-text' instead, and avoid "sh" as it might not be active. OTOH, emacs-lisp is always available: --8<---cut here---start->8--- (should (org-test-with-temp-text "* Test #+BEGIN_SRC emacs-lisp :file test.txt :cache yes (message \"text\") #+END_SRC #+RESULTS[c9828cf13461ca9ccb31e76ba4aee02ec6d7a4e7]: [[file:test.txt]]" (string= (concat default-directory "test.txt") (org-babel-execute-src-block --8<---cut here---end--->8--- Regards, -- Nicolas Goaziou
Re: [O] [RFC] Org linting library
Rainer M Krug writes: > There is an example where I get the error: > > * Fitting the kernel to the data > The parameter which will be fitted can be found in Table [[tab:fitInitial]] > > #+CAPTION: Variables used for the initial fit of the wind profile using the > function and the initial values. > #+LABEL: tab:fitInitial > | variable | initial value | remark > | > |+---+--| > > The cause is the link [[tab:initial]] If I remove everything below and > including the line #+CAPTION the linting works. Fixed. Thank you. Regards,
Re: [O] [RFC] Org linting library
Envoyé de mon iPhone > Le 20 mai 2015 à 22:42, Andreas Leha a > écrit : > > Hi Rainer, > > Rainer M Krug writes: >> Rainer M Krug writes: >> >>> Rainer M Krug writes: >>> Andreas Leha writes: > Hi Rainer, > > Rainer M Krug writes: >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> The following library implements linting for Org syntax. The sole public >>> function is `org-lint', which see. >>> >>> Internally, the library defines a new structure: `org-lint-checker', >>> with the following slots: >>> >>> - NAME: Unique check identifier, as a symbol. The check is done >>>calling the function `org-lint-NAME' with one mandatory argument, >>>the parse tree describing the current Org buffer. Such function >>>calls are wrapped within a `save-excursion' and point is always at >>>`point-min'. Its return value has to be an alist (POSITION MESSAGE) >>>when POSITION refer to the buffer position of the error, as an >>>integer, and MESSAGE is a strings describing the error. >>> >>> - DESCRIPTION: Summary about the check, as a string. >>> >>> - CATEGORIES: Categories relative to the check, as a list of symbol. >>>They are used for filtering when calling `org-lint'. Checkers not >>>explicitly associated to a category are collected in the `default' >>>one. >>> >>> - TRUST: The trust level one can have in the check. It is either `low' >>>or `high', depending on the heuristics implemented and the nature of >>>the check. This has an indicative value only and is displayed along >>>reports. >>> >>> All checks have to be listed in `org-lint--checkers'. >>> >>> Results are displayed in a special "*Org Lint*" buffer with a dedicated >>> major mode, derived from `tabulated-list-mode'. In addition to the usual >>> key-bindings inherited from it, "C-j" displays problematic line reported >>> under point and "RET" jumps to it. >>> >>> Checks currently implemented are: >>> >>> - duplicates CUSTOM_ID properties >>> - duplicate NAME values >>> - duplicate targets >>> - duplicate footnote definitions >>> - orphaned affiliated keywords >>> - obsolete affiliated keywords >>> - missing language in src blocks >>> - NAME values with a colon >>> - wrong header arguments in src blocks >>> - misuse of CATEGORY keyword >>> - "coderef" links with unknown destination >>> - "custom-id" links with unknown destination >>> - "fuzzy" links with unknown destination >>> - "id" links with unknown destination >>> - links to non-existent local files >>> - special properties in properties drawer >>> - obsolete syntax for PROPERTIES drawers >>> - missing definition for footnote references >>> - missing reference for footnote definitions >>> - non-footnote definitions in footnote section >>> - probable invalid keywords >>> - invalid blocks >>> - probable incomplete drawers >>> - obsolete QUOTE section >>> >>> Since it relies on lexical binding, `pcase' and `string-prefix-p', it >>> cannot be added to Org 8.3, but can make it into Org 8.4, if deemed >>> useful enough. >> >> This sounds very interesting and I would like to try it out. I >> understand that it can't be put into master, but could it be put into a >> branch? >> >> This would make testing a bit easier. > > It is. The branch is called `wip-lint'. Thanks (also to Nicolas) - I found it. Just expected the branch to be tracked automatically. This is really brilliant! But I now get a message in one .org file: , | Org linting process starting... | Search failed: "^[]*#\\+NAME: +tab:sensVar" ` and no results. Works in other .org files. This one is rather long (11570 lines) and many code blocks. Just let me know how I can trace down where this is coming from and what the message tells me. >>> >>> It seems that the error comes from the fact that ~#+LABEL: sensVar~ was >>> defined twice. >>> >>> Renaming these results in working linting. >> >> OK - please ignore this last comment. >> >> There is an example where I get the error: >> >> * Fitting the kernel to the data >> The parameter which will be fitted can be found in Table [[tab:fitInitial]] >> >> #+CAPTION: Variables used for the initial fit of the wind profile using the >> function and the initial values. >> #+LABEL: tab:fitInitial >> | variable | initial value | remark >>| >> |+---+--| >> >> The cause is the link [[tab:initial]] If I remove everything below and >> including t
Re: [O] position figures side by side in PDF output
Hi Zhihao, Rasmus writes: > Hi Zhihao, > > Zhihao Ding writes: > >> Could anyone give me some advice on how to position figures side by side in >> PDF output? >> I am trying to write a report, while my figures were all originally produced >> individually. I’d like >> to put them, mostly two, sometimes three, side by side sharing a same >> caption and label. >> Below is the syntax I am using now, which can only do one figure. > > Does this thread answer your question? It would give you individual > subcaptions, but you need not use them. > > https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00548.html > > Otherwise you could use e.g. imagemagick to stick together figures. > As an alternative you could use a table. + easy + orgmode only (should work across backends) - no scaling of images - it is a table for latex (i.e. will appear in list of tables, etc.) Here is a short example for the table approach and an imagemagick-based solution as proposed by Rasmus. --8<---cut here---start->8--- * generate images :noexport: #+name: image1 #+begin_src R :results graphics :file img1.pdf plot(1:10) #+end_src #+results: image1 [[file:img1.pdf]] #+name: image2 #+begin_src R :results graphics :file img2.pdf plot(1:5) #+end_src #+results: image2 [[file:img2.pdf]] * export side-by-side ** table #+caption: stitching side-by-side using tables | [[file:img1.pdf]] | [[file:img2.pdf]] | ** using imagemagick *** function :noexport: #+name: sidebyside #+begin_src sh :session none :results file replace :var im1="im1.png" :var im2="im2.png" :var outname="out.png" convert "$im1" "$im2" +append "$outname" echo "$outname" #+end_src *** test #+name: combinedfig #+call: sidebyside(im1="img1.pdf", im2="img2.pdf") :results file #+caption: stitching side-by-side using imagemagick #+results: combinedfig [[file:out.png]] --8<---cut here---end--->8--- Regards, Andreas
Re: [O] How to create synopsis output of versioned text?
Thanks Ken, your wording "side-by-side-options" helped me now tracking down emacs "ediff" (M-x ediff-files). But this probably won't do the trick of side- by-side output other than on screen. Am Mittwoch, 20. Mai 2015, 16:21:55 schrieben Sie: > I use 'latexdiff' for this, but it does not have a side-by-side option. > > -k. > > On 2015-05-20 at 14:13, Martin Weigele wrote: > > When dealing with different versions of text, e.g. old and new (law) code, > > it is sometimes nice to be able to create a synopsis of the versions of > > the text in tabular form. > > > > Any suggestions how to do this in emacs orgmode? Yes I know you can > > manually do tables, and you could call unix diff, but something that does > > it automatically from the individual text versions with a tabular output > > - old version left, new version right column, with similar sections or > > code pieces matching in the same row would be cool. As a last resort, > > even outside orgmode. :) > > > > Martin
Re: [O] [RFC] Org linting library
Hi Rainer, Rainer M Krug writes: > Rainer M Krug writes: > >> Rainer M Krug writes: >> >>> Andreas Leha writes: >>> Hi Rainer, Rainer M Krug writes: > Nicolas Goaziou writes: > >> Hello, >> >> The following library implements linting for Org syntax. The sole public >> function is `org-lint', which see. >> >> Internally, the library defines a new structure: `org-lint-checker', >> with the following slots: >> >> - NAME: Unique check identifier, as a symbol. The check is done >> calling the function `org-lint-NAME' with one mandatory argument, >> the parse tree describing the current Org buffer. Such function >> calls are wrapped within a `save-excursion' and point is always at >> `point-min'. Its return value has to be an alist (POSITION MESSAGE) >> when POSITION refer to the buffer position of the error, as an >> integer, and MESSAGE is a strings describing the error. >> >> - DESCRIPTION: Summary about the check, as a string. >> >> - CATEGORIES: Categories relative to the check, as a list of symbol. >> They are used for filtering when calling `org-lint'. Checkers not >> explicitly associated to a category are collected in the `default' >> one. >> >> - TRUST: The trust level one can have in the check. It is either `low' >> or `high', depending on the heuristics implemented and the nature of >> the check. This has an indicative value only and is displayed along >> reports. >> >> All checks have to be listed in `org-lint--checkers'. >> >> Results are displayed in a special "*Org Lint*" buffer with a dedicated >> major mode, derived from `tabulated-list-mode'. In addition to the usual >> key-bindings inherited from it, "C-j" displays problematic line reported >> under point and "RET" jumps to it. >> >> Checks currently implemented are: >> >> - duplicates CUSTOM_ID properties >> - duplicate NAME values >> - duplicate targets >> - duplicate footnote definitions >> - orphaned affiliated keywords >> - obsolete affiliated keywords >> - missing language in src blocks >> - NAME values with a colon >> - wrong header arguments in src blocks >> - misuse of CATEGORY keyword >> - "coderef" links with unknown destination >> - "custom-id" links with unknown destination >> - "fuzzy" links with unknown destination >> - "id" links with unknown destination >> - links to non-existent local files >> - special properties in properties drawer >> - obsolete syntax for PROPERTIES drawers >> - missing definition for footnote references >> - missing reference for footnote definitions >> - non-footnote definitions in footnote section >> - probable invalid keywords >> - invalid blocks >> - probable incomplete drawers >> - obsolete QUOTE section >> >> Since it relies on lexical binding, `pcase' and `string-prefix-p', it >> cannot be added to Org 8.3, but can make it into Org 8.4, if deemed >> useful enough. >> > > This sounds very interesting and I would like to try it out. I > understand that it can't be put into master, but could it be put into a > branch? > > This would make testing a bit easier. > It is. The branch is called `wip-lint'. >>> >>> Thanks (also to Nicolas) - I found it. Just expected the branch to be >>> tracked automatically. >>> >>> This is really brilliant! >>> >>> But I now get a message in one .org file: >>> >>> , >>> | Org linting process starting... >>> | Search failed: "^[]*#\\+NAME: +tab:sensVar" >>> ` >>> >>> and no results. >>> >>> Works in other .org files. >>> >>> This one is rather long (11570 lines) and many code blocks. >>> >>> Just let me know how I can trace down where this is coming from and what >>> the message tells me. >> >> It seems that the error comes from the fact that ~#+LABEL: sensVar~ was >> defined twice. >> >> Renaming these results in working linting. > > OK - please ignore this last comment. > > There is an example where I get the error: > > * Fitting the kernel to the data > The parameter which will be fitted can be found in Table [[tab:fitInitial]] > > #+CAPTION: Variables used for the initial fit of the wind profile using the > function and the initial values. > #+LABEL: tab:fitInitial > | variable | initial value | remark > | > |+---+--| > > The cause is the link [[tab:initial]] If I remove everything below and > including the line #+CAPTION the linting works. > > , > | 2 high Unknown fuzzy location "tab:fitInitial" > ` > Untested - but should that not be #+NAME: tab:fitInitial rather than #+LABE
Re: [O] How to create synopsis output of versioned text?
I use 'latexdiff' for this, but it does not have a side-by-side option. -k. On 2015-05-20 at 14:13, Martin Weigele wrote: > When dealing with different versions of text, e.g. old and new (law) code, it > is sometimes nice to be able to create a synopsis of the versions of the text > in tabular form. > > Any suggestions how to do this in emacs orgmode? Yes I know you can manually > do tables, and you could call unix diff, but something that does it > automatically from the individual text versions with a tabular output - old > version left, new version right column, with similar sections or code pieces > matching in the same row would be cool. As a last resort, even outside > orgmode. :) > > Martin
[O] Solution for changing background images with Beamer export
Hello,
I make a lot of presentations using Org Mode exporting to Beamer. One
issue that came up is using transparent background images, or rather,
changing background images during the presentation.
That is, you want to do something like this:
(background image image1.jpg)
slide1
slide2
(background image image2.jpg)
slide3
slide4
etc.
The obvious way to do this was as follows:
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation,14pt]
#+BEAMER_THEME: Pittsburgh
#+BEAMER_COLOR_THEME: orchid
#+BEAMER_FONT_THEME: serif [stillsansserifsmall,stillsansseriflarge,structure]
#+BEAMER_HEADER: \setbeamercolor{background canvas}{bg=}
#+BEAMER_HEADER: \setbeamertemplate{navigation symbols}{}
#+BEAMER_HEADER: \logo{\includegraphics{gng-logo.png}}
#+BEAMER_HEADER:
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{images/image1.jpg}}%
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_envargs(Env Args)
%4BEAMER_col(Col) %8BEAMER_extra(Extra)
#+PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 :ETC
#+OPTIONS: toc:nil h:1<--Note frames at level 1
* Song1
stuff
Trying to change background here
#+BEAMER:
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{images/image2.jpg}}%
* Song2
%%% etc. %%%
With this approach the export won't work correctly (and it's
completely understandable why not --- you only know where the old
frame ends when you see the beginning of the new frame). Looking at
the generated Latex, I see
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{images/image2.jpg}}%
\end{frame}
\begin{frame}[label=sec-5]{Song2}
which basically does nothing as far as the background goes. I was hoping for:
\end{frame}
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{images/image2.jpg}}%
\begin{frame}[label=sec-5]{Song2}
In my research on this I saw that a number of people had this problem
and nobody seemed to know what to do.
Turns out there's a simple workaround. Just put the frames one level
deeper and do something like the following:
set background in prologue using beamer command as above
set frames at level 2
#+OPTIONS: ... :h 2
* Song1 (This is a dummy heading at least for my purposes)
** Song 1 slide 1
%%% stuff %%%
** Song 1 slide 2
%%% etc. %%%
* Song2 (Dummy heading)
#+BEAMER:
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{images/image2.jpg}}%
** Song 2 slide 1
%%% stuff %%%
** Song 2 slide 2
%%% etc. %%%
* Song3 (Dummy heading)
#+BEAMER:
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{images/image3.jpg}}%
** Song 3 slide 1
%%% stuff %%%
** Song 3 slide 2
%%% etc. %%%
While this will affect the outlining and so on, it may nevertheless be
useful in many cases.
I hope this is useful to someone.
--
Fred Gilhamf...@sunbot.homedns.org
just make me lighter
make me lighter still
'til the yellow of the sun takes me
[oh what Lazarus saw! I cannnot bear this anymore!]
-- Linshuang Lu
[O] Exporting custom dynamic blocks
Hi, What is the canonical way of exporting custom dynamic blocks? Is there a mechanism similar to org-dblock-write: only for exporting dblocks? I cannot find any documentation on this. To give a little background to my question: I am currently writing a conversion from deadlines/schedules/effort to pgf-gantt charts. This was discussed before on this list, but I couldn't find anyone actually implementing it. Ideally I would like to create a custom dynamic block that contains the result of my parsing and computation, and then have a custom exporter for that dynamic block that creates the pgf-gantt code, so that I can later add exporters for other formats, e.g. html. If there is no such mechanism, what is the best way of storing that pgf-gantt source code so that it gets integrated into latex export, but doesn't interfere with other exporters? Currently I'm simply writing the pgf-gantt code into the custom block, and this does get exported correctly to latex, but produces error boxes in html. Regards, Bernhard
[O] [PATCH] ob-core: Fix indented cached result returning nil
Fix a problem where a source block would return nil if the result was cached and it was indented. * lisp/ob-core.el (org-babel-execute-src-block): Move point to the the first character of the result instead of the beginning of the line. * testing/lisp/test-ob.el (test-org-babel/indented-cached-org-bracket-link): Added test to to see if the indented cached result returns what it should return. --- lisp/ob-core.el | 2 +- testing/lisp/test-ob.el | 17 + 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 91bbde4..e7e029d 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -652,7 +652,7 @@ block." (cache-current-p (save-excursion ;; return cached result (goto-char (org-babel-where-is-src-block-result nil info)) - (end-of-line 1) (forward-char 1) + (end-of-line 1) (forward-char (1+ (current-indentation))) (let ((result (org-babel-read-result))) (message (replace-regexp-in-string "%" "%%" (format "%S" result))) result))) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index f52ff24..ae61b0c 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -20,6 +20,23 @@ ;;; Code: +(ert-deftest test-org-babel/indented-cached-org-bracket-link () + "When the result of a source block is indentend, a link and +cached it should still return the link." + (let ((test-block (concat "* Test\n" + " #+BEGIN_SRC sh :file test.txt :cache yes\n" + "echo 'text'\n" + " #+END_SRC\n" + "\n" + " #+RESULTS[be4fa2f590a6bc5b6c1f2a6747a067404506]:\n" + " [[file:test.txt]]"))) +(with-temp-buffer + (insert test-block) + (search-backward "BEGIN_SRC") + (org-mode) + (should (string= (concat default-directory "test.txt") + (org-babel-execute-src-block)) + (ert-deftest test-org-babel/multi-line-header-regexp () (should(equal "^[ \t]*#\\+headers?:[ \t]*\\([^\n]*\\)$" org-babel-multi-line-header-regexp)) -- 2.3.2 (Apple Git-55)
[O] How to create synopsis output of versioned text?
When dealing with different versions of text, e.g. old and new (law) code, it is sometimes nice to be able to create a synopsis of the versions of the text in tabular form. Any suggestions how to do this in emacs orgmode? Yes I know you can manually do tables, and you could call unix diff, but something that does it automatically from the individual text versions with a tabular output - old version left, new version right column, with similar sections or code pieces matching in the same row would be cool. As a last resort, even outside orgmode. :) Martin
Re: [O] use of 'system in ox-odt.el
On Wed, May 20, 2015 at 01:21:34PM +0200, Rasmus wrote: > Suvayu Ali writes: > > > On Wed, May 20, 2015 at 11:50:03AM +0200, Rasmus wrote: > >> Suvayu Ali writes: > >> > > > >> > Do you have a mailcap which says otherwise? That's what I would suspect > >> > given the doc string for org-file-apps and the default value of > >> > org-file-apps-defaults-gnu on my system. > >> > >> I have this in my mailcap > >> > >> application/msword; antiword %s; > >> application/pdf;evince %s; > >> application/vnd.lotus-organizer; emacsclient -ca '' %s; > >> application/zip file-roller %s; > >> > >> Org does not open my html and odt files. It does open pdf files. This is > >> using emacs -q. I use Gnome 3.16 and xdg-open works as expected from the > >> terminal. > > > > There should also be a system-wide setting in /etc/mailcap. On my > > Fedora machine, the system-wide settings all look like this: > > > > text/html; /usr/bin/xdg-open %s ; copiousoutput > > > > If yours doesn't, you could override it in ~/.mailcap. If that doesn't > > fix things, I'm out of ideas :-|. > > Now it get the message > > Running /usr/bin/xdg-open /tmp/test.html ...done > > But it doesn't actually open the file... The same happens when I mark the > file in dired and says & xdg-open. From the terminal it works fine. You are on Gnome, rt? I think there is a long standing "bug" in gvfs-open (which is called by xdg-open). See the following: http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html https://bugzilla.gnome.org/show_bug.cgi?id=652262 I came across this a long time ago trying to investigate why xdg-open didn't work when running asynchronously like your example. http://thread.gmane.org/gmane.emacs.help/93430 Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] position figures side by side in PDF output
Hi Zhihao, Zhihao Ding writes: > Could anyone give me some advice on how to position figures side by side in > PDF output? > I am trying to write a report, while my figures were all originally produced > individually. I’d like > to put them, mostly two, sometimes three, side by side sharing a same caption > and label. > Below is the syntax I am using now, which can only do one figure. Does this thread answer your question? It would give you individual subcaptions, but you need not use them. https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00548.html Otherwise you could use e.g. imagemagick to stick together figures. —Rasmus -- Need more coffee. . .
[O] position figures side by side in PDF output
Hi there, Could anyone give me some advice on how to position figures side by side in PDF output? I am trying to write a report, while my figures were all originally produced individually. I’d like to put them, mostly two, sometimes three, side by side sharing a same caption and label. Below is the syntax I am using now, which can only do one figure. #+BEGIN_CENTER #+CAPTION[My short Caption]: my long caption #+NAME: fig:label #+ATTR_LATEX: :options page=1 :width \textwidth [[/path/to/my/figure1]] #+END_CENTER Thanks a lot! Zhihao
Re: [O] [RFC] Org linting library
Rainer M Krug writes: > Rainer M Krug writes: > >> Andreas Leha writes: >> >>> Hi Rainer, >>> >>> Rainer M Krug writes: Nicolas Goaziou writes: > Hello, > > The following library implements linting for Org syntax. The sole public > function is `org-lint', which see. > > Internally, the library defines a new structure: `org-lint-checker', > with the following slots: > > - NAME: Unique check identifier, as a symbol. The check is done > calling the function `org-lint-NAME' with one mandatory argument, > the parse tree describing the current Org buffer. Such function > calls are wrapped within a `save-excursion' and point is always at > `point-min'. Its return value has to be an alist (POSITION MESSAGE) > when POSITION refer to the buffer position of the error, as an > integer, and MESSAGE is a strings describing the error. > > - DESCRIPTION: Summary about the check, as a string. > > - CATEGORIES: Categories relative to the check, as a list of symbol. > They are used for filtering when calling `org-lint'. Checkers not > explicitly associated to a category are collected in the `default' > one. > > - TRUST: The trust level one can have in the check. It is either `low' > or `high', depending on the heuristics implemented and the nature of > the check. This has an indicative value only and is displayed along > reports. > > All checks have to be listed in `org-lint--checkers'. > > Results are displayed in a special "*Org Lint*" buffer with a dedicated > major mode, derived from `tabulated-list-mode'. In addition to the usual > key-bindings inherited from it, "C-j" displays problematic line reported > under point and "RET" jumps to it. > > Checks currently implemented are: > > - duplicates CUSTOM_ID properties > - duplicate NAME values > - duplicate targets > - duplicate footnote definitions > - orphaned affiliated keywords > - obsolete affiliated keywords > - missing language in src blocks > - NAME values with a colon > - wrong header arguments in src blocks > - misuse of CATEGORY keyword > - "coderef" links with unknown destination > - "custom-id" links with unknown destination > - "fuzzy" links with unknown destination > - "id" links with unknown destination > - links to non-existent local files > - special properties in properties drawer > - obsolete syntax for PROPERTIES drawers > - missing definition for footnote references > - missing reference for footnote definitions > - non-footnote definitions in footnote section > - probable invalid keywords > - invalid blocks > - probable incomplete drawers > - obsolete QUOTE section > > Since it relies on lexical binding, `pcase' and `string-prefix-p', it > cannot be added to Org 8.3, but can make it into Org 8.4, if deemed > useful enough. > This sounds very interesting and I would like to try it out. I understand that it can't be put into master, but could it be put into a branch? This would make testing a bit easier. >>> >>> It is. The branch is called `wip-lint'. >> >> Thanks (also to Nicolas) - I found it. Just expected the branch to be >> tracked automatically. >> >> This is really brilliant! >> >> But I now get a message in one .org file: >> >> , >> | Org linting process starting... >> | Search failed: "^[ ]*#\\+NAME: +tab:sensVar" >> ` >> >> and no results. >> >> Works in other .org files. >> >> This one is rather long (11570 lines) and many code blocks. >> >> Just let me know how I can trace down where this is coming from and what >> the message tells me. > > It seems that the error comes from the fact that ~#+LABEL: sensVar~ was > defined twice. > > Renaming these results in working linting. OK - please ignore this last comment. There is an example where I get the error: --8<---cut here---start->8--- * Fitting the kernel to the data The parameter which will be fitted can be found in Table [[tab:fitInitial]] #+CAPTION: Variables used for the initial fit of the wind profile using the function and the initial values. #+LABEL: tab:fitInitial | variable | initial value | remark | |+---+--| --8<---cut here---end--->8--- The cause is the link [[tab:initial]] If I remove everything below and including the line #+CAPTION the linting works. , | 2 high Unknown fuzzy location "tab:fitInitial" ` Cheers, Rainer > > Rainer > >> >> Thanks, >> >> Rainer >> >>> >>> Regards, >>> Andreas >>> >>> -- Rainer M. Krug, PhD (Con
Re: [O] [RFC] Org linting library
Rainer M Krug writes: > Andreas Leha writes: > >> Hi Rainer, >> >> Rainer M Krug writes: >>> Nicolas Goaziou writes: >>> Hello, The following library implements linting for Org syntax. The sole public function is `org-lint', which see. Internally, the library defines a new structure: `org-lint-checker', with the following slots: - NAME: Unique check identifier, as a symbol. The check is done calling the function `org-lint-NAME' with one mandatory argument, the parse tree describing the current Org buffer. Such function calls are wrapped within a `save-excursion' and point is always at `point-min'. Its return value has to be an alist (POSITION MESSAGE) when POSITION refer to the buffer position of the error, as an integer, and MESSAGE is a strings describing the error. - DESCRIPTION: Summary about the check, as a string. - CATEGORIES: Categories relative to the check, as a list of symbol. They are used for filtering when calling `org-lint'. Checkers not explicitly associated to a category are collected in the `default' one. - TRUST: The trust level one can have in the check. It is either `low' or `high', depending on the heuristics implemented and the nature of the check. This has an indicative value only and is displayed along reports. All checks have to be listed in `org-lint--checkers'. Results are displayed in a special "*Org Lint*" buffer with a dedicated major mode, derived from `tabulated-list-mode'. In addition to the usual key-bindings inherited from it, "C-j" displays problematic line reported under point and "RET" jumps to it. Checks currently implemented are: - duplicates CUSTOM_ID properties - duplicate NAME values - duplicate targets - duplicate footnote definitions - orphaned affiliated keywords - obsolete affiliated keywords - missing language in src blocks - NAME values with a colon - wrong header arguments in src blocks - misuse of CATEGORY keyword - "coderef" links with unknown destination - "custom-id" links with unknown destination - "fuzzy" links with unknown destination - "id" links with unknown destination - links to non-existent local files - special properties in properties drawer - obsolete syntax for PROPERTIES drawers - missing definition for footnote references - missing reference for footnote definitions - non-footnote definitions in footnote section - probable invalid keywords - invalid blocks - probable incomplete drawers - obsolete QUOTE section Since it relies on lexical binding, `pcase' and `string-prefix-p', it cannot be added to Org 8.3, but can make it into Org 8.4, if deemed useful enough. >>> >>> This sounds very interesting and I would like to try it out. I >>> understand that it can't be put into master, but could it be put into a >>> branch? >>> >>> This would make testing a bit easier. >>> >> >> It is. The branch is called `wip-lint'. > > Thanks (also to Nicolas) - I found it. Just expected the branch to be > tracked automatically. > > This is really brilliant! > > But I now get a message in one .org file: > > , > | Org linting process starting... > | Search failed: "^[ ]*#\\+NAME: +tab:sensVar" > ` > > and no results. > > Works in other .org files. > > This one is rather long (11570 lines) and many code blocks. > > Just let me know how I can trace down where this is coming from and what > the message tells me. It seems that the error comes from the fact that ~#+LABEL: sensVar~ was defined twice. Renaming these results in working linting. Rainer > > Thanks, > > Rainer > >> >> Regards, >> Andreas >> >> -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] [RFC] Org linting library
Andreas Leha writes: > Hi Rainer, > > Rainer M Krug writes: >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> The following library implements linting for Org syntax. The sole public >>> function is `org-lint', which see. >>> >>> Internally, the library defines a new structure: `org-lint-checker', >>> with the following slots: >>> >>> - NAME: Unique check identifier, as a symbol. The check is done >>> calling the function `org-lint-NAME' with one mandatory argument, >>> the parse tree describing the current Org buffer. Such function >>> calls are wrapped within a `save-excursion' and point is always at >>> `point-min'. Its return value has to be an alist (POSITION MESSAGE) >>> when POSITION refer to the buffer position of the error, as an >>> integer, and MESSAGE is a strings describing the error. >>> >>> - DESCRIPTION: Summary about the check, as a string. >>> >>> - CATEGORIES: Categories relative to the check, as a list of symbol. >>> They are used for filtering when calling `org-lint'. Checkers not >>> explicitly associated to a category are collected in the `default' >>> one. >>> >>> - TRUST: The trust level one can have in the check. It is either `low' >>> or `high', depending on the heuristics implemented and the nature of >>> the check. This has an indicative value only and is displayed along >>> reports. >>> >>> All checks have to be listed in `org-lint--checkers'. >>> >>> Results are displayed in a special "*Org Lint*" buffer with a dedicated >>> major mode, derived from `tabulated-list-mode'. In addition to the usual >>> key-bindings inherited from it, "C-j" displays problematic line reported >>> under point and "RET" jumps to it. >>> >>> Checks currently implemented are: >>> >>> - duplicates CUSTOM_ID properties >>> - duplicate NAME values >>> - duplicate targets >>> - duplicate footnote definitions >>> - orphaned affiliated keywords >>> - obsolete affiliated keywords >>> - missing language in src blocks >>> - NAME values with a colon >>> - wrong header arguments in src blocks >>> - misuse of CATEGORY keyword >>> - "coderef" links with unknown destination >>> - "custom-id" links with unknown destination >>> - "fuzzy" links with unknown destination >>> - "id" links with unknown destination >>> - links to non-existent local files >>> - special properties in properties drawer >>> - obsolete syntax for PROPERTIES drawers >>> - missing definition for footnote references >>> - missing reference for footnote definitions >>> - non-footnote definitions in footnote section >>> - probable invalid keywords >>> - invalid blocks >>> - probable incomplete drawers >>> - obsolete QUOTE section >>> >>> Since it relies on lexical binding, `pcase' and `string-prefix-p', it >>> cannot be added to Org 8.3, but can make it into Org 8.4, if deemed >>> useful enough. >>> >> >> This sounds very interesting and I would like to try it out. I >> understand that it can't be put into master, but could it be put into a >> branch? >> >> This would make testing a bit easier. >> > > It is. The branch is called `wip-lint'. Thanks (also to Nicolas) - I found it. Just expected the branch to be tracked automatically. This is really brilliant! But I now get a message in one .org file: , | Org linting process starting... | Search failed: "^[]*#\\+NAME: +tab:sensVar" ` and no results. Works in other .org files. This one is rather long (11570 lines) and many code blocks. Just let me know how I can trace down where this is coming from and what the message tells me. Thanks, Rainer > > Regards, > Andreas > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
[O] [bug] Error evaluating table expression with relative references
Hello, I seem to have encountered a bug in table spreadsheet evaluations. See this example: #+begin_src org ,* Table evaluation with relative references | 1 | 2 | 3 | 6 | | 1 | 2 | 3 | #ERROR | ,#+TBLFM: @1$4=vsum($1..$3)::@2$4=vsum($1..$-1) #+end_src As far as I can tell, the two formulae should be equivalent? Or am I missing something silly (not unlikely ;-)? Turning on debugging shows that the first formula gets converted to vsum([1,2,3]) whereas the second goes to vsum((1)..(3)). This is with git updated a minute ago and with emacs -Q. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1154-g6ba251
Re: [O] Incomplete org-plus-contrib
Rasmus writes: >> IIUC org-eww is missing because it is not included in branch 'maint'. >> Possibly it is a good idea to put org-eww there. > > In the lisp folder, maint is typically for bug fixes. I guess for contrib > it's more flexible. So would you recommend to copy org-eww to branch maint...contrib/lisp/?
Re: [O] use of 'system in ox-odt.el
Suvayu Ali writes: > On Wed, May 20, 2015 at 11:50:03AM +0200, Rasmus wrote: >> Suvayu Ali writes: >> > >> > Do you have a mailcap which says otherwise? That's what I would suspect >> > given the doc string for org-file-apps and the default value of >> > org-file-apps-defaults-gnu on my system. >> >> I have this in my mailcap >> >> application/msword; antiword %s; >> application/pdf; evince %s; >> application/vnd.lotus-organizer; emacsclient -ca '' %s; >> application/zip file-roller %s; >> >> Org does not open my html and odt files. It does open pdf files. This is >> using emacs -q. I use Gnome 3.16 and xdg-open works as expected from the >> terminal. > > There should also be a system-wide setting in /etc/mailcap. On my > Fedora machine, the system-wide settings all look like this: > > text/html; /usr/bin/xdg-open %s ; copiousoutput > > If yours doesn't, you could override it in ~/.mailcap. If that doesn't > fix things, I'm out of ideas :-|. Now it get the message Running /usr/bin/xdg-open /tmp/test.html ...done But it doesn't actually open the file... The same happens when I mark the file in dired and says & xdg-open. From the terminal it works fine. Weird. —Rasmus -- Send from my Emacs
Re: [O] use of 'system in ox-odt.el
On Wed, May 20, 2015 at 11:50:03AM +0200, Rasmus wrote: > Suvayu Ali writes: > > > Do you have a mailcap which says otherwise? That's what I would suspect > > given the doc string for org-file-apps and the default value of > > org-file-apps-defaults-gnu on my system. > > I have this in my mailcap > > application/msword; antiword %s; > application/pdf; evince %s; > application/vnd.lotus-organizer; emacsclient -ca '' %s; > application/zip file-roller %s; > > Org does not open my html and odt files. It does open pdf files. This is > using emacs -q. I use Gnome 3.16 and xdg-open works as expected from the > terminal. There should also be a system-wide setting in /etc/mailcap. On my Fedora machine, the system-wide settings all look like this: text/html; /usr/bin/xdg-open %s ; copiousoutput If yours doesn't, you could override it in ~/.mailcap. If that doesn't fix things, I'm out of ideas :-|. GL, > May contains speling mistake > Funnny ;) -- Suvayu Open source is the future. It sets us free.
Re: [O] How to export to pdf and link to other pdf-files?
On Wed, May 20, 2015 at 11:43:13AM +0200, Rasmus wrote:
> Dov Grobgeld writes:
>
> > What do I need to do to inhibit the inclusion of pdf files as graphics
> > files, when exporting an org file to pdf?
> >
> > Ideally I would like to have links to referenced pdf files and not have
> > them treated as embedded graphics.
>
> A very quick look suggests it's hardcoded in org-latex--inline-image.
> Thus, the easiest thing may be to use a filter and be sure to include the
> pdf extension. I think you might have to use
> org-export-filter-paragraph-functions,
I think the OP can simply add a description to the links. AFAIK, links
with descriptions are exported as links during LaTeX export.
Okay I can confirm this. The following:
[[file:/tmp/foo.pdf][A link]]
is exported as:
\href{file:///tmp/foo.pdf}{A link}
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] use of 'system in ox-odt.el
Suvayu Ali writes: > Do you have a mailcap which says otherwise? That's what I would suspect > given the doc string for org-file-apps and the default value of > org-file-apps-defaults-gnu on my system. I have this in my mailcap application/msword; antiword %s; application/pdf; evince %s; application/vnd.lotus-organizer; emacsclient -ca '' %s; application/zip file-roller %s; Org does not open my html and odt files. It does open pdf files. This is using emacs -q. I use Gnome 3.16 and xdg-open works as expected from the terminal. —Rasmus -- May contains speling mistake
Re: [O] How to export to pdf and link to other pdf-files?
Dov Grobgeld writes: > What do I need to do to inhibit the inclusion of pdf files as graphics > files, when exporting an org file to pdf? > > Ideally I would like to have links to referenced pdf files and not have > them treated as embedded graphics. A very quick look suggests it's hardcoded in org-latex--inline-image. Thus, the easiest thing may be to use a filter and be sure to include the pdf extension. I think you might have to use org-export-filter-paragraph-functions, Hope it helps, Rasmus -- Dung makes an excellent fertilizer
Re: [O] Incomplete org-plus-contrib
Marco Wahl writes: > IIUC org-eww is missing because it is not included in branch 'maint'. > Possibly it is a good idea to put org-eww there. In the lisp folder, maint is typically for bug fixes. I guess for contrib it's more flexible. —Rasmus -- ⠠⠵
Re: [O] [bug] TODO [/] cookie not updating if list has inline task
Hello again, coming back to my original problem: is there a consensus on how inline tasks should be treated within lists? Inline means to me that they should not break up a list... but I would like this resolved if possible. For the moment, Rasmus's patch works for me... Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-790-gb719c1.dirty
Re: [O] Incomplete org-plus-contrib
Hi! Kaushal writes: > I was following the installation instructions on http://orgmode.org/elpa.html > > because I wanted to have the org and the contrib packages installed via the > emacs package manager. > > I installed the org-plus-contrib "package" from the package manager as > per the instructions but it is missing the org-eww.el (the very reason > I wanted to install the contrib stuff). > > But I see that org-eww.el is indeed still present in the org git: > http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp/org-eww.el > > Can you please review why that file is not present in org-plus-contrib? IIUC org-eww is missing because it is not included in branch 'maint'. Possibly it is a good idea to put org-eww there. Could you test org-eww, please? It's easy. - download http://orgmode.org/cgit.cgi/org-mode.git/plain/contrib/lisp/org-eww.el, - load it into Emacs - M-x eval-buffer - test test test When you find org-eww valuable the next step could be the merge to branch maint. Does this sound reasonable? Thanks and best regards, Marco -- GPG: 0x49010A040A3AE6F2
