Conditional link export?

Conditional link export?

[Oleh Krehel]

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

Re: Conditional link export?

[Aaron Ecay]

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

Re: Conditional link export?

[Aaron Ecay]

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

Re: Conditional link export?

[Oleh Krehel]

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

Re: Conditional link export?

[Aaron Ecay]

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

Re: Conditional link export?

[Achim Gratz]

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

Re: Conditional link export?

[Oleh Krehel]

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

Re: Conditional link export?

[Nicolas Goaziou]

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

Re: Conditional link export?

[Oleh Krehel]

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>&lt;a href</code>"<a href="http://google.com/">http://google.com/</a>"&gt;15:50&lt;/a&gt;=.

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

Re: Conditional link export?

[Nicolas Goaziou]

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>&lt;a href</code>"<a href="http://google.com/">http://google.com/</a>"&gt;15:50&lt;/a&gt;=.
>
> 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,

Re: Conditional link export?

[Oleh Krehel]

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>&lt;a href</code>"<a
>> href="http://google.com/">http://google.com/</a>"&gt;15:50&lt;/a&gt;=.
>>
>> 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.

Re: Conditional link export?

[Nicolas Goaziou]

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,

Re: Conditional link export?

[John Kitchin]

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>
>> &lt;a href="<a href="http://some.place/info">http://some.place/info</a>"&gt;org&lt;/a&gt; <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

Re: Conditional link export?

[Aaron Ecay]

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

Re: Conditional link export?

[John Kitchin]

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