From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleh Krehel Subject: Re: Conditional link export? Date: Sun, 08 Nov 2015 15:09:09 +0100 Message-ID: <874mgwd1mi.fsf@gmail.com> References: <87ziyri8lk.fsf@gmail.com> <878u6buupy.fsf@gmail.com> <87d1vmgdt6.fsf@gmail.com> <87fv0hubym.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvQeX-0002UD-NG for emacs-orgmode@gnu.org; Sun, 08 Nov 2015 09:09:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvQeU-0004Tb-GR for emacs-orgmode@gnu.org; Sun, 08 Nov 2015 09:09:05 -0500 Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:37185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvQeU-0004TI-66 for emacs-orgmode@gnu.org; Sun, 08 Nov 2015 09:09:02 -0500 Received: by wmww144 with SMTP id w144so12620024wmw.0 for ; Sun, 08 Nov 2015 06:09:01 -0800 (PST) Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id b1sm10194704wjx.12.2015.11.08.06.09.00 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 08 Nov 2015 06:09:00 -0800 (PST) In-Reply-To: <87fv0hubym.fsf@gmail.com> (Aaron Ecay's message of "Sat, 07 Nov 2015 14:21:37 +0000") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Aaron Ecay writes: > Extra elisp inside the org file is an important way of extending the > power of org markup. Why don=E2=80=99t 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=20 #+begin_src emacs-lisp :exports results (defun ox-link (link &optional description) (cond ((equal org-export-current-backend 'html) (format "%s" 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 
 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.ht=
ml")))

Now note that the above is meant to be exported inline, instead of into
a 
 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=E2=80=99t 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:
> 
> where many of the same themes come up.
>
> There=E2=80=99s not enough consensus at present to add any new markup typ=
es 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") =3Dpackage-install=3D.

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 "%s" 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