* Conditional link export?
@ 2015-11-06 13:02 Oleh Krehel
2015-11-06 13:24 ` Aaron Ecay
2015-11-06 13:28 ` John Kitchin
0 siblings, 2 replies; 15+ messages in thread
From: Oleh Krehel @ 2015-11-06 13:02 UTC (permalink / raw)
To: emacs-orgmode
Hi all,
I'm writing a manual in Org-mode, with the intent to export both to
Texinfo and HTML. And I'd like to use this link for Texinfo:
info:emacs#Packages
and this link for HTML:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html
They both link to the same information, but in different browsers
basically. How could this be done? I'm thinking of something like:
#ifdef TEXINFO
[[info:emacs#Packages]]
#else
[[https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html]]
#endif
Oleh
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Conditional link export? 2015-11-06 13:02 Conditional link export? Oleh Krehel @ 2015-11-06 13:24 ` Aaron Ecay 2015-11-06 13:26 ` Aaron Ecay 2015-11-07 13:05 ` Oleh Krehel 2015-11-06 13:28 ` John Kitchin 1 sibling, 2 replies; 15+ messages in thread From: Aaron Ecay @ 2015-11-06 13:24 UTC (permalink / raw) To: Oleh Krehel, emacs-orgmode Hi Oleh, One approach would be to use a parse-tree filter to change one kind of link into another. Something like the following (not tested): ,---- | (defun awe/change-info-links (tree backend _info) | (org-element-map tree 'link | (lambda (link) | (when (org-export-derived-backend-p backend 'html) | (let* ((target (org-element-property :path link)) | (parts (split-string target "#"))) | (org-element-put-property link :type "https") | (org-element-put-property | link :path | (format | "//www.gnu.org/software/emacs/manual/html_node/%s/%s.html" | (nth 0 parts) | (nth 1 parts))))))) | tree) | (add-to-list 'org-export-filter-parse-tree-functions #'awe/change-info-links) `---- This finds info links in the buffer, and converts them to http ones for html export. Exercises for the reader: - Handle the case of info links with no “#” - Link to manuals as http links in the document, and convert only the relevant http links to info links for info export. Hope this helps, -- Aaron Ecay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-06 13:24 ` Aaron Ecay @ 2015-11-06 13:26 ` Aaron Ecay 2015-11-07 13:05 ` Oleh Krehel 1 sibling, 0 replies; 15+ messages in thread From: Aaron Ecay @ 2015-11-06 13:26 UTC (permalink / raw) To: Oleh Krehel, emacs-orgmode Hi again, 2015ko azaroak 6an, Aaron Ecay-ek idatzi zuen: > > Hi Oleh, > > One approach would be to use a parse-tree filter to change one kind of > link into another. Something like the following (not tested): > > ,---- > | (defun awe/change-info-links (tree backend _info) > | (org-element-map tree 'link > | (lambda (link) > | (when (org-export-derived-backend-p backend 'html) add (equal (org-element-property :type link) "info") to the condition of the when. derp derp derp, -- Aaron Ecay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-06 13:24 ` Aaron Ecay 2015-11-06 13:26 ` Aaron Ecay @ 2015-11-07 13:05 ` Oleh Krehel 2015-11-07 14:21 ` Aaron Ecay 1 sibling, 1 reply; 15+ messages in thread From: Oleh Krehel @ 2015-11-07 13:05 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay <aaronecay@gmail.com> writes: Hi Aaron, Thanks for the effort, I might use the code you suggested as a last resort:) I think the issue here is extending the power of Org markup. The task at hand is "Write a manual in Org that exports to both Texinfo and HTML", preferably with zero config outside of the Org file itself. Also preferably without any extra Elisp inside the Org file. Is Org-mode suitable for the task? Currently I have a few questions that I had trouble internet-searching: 1. Does Org-mode support export-based #ifdef #endif escapes? Here's what I have currently: You can read about ELPA in the Emacs manual, see #+HTML: <a href="https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html">(emacs)Packages</a>. #+TEXINFO: @ref{Packages,,,emacs,}. Note that I'm getting an unwanted newline after "see" in case of HTML export that I'd like to get rid of. Even if that problem is solved, it still looks a bit clunky. Is there a way to make something like this work instead? #+begin_src elisp :inline (cond (ox-htmlp (ox-html-link "(emacs)Packages" "https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html")) (ox-texinfop (ox-texinfo-link "info:emacs#Packages"))) #+end_src 2. Does Org-mode support the kbd markup for denoting keyboard shortcuts? I'm guessing that the answer is no, which is a shame since both Texinfo and Github/StackExchange-flavored Markdown support it. Currently I've customized my Org to export =foo= as code, and ~foo~ as <kbd>foo</kbd>. Could we have this or a similar markup as the built-in default? Since Org-mode has so much to do with Emacs, having kbd tags would be very convenient. In some odd cases, ~foo~ wasn't working for me and I've had to use @@html:<kbd>@@"@@html:</kbd>@@, which looks quite ugly. 3. I really like http://orgmode.org/manual/index.html. How would I go about producing something like that (i.e. where can I find the sources)? Each time I've seen HTML export, it's always a single page. How to export each heading to its own page and have them all linked? 4. Is Org-mode powerful enough to have all of Emacs' manuals re-written in it, without any change in the final Info output? regards, Oleh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-07 13:05 ` Oleh Krehel @ 2015-11-07 14:21 ` Aaron Ecay 2015-11-07 16:23 ` Achim Gratz 2015-11-08 14:09 ` Oleh Krehel 0 siblings, 2 replies; 15+ messages in thread From: Aaron Ecay @ 2015-11-07 14:21 UTC (permalink / raw) To: Oleh Krehel, emacs-orgmode Hi Oleh, 2015ko azaroak 7an, Oleh Krehel-ek idatzi zuen: > > Aaron Ecay <aaronecay@gmail.com> writes: > > Hi Aaron, > > Thanks for the effort, I might use the code you suggested as a last > resort:) > > I think the issue here is extending the power of Org markup. > > The task at hand is "Write a manual in Org that exports to both Texinfo > and HTML", preferably with zero config outside of the Org file itself. > Also preferably without any extra Elisp inside the Org file. Is Org-mode > suitable for the task? Extra elisp inside the org file is an important way of extending the power of org markup. Why don’t you want to use it? > > Currently I have a few questions that I had trouble internet-searching: > > 1. Does Org-mode support export-based #ifdef #endif escapes? Not in general. For small pieces of text, you can use macros. Something like: #+macro: ifinfo (eval (if (org-export-derived-backend org-export-current-backend 'info) "$1" "$2")) {{{ifinfo([[info:emacs#Pachages]],[[https://....]])}}} Note that the solution I gave you allows the links to be clickable in the buffer, whereas a macro does not (sort of). (Presently links in macro arguments are clickable but not underlined/colored like links, but that’s because the buffer is parsed differently for fontification than for export. Eventually fontification will use the export parser, and then I expect macro args will no longer be able to contain clickable links.) The restrictions on what you can put inside a macro are a bit complex (I don’t claim to understand them fully myself), but approximately speaking they must occur in running text (not src blocks, the value of property drawers, #+keywords, etc) and the arguments must not contain a blank line. > Here's what I have currently: > > You can read about ELPA in the Emacs manual, see > #+HTML: <a href="https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html">(emacs)Packages</a>. > #+TEXINFO: @ref{Packages,,,emacs,}. > > Note that I'm getting an unwanted newline after "see" in case of HTML > export that I'd like to get rid of. Even if that problem is solved, it > still looks a bit clunky. > > Is there a way to make something like this work instead? > > #+begin_src elisp :inline > (cond > (ox-htmlp > (ox-html-link > "(emacs)Packages" > "https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html")) > (ox-texinfop > (ox-texinfo-link > "info:emacs#Packages"))) > #+end_src > See, even you can’t resist putting elisp in. :P You could give the your pseudocode a #+name and then call it as an inline babel call. But that would be almost exactly the same as the macro approach (but more complicated). > 2. Does Org-mode support the kbd markup for denoting keyboard shortcuts? > I'm guessing that the answer is no, which is a shame since both Texinfo > and Github/StackExchange-flavored Markdown support it. No. There was recently a thread on small caps syntax: <http://mid.gmane.org/CAN_Dec92RNWQ743SvSUa0Nam1eCYns9raitRKmJnXmF+LWDjYQ@mail.gmail.com> where many of the same themes come up. There’s not enough consensus at present to add any new markup types to org syntax. Macros can be made to serve many of the same functions, though. > > Currently I've customized my Org to export =foo= as code, and ~foo~ as > <kbd>foo</kbd>. Could we have this or a similar markup as the built-in > default? Since Org-mode has so much to do with Emacs, having kbd tags > would be very convenient. In some odd cases, ~foo~ wasn't working for > me and I've had to use @@html:<kbd>@@"@@html:</kbd>@@, which looks quite > ugly. You could use: #+macro: kbd @@html:<kbd>@@$1@@html:</kbd>@@ @@info:@kbd{@@$1@@info:}@@ @@latex:...@@ It’s long and ugly, but it works for however many backends you care to add. I left a space between the different backends for clarity; you’ll need to remove this in your actual document though. > > 3. I really like http://orgmode.org/manual/index.html. How would I go > about producing something like that (i.e. where can I find the sources)? > Each time I've seen HTML export, it's always a single page. How to > export each heading to its own page and have them all linked? AFAIK that is produced by converting a texinfo document to html using texinfo, not by org’s html exporter. There must be a way to have multi-page html documents, perhaps using ox-publish. I’m not familiar with them though. > > 4. Is Org-mode powerful enough to have all of Emacs' manuals re-written > in it, without any change in the final Info output? In a trivial sense yes, using a file consisting solely of: #+begin_info <insert contents of info file here> #+end_info Someone ported the org manual to org format in a non-trivial way a couple of years ago <http://mid.gmane.org/m1bob8cffh.fsf@tsdye.com>. It generated a lot of discussion but was never finally adopted. I believe that was due more to the difficulty in integrating the build process rather than anything wrong with the org version of the manual per se. Speed may have also been a concern, but I expect the exporter to have gotten much faster in the intervening years. Hope this is helpful, -- Aaron Ecay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-07 14:21 ` Aaron Ecay @ 2015-11-07 16:23 ` Achim Gratz 2015-11-08 14:09 ` Oleh Krehel 1 sibling, 0 replies; 15+ messages in thread From: Achim Gratz @ 2015-11-07 16:23 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay writes: > Someone ported the org manual to org format in a non-trivial way a > couple of years ago <http://mid.gmane.org/m1bob8cffh.fsf@tsdye.com>. > It generated a lot of discussion but was never finally adopted. I > believe that was due more to the difficulty in integrating the build > process rather than anything wrong with the org version of the manual > per se. Speed may have also been a concern, but I expect the exporter > to have gotten much faster in the intervening years. The build process wasn't a problem, but speed arguably still is. I still have the corresponding extension in my local.mk file (I also posted them on the list for others to re-use). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-07 14:21 ` Aaron Ecay 2015-11-07 16:23 ` Achim Gratz @ 2015-11-08 14:09 ` Oleh Krehel 2015-11-08 14:27 ` Nicolas Goaziou 2015-11-08 18:03 ` Aaron Ecay 1 sibling, 2 replies; 15+ messages in thread From: Oleh Krehel @ 2015-11-08 14:09 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay <aaronecay@gmail.com> writes: > Extra elisp inside the org file is an important way of extending the > power of org markup. Why don’t you want to use it? Including boilerplate Elisp, all subtly different into each markup document, just to extend the markup with the syntax that it should have in the first place anyway. Doesn't that sound bad to you? One-off Elisp inclusions relevant to a single document are great and powerful, but adding boilerplate code, usually more of it that the whole sum of the markup, doesn't sound great at all. This could be rectified somewhat by using `require', but then we don't have a self-contained document any more. Which is important to facilitate sharing and re-use of Org-mode documents. > Not in general. For small pieces of text, you can use macros. > Something like: > > #+macro: ifinfo (eval (if (org-export-derived-backend org-export-current-backend 'info) "$1" "$2")) > > {{{ifinfo([[info:emacs#Pachages]],[[https://....]])}}} The macro definition and call syntax looks very ugly. Why can't we add inline Elisp calls with the following rules: 1. Any amount of Elisp code can be embedded. 2. The result of the last expression is interpreted either as "%s" or "%S" appropriately. I tried this: For more package manager details, see #+begin_src emacs-lisp :exports results (defun ox-link (link &optional description) (cond ((equal org-export-current-backend 'html) (format "<a href=\"%s\">%s</a>" link (or description link))) (t link))) (cond ((equal org-export-current-backend 'texinfo+) (ox-link "info:emacs#Packages")) (t (ox-link "https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html"))) #+end_src . Here are the problems that I see here: 1. The results aren't embedded and are instead quoted. Extra newlines are added around the result. 2. Something like `ox-link' isn't built-in. 3. The boundaries are rather verbose, maybe "#+begin_src inline" or something even shorter would look better. I think fixing the above three issues would really improve Org-mode's markup, make it much more powerful. We already have `org-edit-src-code' which allows us to edit Elisp natively, it only remains to un-constrain the results from being quoted in a <pre></pre> block, and provide the standard API (e.g. `ox-link', `ox-src', `ox-tbl') that would work for all export back ends. Here's how my example would look, once the above changes are implemented: !(cl-case org-export-current-backend (texinfo+ (ox-link "info:emacs#Packages")) (t (ox-link "https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html"))) Now note that the above is meant to be exported inline, instead of into a <pre></pre> block. If I wanted such a block, I would Paredit-wrap that sexp with (ox-pre) - a very quick and simple modification. And to remove (ox-pre), simply Paredit-raise. Now this would be a powerful markup indeed. One very important advantage is that each block can be efficiently debugged in its native Elisp mode, maybe even ERT-tested, because all API functions would be bound all the time, not just during the export. > Note that the solution I gave you allows the links to be clickable in > the buffer, whereas a macro does not (sort of). I think we should completely get rid of macros and simply use inline Elisp, which is both more powerful and more simple. > See, even you can’t resist putting elisp in. :P You could give the > your pseudocode a #+name and then call it as an inline babel call. The #+name thing is powerful because if I understood correctly it allows to call /any/ language not just Elisp. As I mentioned above, I think Elisp should be privileged and we should be able to call any bound Elisp function inline without having to declare it. >> 2. Does Org-mode support the kbd markup for denoting keyboard shortcuts? >> I'm guessing that the answer is no, which is a shame since both Texinfo >> and Github/StackExchange-flavored Markdown support it. > > No. There was recently a thread on small caps syntax: > <http://mid.gmane.org/CAN_Dec92RNWQ743SvSUa0Nam1eCYns9raitRKmJnXmF+LWDjYQ@mail.gmail.com> > where many of the same themes come up. > > There’s not enough consensus at present to add any new markup types to > org syntax. Macros can be made to serve many of the same functions, > though. I see. I understand why Nicolas is reluctant to modify the actual syntax for every small thing. And macros could indeed be a solution. My issues with the macros are the following: 1. They're awkward to define. 2. They're awkward to call. Using inline Elisp instead of macros would solve both problems. The first problem is solved by having a standard library e.g. ox-inline.el bundled with Org. That would include, e.g. `ox-kbd'. Additionally the users can write their own libraries and simply `require' them. Here's how it might look like: To install a package, use !(ox-kbd "M-x") =package-install=. It doesn't look too awkward, and "C-x C-e" would still work simply inside the Org document. Here's a simple implementation of `ox-kbd': (defun ox-kbd (str) (cl-case org-export-current-backend (html (format "<kbd>%s</kbd>" str)) (texinfo+ (format "@kbd{%s}" str)) (t str))) Here's another example of the proposed inline Elisp syntax: This document's last revision is !(substring (shell-command-to-string "git rev-parse HEAD") 0 -1). It should be fairly easy to add this to the syntax, since the "!(" string is very unique, and `forward-sexp' can be used to find the ending of the inline block. I'd appreciate everyone's thoughts on the proposed addition. Best case scenario, Nicolas agrees and it's actually easy to add the new "!()" inline Elisp syntax. Mid case, everyone's indifferent and I can add the code myself. Worst case, people are opposed to this change and I'm sad. regards, Oleh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-08 14:09 ` Oleh Krehel @ 2015-11-08 14:27 ` Nicolas Goaziou 2015-11-08 14:56 ` Oleh Krehel 2015-11-08 18:03 ` Aaron Ecay 1 sibling, 1 reply; 15+ messages in thread From: Nicolas Goaziou @ 2015-11-08 14:27 UTC (permalink / raw) To: Oleh Krehel; +Cc: emacs-orgmode Hello, Oleh Krehel <ohwoeowho@gmail.com> writes: > I'd appreciate everyone's thoughts on the proposed addition. Best case > scenario, Nicolas agrees and it's actually easy to add the new "!()" > inline Elisp syntax. Mid case, everyone's indifferent and I can add the > code myself. Worst case, people are opposed to this change and I'm > sad. There is already inline syntax for any language, including elisp: src_emacs-lisp{(foo)} and, if you use the library of Babel, call_foo{} I don't see the need to add yet another way to call inline code from an Org document. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-08 14:27 ` Nicolas Goaziou @ 2015-11-08 14:56 ` Oleh Krehel 2015-11-08 15:04 ` Nicolas Goaziou 0 siblings, 1 reply; 15+ messages in thread From: Oleh Krehel @ 2015-11-08 14:56 UTC (permalink / raw) To: emacs-orgmode Hi Nicolas, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > There is already inline syntax for any language, including elisp: > > src_emacs-lisp{(foo)} > > and, if you use the library of Babel, > > call_foo{} > > I don't see the need to add yet another way to call inline code from an > Org document. Is that a new feature? First time I've heard about it, and I did google for inline code block evaluation before. In any case, the HTML export result of e.g. this: The current time is: src_emacs-lisp{(format "<a href=%S>%s</a>" "http://google.com" (format-time-string "%H:%M"))}. is: The current time is: <code><a href</code>"<a href="http://google.com/">http://google.com/</a>">15:50</a>=. which is far from what I want. And I still think that Elisp could benefit from privileged call syntax. Compare: !(foo) to src_emacs-lisp{(foo)} No one would quickly forget the first call syntax after using it once, while the second one is highly forgettable and clumsy. Additionally `org-edit-src-code' doesn't work for these blocks. regards, Oleh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-08 14:56 ` Oleh Krehel @ 2015-11-08 15:04 ` Nicolas Goaziou 2015-11-08 15:35 ` Oleh Krehel 0 siblings, 1 reply; 15+ messages in thread From: Nicolas Goaziou @ 2015-11-08 15:04 UTC (permalink / raw) To: Oleh Krehel; +Cc: emacs-orgmode Oleh Krehel <ohwoeowho@gmail.com> writes: > Is that a new feature? It is probably almost as old as Babel itself. > First time I've heard about it, and I did google > for inline code block evaluation before. You should check the Org manual first: (info "(org) Structure of code blocks") > In any case, the HTML export result of e.g. this: > > The current time is: src_emacs-lisp{(format "<a href=%S>%s</a>" "http://google.com" (format-time-string "%H:%M"))}. > > is: > > The current time is: <code><a href</code>"<a href="http://google.com/">http://google.com/</a>">15:50</a>=. > > which is far from what I want. Try The current time is: src_emacs-lisp[:results html]{(format "<a href=%S>%s</a>" "http://google.com" (format-time-string "%H:%M"))}. > And I still think that Elisp could benefit from privileged call > syntax. Compare: > > !(foo) > > to > > src_emacs-lisp{(foo)} I'm not a big fan of redundant syntax. Also, I'm trying to move Org format out of Elisp's grasp. This doesn't help much either. > Additionally `org-edit-src-code' doesn't work for these blocks. Do you want to provide a patch for it? Regards, ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-08 15:04 ` Nicolas Goaziou @ 2015-11-08 15:35 ` Oleh Krehel 2015-11-08 16:06 ` Nicolas Goaziou 0 siblings, 1 reply; 15+ messages in thread From: Oleh Krehel @ 2015-11-08 15:35 UTC (permalink / raw) To: emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Oleh Krehel <ohwoeowho@gmail.com> writes: > >> Is that a new feature? > > It is probably almost as old as Babel itself. > >> First time I've heard about it, and I did google >> for inline code block evaluation before. > > You should check the Org manual first: > > (info "(org) Structure of code blocks") OK, I was looking at http://orgmode.org/manual/Exporting-code-blocks.html instead. > >> In any case, the HTML export result of e.g. this: >> >> The current time is: src_emacs-lisp{(format "<a href=%S>%s</a>" >> "http://google.com" (format-time-string "%H:%M"))}. >> >> is: >> >> The current time is: <code><a href</code>"<a >> href="http://google.com/">http://google.com/</a>">15:50</a>=. >> >> which is far from what I want. > > Try > > The current time is: src_emacs-lisp[:results html]{(format "<a > href=%S>%s</a>" "http://google.com" (format-time-string "%H:%M"))}. This is quite restrictive, since it implies that I want to export to HTML. What I really want is to insert a raw string, with no further processing into the export, whatever format the export may have. >> And I still think that Elisp could benefit from privileged call >> syntax. Compare: >> >> !(foo) >> >> to >> >> src_emacs-lisp{(foo)} > > I'm not a big fan of redundant syntax. Also, I'm trying to move Org > format out of Elisp's grasp. This doesn't help much either. I think it's better to have people use !(foo) than to be turned away by src_emacs-lisp[:results html]{(foo)} and use nothing at all. Besides, Elisp is a very strong library for Org. We could also have e.g. #+INLINE_LANG Elisp to set the language for !() in the current document. >> Additionally `org-edit-src-code' doesn't work for these blocks. > > Do you want to provide a patch for it? I could provide a patch for `org-edit-src-code' to work with !(). I'm not interested in using the current inline syntax. I'll implement the !(progn (foo) (bar)) style for my config anyway, then it's up to you whether you'll want to merge it or not. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-08 15:35 ` Oleh Krehel @ 2015-11-08 16:06 ` Nicolas Goaziou [not found] ` <m2k2ps9x9o.fsf@andrew.cmu.edu> 0 siblings, 1 reply; 15+ messages in thread From: Nicolas Goaziou @ 2015-11-08 16:06 UTC (permalink / raw) To: Oleh Krehel; +Cc: emacs-orgmode Oleh Krehel <ohwoeowho@gmail.com> writes: > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > >> The current time is: src_emacs-lisp[:results html]{(format "<a >> href=%S>%s</a>" "http://google.com" (format-time-string "%H:%M"))}. > > This is quite restrictive, since it implies that I want to export to > HTML. What I really want is to insert a raw string, with no further > processing into the export, whatever format the export may have. Then use [:results raw]. This is also in the manual. > I think it's better to have people use !(foo) than to be turned away by > src_emacs-lisp[:results html]{(foo)} and use nothing at all. You don't have to write [:results html] or [:results raw] for every inline block you write. You can set the results per subtree, per document, or globally. So really, it boils down to: src_emacs-lisp{(foo)} You can even define a macro for that #+MACRO: eval src_emacs-lisp[:results raw]{($1)} {{{eval(foo)}}} even less characters. > Besides, Elisp is a very strong library for Org. We could also have > e.g. > > #+INLINE_LANG Elisp > > to set the language for !() in the current document. Again, having duplicate syntax is out of question, IMO. I don't think the current one is hideous either. With all due respect, the fact that you don't like it is really insufficient as a justification for introducing a special alternate syntax. >> Do you want to provide a patch for it? > > I could provide a patch for `org-edit-src-code' to work with !(). I'm > not interested in using the current inline syntax. Too bad, then. Regards, ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <m2k2ps9x9o.fsf@andrew.cmu.edu>]
[parent not found: <8737wg6zi3.fsf@nicolasgoaziou.fr>]
[parent not found: <m2ziy6vsw2.fsf@andrew.cmu.edu>]
[parent not found: <87io4tpsu2.fsf@nicolasgoaziou.fr>]
* Re: Conditional link export? [not found] ` <87io4tpsu2.fsf@nicolasgoaziou.fr> @ 2015-11-22 23:08 ` John Kitchin 0 siblings, 0 replies; 15+ messages in thread From: John Kitchin @ 2015-11-22 23:08 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode@gnu.org That gets closer! Thanks. It ends up having a duplicate link if you evaluate the inline src in the org buffer, which outputs an org-link, and then evaluate it again during the export. The :results raw keeps putting new output inline. I think I lean more towards modifying the export behavior of a link to accomplish this goal. It ends up having the same effect as far as I can tell, with shorter syntax in the org document. Nicolas Goaziou writes: > Hello, > >> I gave this a try. The idea is to have a function that exports >> differently in different backends in inline src. I don't need this, but >> I thought it would be interesting to try as it would enable one thing to >> transform to many different representations that doesn't go through the >> new link approach, filter mechanism or the derived backend mechanism. >> >> #+BEGIN_SRC emacs-lisp >> (setq org-export-babel-evaluate 'inline-only) >> >> (defun foo (arg1 arg2) >> (cond >> ((eq 'html org-export-current-backend) >> (format "<a href=\"http://some.place/%s\">%s</a>" arg1 arg2)) >> (t >> (format "[[%s:%s][%s]]" arg1 arg2 arg2)))) >> #+END_SRC >> >> src_emacs-lisp[:results raw]{(foo "info" "org")} [[info:org][org]] >> >> exports like this: >> >> <p> >> <a href="<a href="http://some.place/info">http://some.place/info</a>">org</a> <a href="org">org</a> >> </p> >> >> It looks like the angle brackets get escaped. I am not sure if there is >> a way to avoid that without a filter or additional function. Otherwise, >> it would work I think. Any thoughts? > > ":results raw" means results are inserted as raw Org text. This is the > same as writing text in an Org document before exporting it. As > a consequence, these results are escaped during the export process. > > You could wrap the results in an export snippet, e.g., > > (format "@@html:<a href=\"http://some.place/%s\">%s</a>@@" arg1 arg2) > > > Regards, -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-08 14:09 ` Oleh Krehel 2015-11-08 14:27 ` Nicolas Goaziou @ 2015-11-08 18:03 ` Aaron Ecay 1 sibling, 0 replies; 15+ messages in thread From: Aaron Ecay @ 2015-11-08 18:03 UTC (permalink / raw) To: Oleh Krehel, emacs-orgmode Hi Oleh, 2015ko azaroak 8an, Oleh Krehel-ek idatzi zuen: > > Aaron Ecay <aaronecay@gmail.com> writes: > >> Extra elisp inside the org file is an important way of extending the >> power of org markup. Why don’t you want to use it? > > Including boilerplate Elisp, all subtly different into each markup > document, just to extend the markup with the syntax that it should have > in the first place anyway. Doesn't that sound bad to you? > > One-off Elisp inclusions relevant to a single document are great and > powerful, but adding boilerplate code, usually more of it that the whole > sum of the markup, doesn't sound great at all. This could be rectified > somewhat by using `require', but then we don't have a self-contained > document any more. Which is important to facilitate sharing and re-use > of Org-mode documents. I’m not sure I understand you. You’re against putting elisp into the document, but that seems like the main thrust of your proposal. You also want self-contained documents, but insofar as these rely on new features being added to org, they will introduce dependencies on specific org versions, which is an potential obstacle to sharing and reuse. > >> Not in general. For small pieces of text, you can use macros. >> Something like: >> >> #+macro: ifinfo (eval (if (org-export-derived-backend org-export-current-backend 'info) "$1" "$2")) >> >> {{{ifinfo([[info:emacs#Pachages]],[[https://....]])}}} > > The macro definition and call syntax looks very ugly. For aesthetic considerations when editing, check out ‘org-hide-macro-markers’. I think Nicolas gave you very thorough responses to the rest of your proposal. Just a one more additional comment. [...] > 2. Something like `ox-link' isn't built-in. Thorsten Jolitz’s org-dp library might provide you a base on which to build such functions, if you’re motivated. <https://github.com/tj64/org-dp>. The readme is a little dense IMO (the docstrings are better), but you should be able to do something like: (defun ox-link (dest) (let* ((elements (split-string dest ":")) (type (nth 0 elements)) (path (mapconcat #'identity (cdr elements) ":"))) (org-dp-create 'link nil nil :type type :path path))) If you build a library of such functions and they prove useful, we could put them in org-contrib and (eventually perhaps) into core. Hope this is helpful, -- Aaron Ecay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Conditional link export? 2015-11-06 13:02 Conditional link export? Oleh Krehel 2015-11-06 13:24 ` Aaron Ecay @ 2015-11-06 13:28 ` John Kitchin 1 sibling, 0 replies; 15+ messages in thread From: John Kitchin @ 2015-11-06 13:28 UTC (permalink / raw) To: Oleh Krehel; +Cc: emacs-orgmode I would redefine the info link, and write new export functions for each backend. You will need to parse the link path for html to construct that url, but it looks easy to do. I assume # splits the info link into pieces that are useful? Alternatively, write a filter for links that only does that for links of info type. or you could directly modify org-link-protocols, e.g. #+BEGIN_SRC emacs-lisp (setf (elt (assoc "info" org-link-protocols) 2) (lambda (keyword desc format) (cond ((eq format 'html) (format "<a href=\"https://www.gnu.org/software/emacs/manual/html_node/%s/%s.html\">%s</a>" (car (s-split "#" keyword)) (car (last (s-split "#" keyword))) keyword))))) #+END_SRC This seems to make the info link into something like what you want. This way you keep the simple link syntax in org, and get what you want in other formats. Oleh Krehel writes: > Hi all, > > I'm writing a manual in Org-mode, with the intent to export both to > Texinfo and HTML. And I'd like to use this link for Texinfo: > > info:emacs#Packages > > and this link for HTML: > > https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html > > They both link to the same information, but in different browsers > basically. How could this be done? I'm thinking of something like: > > #ifdef TEXINFO > [[info:emacs#Packages]] > #else > [[https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html]] > #endif > > Oleh -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-11-22 23:09 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-06 13:02 Conditional link export? Oleh Krehel
2015-11-06 13:24 ` Aaron Ecay
2015-11-06 13:26 ` Aaron Ecay
2015-11-07 13:05 ` Oleh Krehel
2015-11-07 14:21 ` Aaron Ecay
2015-11-07 16:23 ` Achim Gratz
2015-11-08 14:09 ` Oleh Krehel
2015-11-08 14:27 ` Nicolas Goaziou
2015-11-08 14:56 ` Oleh Krehel
2015-11-08 15:04 ` Nicolas Goaziou
2015-11-08 15:35 ` Oleh Krehel
2015-11-08 16:06 ` Nicolas Goaziou
[not found] ` <m2k2ps9x9o.fsf@andrew.cmu.edu>
[not found] ` <8737wg6zi3.fsf@nicolasgoaziou.fr>
[not found] ` <m2ziy6vsw2.fsf@andrew.cmu.edu>
[not found] ` <87io4tpsu2.fsf@nicolasgoaziou.fr>
2015-11-22 23:08 ` John Kitchin
2015-11-08 18:03 ` Aaron Ecay
2015-11-06 13:28 ` John Kitchin
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).