all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Aaron Ecay <aaronecay@gmail.com>
To: Oleh Krehel <ohwoeowho@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Conditional link export?
Date: Sat, 07 Nov 2015 14:21:37 +0000	[thread overview]
Message-ID: <87fv0hubym.fsf@gmail.com> (raw)
In-Reply-To: <87d1vmgdt6.fsf@gmail.com>

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

  reply	other threads:[~2015-11-07 14:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fv0hubym.fsf@gmail.com \
    --to=aaronecay@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ohwoeowho@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.