babel default header args as functions
I've added the ability in my own configuration to use lambda functions that evaluate to a string as babel default header arguments, instead of just the plain strings currently allowed. Would anyone else be interested in this feature? Shall I prepare a patch? There are a number of use cases for this, but to give you an idea, here's one I'm using myself. (setq org-babel-default-header-args:latex `((:file . (lambda () (concat "img/" (sha1 (org-element-property :value (org-element-at-point))) (by-backend '((html . "-html") (t . "-org"))) ".svg") This computes a filename based on the hash of the block contents. Matt
babel comma escape with :wrap
There appears to be no way to disable the comma escape when using :wrap
for a babel source block.
I'm essentially trying to replicate this example from the manual
#+NAME: attr_wrap
#+BEGIN_SRC sh :var data="" :var width="\\textwidth" :results output
echo "#+ATTR_LATEX: :width $width"
echo "$data"
#+END_SRC
#+HEADER: :file /tmp/it.png
#+BEGIN_SRC dot :post attr_wrap(width="5cm", data=*this*) :results drawer
digraph{
a -> b;
b -> c;
c -> a;
}
#+end_src
#+RESULTS:
:RESULTS:
#+ATTR_LATEX :width 5cm
[[file:/tmp/it.png]]
:END:
But, my result type is a link not a drawer (which are mutually
exclusive). So, to get the same wrapping effect, I need to use the :wrap
argument. However, the comma escape negates attr_wrap's effect with this
code
(let ((wrap
(lambda (start finish no-escape no-newlines
inline-start inline-finish)
(when inline
(setq start inline-start)
(setq finish inline-finish)
(setq no-newlines t))
(let ((before-finish (copy-marker end)))
(goto-char end)
(insert (concat finish (unless no-newlines "\n")))
(goto-char beg)
(insert (concat start (unless no-newlines "\n")))
(unless no-escape
(org-escape-code-in-region
(min (point) before-finish) before-finish))
(goto-char end
[...]
But, since this file uses lexical binding (as it should) there appears
to be no way to set no-escape. I searched through the changelog a bit
and that seems to be a relic from an old version. At the very least,
that no-escape conditional should be made unconditional. However, I do
think there should be a way to avoid the comma escape, but I'm not sure
of the best way to do it. I'm more than happy to write the code, but I'm
curious what people think would be the best way to do it.
Maybe :wrap could take a special keyword argument (e.g. no-escape) that
would stop the effect. Thoughts?
Best,
Matt
babel link bug
The patch below fixes a bug with the behavior of link without file for babel source blocks. All explained in patch message, but let me know if any concerns. >From 25d363bbc3cd7122287364f25f9b5d653bcae232 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Fri, 7 Feb 2020 23:09:48 -0800 Subject: [PATCH] ob-core.el: fix silent ouput of babel link format Cc: emacs The file type and link format are distinct according to the manual. Previous code required file type in order for link to work. This is distinct from the file header argument that is required for link to work. To see why this is a bug, try the code under link in the manual #+begin_src shell :results link :file "download.tar.gz" wget -c "http://example.com/download.tar.gz; #+end_src This will download the file but will not generate any results. --- lisp/ob-core.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 1a0122192..53168edc8 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -709,8 +709,7 @@ block." (not (listp r))) (list (list r)) r))) - (let ((file (and (member "file" result-params) - (cdr (assq :file params) + (let ((file (cdr (assq :file params ;; If non-empty result and :file then write to :file. (when file ;; If `:results' are special types like `link' or -- 2.25.0
Re: Bug: org-latex--format-spec does not support documented SUBTITLE/%s substitution [9.3.4 (9.3.4-elpa @ /home/seth/.emacs.d/elpa/org-20200206/)]
Hi Seth, I applied your change on the maint branch: https://code.orgmode.org/bzg/org-mode/commit/7e4e34db Thanks! -- Bastien
Re: A few changes to test in master
Hi Jack, Jack Kamm writes: > Hmm, I'm experience the problem worse now -- the header is always > getting stuck on the first row it appears on. Also, I'm seeing the > follow error in my *Messages*: A silly oversight on my side (I need a little break.) Fixed. > Sure, see the patch below. Applied, thanks! -- Bastien
Re: A few changes to test in master
Hi Bastien, Bastien writes: >> I have noticed a new bug, where the header line randomly gets "stuck" >> on some row of the table, so even when I scroll and that row is no >> longer on top of the buffer, that row is still replaced by the header >> line. > > Yes, fixed now. Hmm, I'm experience the problem worse now -- the header is always getting stuck on the first row it appears on. Also, I'm seeing the follow error in my *Messages*: Error in post-command-hook (org-table-header-set-header): (error "Invalid or uninitialized timer") >> Thanks. The default face looks great on light-themed backgrounds like >> leuven, but is hard to read on some dark-themed backgrounds like >> tsdh-dark or zenburn, due to their light text. Maybe the simplest >> solution would be to set both the background and foreground colors in >> the default face? > > Sure - would you like to suggest a patch for this? Sure, see the patch below. >From 2922d104b3508b1269c17ad0a28103bd912e308b Mon Sep 17 00:00:00 2001 From: Jack Kamm Date: Fri, 7 Feb 2020 18:04:59 -0800 Subject: [PATCH] org-faces.el: Add foreground color to org-table-header face * lisp/org-faces.el (org-table-header): Add foreground color to org-table-header face, to ensure readability when using a dark theme. --- lisp/org-faces.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org-faces.el b/lisp/org-faces.el index d50f715cc..d78b606ec 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -364,7 +364,9 @@ changes." "Face used for tables." :group 'org-faces) -(defface org-table-header '((t :inherit org-table :background "LightGray")) +(defface org-table-header '((t :inherit org-table + :background "LightGray" + :foreground "Black")) "Face for table header." :group 'org-faces) -- 2.25.0
Re: org-babel strange html print in R
Hi Jeremie, > Thanks for the info. > Unfortunately I couldn't identify the issue > I updated R and org (org 9.3.2, R 3.6.2). > but I'm still getting [the error] Sorry, I missed the initial property line where you set the ":session" header argument. When I set the ":session" header argument, I get the original buggy behavior that you report. It looks like the reason for this, is that the substrings like "tr>" match `comint-prompt-regexp', and so get stripped out by `org-babel-comint-with-output'. I think a more reliable implementation would be to avoid `org-babel-comint-with-output', and take the approach used in the ":results value" case, which reads the output from a temp file instead of directly from the shell. Actually, that's the approach I use in my ob-session-async package [0], which re-implements ob-R sessions to allow async evaluation. It doesn't suffer from the bug you are reporting. I'll plan to extract that implementation and submit it as a patch here. Long term, I am intending to contribute the full functionality in ob-session-async here, but that's still a ways off. [0] https://github.com/jackkamm/ob-session-async Jack
Re: org-babel strange html print in R
Hello, Jack Kamm writes: > Dominique Dumont writes: > >> On my system, org-mode 3.6.1 provides the expected table. > > My system produces the expected table as well (org 9.3.2, R 3.6.2). > > --Jack Thanks for the info. Unfortunately I couldn't identify the issue I updated R and org (org 9.3.2, R 3.6.2). launched > emacs -Q - executed the following commands (add-to-list 'load-path "/home/djj/.emacs.d/elpa/ess-20200115.225") (add-to-list 'load-path "/home/djj/.emacs.d/elpa/julia-mode-20180816.2117") (require 'ess-site) (org-babel-do-load-languages 'org-babel-load-languages '( (R . t) )) but I'm still getting #+begin_src R :results output :cache no :session "R2" library(xtable) x <- rnorm(100) y <- x + rnorm(100) a <- summary(lm(y ~ x)) print(xtable(a),type="html") #+end_src #+RESULTS: #+begin_example < < < < #+end_example Best regards, Jeremie
[org-inlinetask] Inquiry of opinion from all users
Hi, while org-superstar-mode (a minor mode that prettifies org headlines and item bullets, see https://github.com/dw-github-mirror/org-superstar-mode) is awaiting it's debut on MELPA, I am currently doing a few more touch-ups to ensure quality. While I am working on providing proper unit tests, I thought I may take the time to ask a few questions to all people interested using org-inlinetask: 1) Would you like a mode prettifying header bullets to honor org-inlinetask-show-first-star? 2) If yes, would you like to have the leading character depend on the inlinetask's level (or rather, the level it would have had as a headline), or would you prefer a fixed character, for example, a Dingbat? 3) Header bullets cycle through a user defined list of bullets. Should the pair of header bullets (the trailing two stars) be displayed by the level they would have as headlines? For example, suppose your headeline bullets would cycle through (1), (2), (3), (4). Now suppose org-inlinetask-min-level was 6. Should ** be rendered as (1)(1) (that is, as the *first* inlinetask) or (2)(2) (that is, like a level 6 (mod 4) headline)? Thank you in advance, D.
Src blocks laid out side-by-side
I have a need to lay out source blocks side by side, in order to present before and after changes to the source. If I could embed a block in a table, that would do it. Is there another obvious way that I'm missing? Hilight etc is important, but also actually compiling the code to maintain correctness. https://isocpp.org/files/papers/D1988R1.html Has an example at the top. That's done with pandoc markdown with a bunch of post processing. I'd like to go back to org.
Re: How to intersperse commands with their output in RESULTS block?
Hi Adam and Eric for your further comments! I had read a bit about the =rx= package but not used it, thanks for the pointer to =xr=, makes it a lot easier to figure out the syntax. One more thing I realized is that I can make the desired settings the defaults within my document, and even automatically wrap all blocks with the =script= command, by setting the corresponding properties: #+property: header-args:sh+ :exports output #+property: header-args:sh+ :results output #+property: header-args:sh+ :wrap "src console" #+property: header-args:sh+ :post cleanup(data=*this*) #+property: header-args:sh+ :prologue "script < wrote: > Diego Zamboni writes: > > > I came up with the following block, which cleans up all the cruft from > > the output of the =script= command and produces a nicely formatted > > session transcript: > > > > #+NAME: cleanup > > #+BEGIN_SRC emacs-lisp :var data="" :results value :exports none > > (replace-regexp-in-string > >"\\$ exit\\(.\\|\n\\)*$" "" > >(replace-regexp-in-string > > "^bash-.*\\$" "$" > > (replace-regexp-in-string > > "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" "" > > (replace-regexp-in-string " > > " "" data) nil nil 1))) > > #+END_SRC > > > > (I am not happy with the regexp nesting and repetition above, I am not > > an expert yet in emacs-lisp regex facilities. Suggestions appreciated > > for how to simplify it). > > Hi Diego, > > A few suggestions: > > 1. You can use `rx' to define regexps in a Lispy way, and the ELPA > package `xr' converts existing regexp strings to the rx format, which > can help in learning rx syntax. For example: > > (xr "^bash-.*\\$" 'brief) ;;=> (seq bol "bash-" (0+ nonl) "$") > > So you can use that regexp like: > > (replace-regexp-in-string (rx bol "bash-" (0+ nonl) "$") ...) > > This nasty one is much easier with rx: > > (xr "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" 'brief) > ;;=> > ;; (seq (group (*? (group anything))) > ;; "$" (0+ (group anything)) eos) > > 2. To avoid the nested calls, you can use a loop, like: > > (cl-loop for (match replace) in >(list (list (rx foo bar) "replacement")) >do (setf string > (replace-regexp-in-string match replace > string))) > > >
Bug: org-latex--format-spec does not support documented SUBTITLE/%s substitution [9.3.4 (9.3.4-elpa @ /home/seth/.emacs.d/elpa/org-20200206/)]
org-latex-title-command does not honor the document SUBTITLE or %s substitution, and throws an error invalid format character %s. Investigation showed that org-latex--format-spec did not have an entry for %s. Making the obvious change appeared to resolve the issue: #+BEGIN_SRC emacs-lisp --- ox-latex.el~2020-02-07 13:59:34.804141887 -0500 +++ ox-latex.el 2020-02-07 14:00:18.836895973 -0500 @@ -1586,6 +1586,7 @@ lang `((?a . ,(org-export-data (plist-get info :author) info)) (?t . ,(org-export-data (plist-get info :title) info)) + (?s . ,(org-export-data (plist-get info :subtitle) info)) (?k . ,(org-export-data (org-latex--wrap-latex-math-block (plist-get info :keywords) info) info)) #+END_SRC Emacs : GNU Emacs 26.3 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.13) of 2019-12-10 Package: Org mode version 9.3.4 (9.3.4-elpa @ /home/srobertson/.emacs.d/elpa/org-20200206/)
Re: commit "328c9a1af * bad org.el: Enhance menus" caused error
Hi Stardiviner, I fixed this in master, thanks for reporting this bug. Best, -- Bastien
Re: A few changes to test in master
Hi Jack, Jack Kamm writes: > FWIW, I wouldn't mind if this were a global minor mode, I intend to > activate it globally with `org-table-header-line-p'. Well, it only makes sense in org buffers, so activating it through this variable is okay IMO. > Since updating and testing for a few minutes, I haven't noticed this > issue anymore. However, I have noticed a new bug, where the header line > randomly gets "stuck" on some row of the table, so even when I scroll > and that row is no longer on top of the buffer, that row is still > replaced by the header line. Yes, fixed now. >> M-x customize-face RET org-table-header RET > > Thanks. The default face looks great on light-themed backgrounds like > leuven, but is hard to read on some dark-themed backgrounds like > tsdh-dark or zenburn, due to their light text. While this could be left > to the user or individual themes to fix, it'd be nice if it worked out > of the box for the common dark themes. Maybe the simplest solution would > be to set both the background and foreground colors in the default > face? Sure - would you like to suggest a patch for this? -- Bastien
Re: How to intersperse commands with their output in RESULTS block?
Diego Zamboni writes: > I came up with the following block, which cleans up all the cruft from > the output of the =script= command and produces a nicely formatted > session transcript: > > #+NAME: cleanup > #+BEGIN_SRC emacs-lisp :var data="" :results value :exports none > (replace-regexp-in-string >"\\$ exit\\(.\\|\n\\)*$" "" >(replace-regexp-in-string > "^bash-.*\\$" "$" > (replace-regexp-in-string > "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" "" > (replace-regexp-in-string " > " "" data) nil nil 1))) > #+END_SRC > > (I am not happy with the regexp nesting and repetition above, I am not > an expert yet in emacs-lisp regex facilities. Suggestions appreciated > for how to simplify it). Hi Diego, A few suggestions: 1. You can use `rx' to define regexps in a Lispy way, and the ELPA package `xr' converts existing regexp strings to the rx format, which can help in learning rx syntax. For example: (xr "^bash-.*\\$" 'brief) ;;=> (seq bol "bash-" (0+ nonl) "$") So you can use that regexp like: (replace-regexp-in-string (rx bol "bash-" (0+ nonl) "$") ...) This nasty one is much easier with rx: (xr "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" 'brief) ;;=> ;; (seq (group (*? (group anything))) ;; "$" (0+ (group anything)) eos) 2. To avoid the nested calls, you can use a loop, like: (cl-loop for (match replace) in (list (list (rx foo bar) "replacement")) do (setf string (replace-regexp-in-string match replace string)))
Re: How to intersperse commands with their output in RESULTS block?
On Friday, 7 Feb 2020 at 16:26, Diego Zamboni wrote: > Quick follow up about this: following Eric's suggestion, I came up with the > following block, which cleans up all the cruft from the output of the > =script= command and produces a nicely formatted session transcript: You might like to add "--quiet" to the =script= command to reduce some of the cruft. Otherwise, I'm glad you got something working! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: A few changes to test in master
Hi Bastien, Bastien writes: >> The variable `org-table-header-line-p' doesn't seem to have any effect >> for me, I find that I need to call "M-x org-table-header-line-mode" even >> when it's set. > > Should be fixed now. Confirmed, it works correctly for me now. >> Also, "M-x org-table-header-line-mode" seems to activate the minor mode >> globally > > Well, I tried various things and I didn't fix this one. Perhaps this > is due to the special display of the header line. I will continue to > look for a solution. FWIW, I wouldn't mind if this were a global minor mode, I intend to activate it globally with `org-table-header-line-p'. >> If I am in a table, and scroll-up-command brings me out of the table, >> then the header of the table still sits on top of the window immediately >> after scrolling. This gets fixed as soon as any action is taken >> (e.g. moving the cursor or hitting C-g). > > Yes, this happened to me sometimes. I think I enhanced the situation > a bit here, but I can't tell for 100% sure. Please test and report. Since updating and testing for a few minutes, I haven't noticed this issue anymore. However, I have noticed a new bug, where the header line randomly gets "stuck" on some row of the table, so even when I scroll and that row is no longer on top of the buffer, that row is still replaced by the header line. This bug happens infrequently, and I haven't figured out how to consistently reproduce yet. I noticed this happening when I was scrolling up and down many times past the same table, and also switching themes. >> It would be nice if the header row was a little more visually >> distinguishable from the other table rows (maybe by adding an underline >> to that row?) > > Good idea, done - you can now customize the face: > > M-x customize-face RET org-table-header RET Thanks. The default face looks great on light-themed backgrounds like leuven, but is hard to read on some dark-themed backgrounds like tsdh-dark or zenburn, due to their light text. While this could be left to the user or individual themes to fix, it'd be nice if it worked out of the box for the common dark themes. Maybe the simplest solution would be to set both the background and foreground colors in the default face?
Re: org link to OCaml comment
On 2020-02-07 15:33, Nicolas Goaziou writes: > *shivers* Please never suggest again url-encoding links in Org! ;) We > only got out of this hell recently. I don't want to dive in again. Sorry, I should have put a smiley there. > There is some specific syntax in links. More specifically, the > following are meaningful: > > - a star at the beginning of the link (or search option) > - a hash at the beginning of the link > - forward slashes around the link > - parenthesis around the link > > I think that `org-store-link' should be careful about it and prevent > these pathological cases if necessary. > > In any other situation, however, I think the user is responsible for > not using these specific constructs. > > WDYT? I understand, and I can be careful (and easily fix the link if needed). If `org-store-link' could do it for me, that would be perfect. Thanks again for the explanation. Best, Alan
Re: How to intersperse commands with their output in RESULTS block?
Hi everyone, Quick follow up about this: following Eric's suggestion, I came up with the following block, which cleans up all the cruft from the output of the =script= command and produces a nicely formatted session transcript: #+NAME: cleanup #+BEGIN_SRC emacs-lisp :var data="" :results value :exports none (replace-regexp-in-string "\\$ exit\\(.\\|\n\\)*$" "" (replace-regexp-in-string "^bash-.*\\$" "$" (replace-regexp-in-string "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" "" (replace-regexp-in-string " " "" data) nil nil 1))) #+END_SRC (I am not happy with the regexp nesting and repetition above, I am not an expert yet in emacs-lisp regex facilities. Suggestions appreciated for how to simplify it). This produces exactly the result I need: #+begin_src sh :exports output :results output :wrap "src console" :post cleanup(data=*this*) script < wrote: > Hi Eric, > > Great idea! I hadn't considered using the =script= command, it's a great > starting point. > > Thanks! > --Diego > > > On Thu, Feb 6, 2020 at 7:55 AM Fraga, Eric wrote: > >> On Wednesday, 5 Feb 2020 at 18:25, Diego Zamboni wrote: >> > tl;dr: is there a way to have ob-shell (or some similar mode) run >> commands >> > one by one and include the commands, interspersed with their output, in >> the >> > #+RESULTS block? >> >> You haven't said on what type of system but, if Linux, you could try >> using =script= as a starting point: >> >> #+begin_src shell :results output >> script <> ls >> echo 'hello' >> EOF >> #+end_src >> >> You may wish to have a second shell script that massages the output in >> the =typescript= file and ouputs that instead, e.g. to filter the >> carriage returns. >> -- >> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48 >> >
Re: org-babel strange html print in R
On Friday, 7 February 2020 14:38:53 CET Bastien wrote: > This seems to be a *very* version of org-mode ;) Bummer... I remember that I've used org-version to get the version number. I guess I have cut'n'pasted an unrelated number :-/ For the record, I've tested R and html output on Org mode version 9.3.1 Sorry for the confusion. All the best Dod
Re: org-babel strange html print in R
Dominique Dumont writes: > On my system, org-mode 3.6.1 provides the expected table. My system produces the expected table as well (org 9.3.2, R 3.6.2). --Jack
Re: org link to OCaml comment
Hello, Alan Schmitt writes: > Thank you for the explanation. Is there a way to either escape the > parentheses (maybe url-encode them), *shivers* Please never suggest again url-encoding links in Org! ;) We only got out of this hell recently. I don't want to dive in again. > or to automatically not include the closing one as you suggest when > creating the link? There is some specific syntax in links. More specifically, the following are meaningful: - a star at the beginning of the link (or search option) - a hash at the beginning of the link - forward slashes around the link - parenthesis around the link I think that `org-store-link' should be careful about it and prevent these pathological cases if necessary. In any other situation, however, I think the user is responsible for not using these specific constructs. WDYT? Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Hmm, maybe that is so.. Except raw-path is called path (not really an > issue though) and there is another property called raw-link. Not sure > how to interpret the use of both path and raw-link. And there are > things happening between parsing the actual buffer link and storing > the raw-link and path parameters. There is some normalization involved, indeed. The intent of :raw-link is to provide the link almost as it was in the buffer, without any parsing. I agree there should not be any `org-link-unescape' and `org-link-expand-abbrev' involved there. Something to fix at some point. :path, on the contrary is parsed. It is the part of the link between the type and the search options, i.e., [[type:path::search]], [[type:path]], or [[path]]. > In the end, what made me consider the sub-typing I've been writing > about could very well just have been the ambiguities regarding what's > what, and the lack of treatment for parts that arguably could be seen > as additional parameters to the link-path. For example the > "::extra_content" suffix in file links, that by the parser currently > is just a part of the path itself. In [[file:name::extra_content]] :path is "name", and :search-option is "extra_content". As you noted, :search-option is not valid in non-file links, so it belongs to the path. It seems there is some friction about this search option part. IIUC, you want attachment links to support this link-specific syntax. This is indeed not possible. As I commented earlier, letting libraries decide what the parser should do is not an option. There are a few options, though: 1. Allow every link with an explicit type (i.e., not internal links) to have a search option, so you can write [[docview:filename::12]] or [[attachment:filename::*Section 2]]. IMO this is a waste, because most links do not need this, and it could become confusing [[https:www.orgmode.org::#sec2]]. 2. Provide a function in "ol.el" to do the parsing for you, so that every new link library doesn't have to re-invent the wheel. E.g., (org-link-extract-search-options "foo::bar") => (:path "foo" :search-options "bar"). 3. Keep that way, i.e., any link library requiring to read the search part can do a dumb `match-string` and, in two or three lines of code, extract it. IOW, since this is so trivial, why bother? WDYT? > Maybe clearer documentation in the function of what each part is > /supposed/ to be, and the design principle that is applied, i.e. that > the path is the raw path with options included can help future me and > others who might want to understand. Thoughts on that? There is some information in the manual, and the Org Syntax document. > Hmm, don't really know if a link description should be regarded as > content. I for one hadn't considered it until now when you mentioned > it! But it preserves space in the parse tree I suppose. This is unrelated to the size of the parse tree. A description may contain Org specific markup, e.g., bold, so it needs to be parsed further. Therefore, a link with a description is not a leaf: it has contents. > If the docstring of the link parser would make it clear what each > property is supposed to contain, in this case :contents-begin > & :contents-end, I'm sure I would have been less confused about this, > and wouldn't have had any objections. A docstring is not a manual. I explained this in the Org Element API documentation, IIRC. > Ok, got it. You're saying the link interpreter for docview (in this > case) have to be able to parse the link one step further, to be able > to extract this ":go-to-page" information, before being able to > operate on it. Indeed a design decision. Maybe the best one, who am > I to say otherwise. It will make the Org link parser leaner for sure. Sarcasm? My opinion is the library defining the Org syntax should be a fixed point. It is important that the output of the parser does not depend on what libraries are currently loaded. It guarantees that if we both open the same document, we'll get the same parse tree. Of course, this is not exactly true at the moment. For example, we may not have the same TODO keywords, or the same item list separator. Nevertheless, I see no reason to diverge further from this goal. > Not sure about location. Maybe ol.el? What I'm talking about is > a higher order function for the :export property within > org-link-parameters. File link exporting would then have to be > declared using org-link-set-parameters, just as other link types are > supposed to be declared for exporting. See above about my suggestion of a generic tool. >> As suggested already (I think) we could add a phase in ox.el that would >> expand attachment links into their file link counterpart automatically. >> This would avoid adding specific code in every export back-end. However, >> export back-end would miss the opportunity to handle attachment links >> specifically. This is one way or the
Re: org-babel strange html print in R
Hi Dominique, Dominique Dumont writes: > On Thursday, 6 February 2020 19:23:36 CET Jeremie Juste wrote: >> I've found that some strange results when outputing html from R. >> Do you have some insights on a potential solution? > > On my system, org-mode 3.6.1 This seems to be a *very* version of org-mode ;) -- Bastien
Re: org-babel strange html print in R
On Thursday, 6 February 2020 19:23:36 CET Jeremie Juste wrote: > I've found that some strange results when outputing html from R. > Do you have some insights on a potential solution? On my system, org-mode 3.6.1 provides the expected table. All the best
