emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Carlos Pita <carlosjosepita@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Feature request: simplify usage of special blocks (for beamer)
Date: Sun, 2 Dec 2018 11:50:19 -0300	[thread overview]
Message-ID: <CAELgYhd4gM0OfxmvLWt8-Mv7=fj35ZEaVCFRmW+jMNtTP-zN0Q@mail.gmail.com> (raw)
In-Reply-To: <87woosw378.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

Hi Eric,

And this is where the challenge lies!  The whole point of special blocks is
> that org knows nothing of their semantics.  They are a "black box" and it
> would be difficult to identify export specific elements and general
> elements on this basis.
>

I partially agree with this just because TIL that the html backend is
already exporting special blocks as divs with an appropriate css class.

But facilitating powerful backend specific mechanisms to the user that
prefer to exploit the advantages of a particular backend, by somehow
hindering his/her ability to later export to a different format, that's
important too. And, besides backend-specific stuff, don't forget there are
user-specific extensions, as mine above, that deliberately sacrifice
generality. All this is in the best open-close spirit I would say and org
already fully embraces it by its superb backend and filter interfaces.

The same than the core parser is exposing a block "special type" it could
also expose the block "special argument" as an uninterpreted string for the
backend to interpret it. To emphasize this point: I'm not proposing that
the core parser understands the arguments to the special block but that it
passes opaque content for the backend and/or end user to process. I would
have gladly avoided that save-excursion-goto-char-re-search-forwars cruft
to focus in parsing a string cleanly passed down by the parser.

Notice that, up to this point, I've not proposed any modification to the
latex backend. But, to be honest, I see no harm in interpreting this
special argument as :options if it's well understood that, by doing so,
ability to export to another backends may be compromised. I understand this
proposal could be more controversial, tough.

So I think it's better to distinctly state the different but related
suggestions I made:

1. Mention special blocks in the beamer export documentation as an
alternative to subsectioning.

2. Make the core parser pass an :args or similar property as part of the
element for the sake of backends providing specific extensions or end users
filtering the tree to tailor the syntax to their needs, thus empowering
special blocks as an extension mechanism.

3. Make the latex backend interpret this :args property as options for the
underlying latex environment.

Best regards
--
Carlos

[-- Attachment #2: Type: text/html, Size: 2975 bytes --]

next prev parent reply	other threads:[~2018-12-02 14:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-01 16:24 Feature request: simplify usage of special blocks (for beamer) Carlos Pita
2018-12-01 18:28 ` Eric S Fraga
2018-12-01 18:41   ` Carlos Pita
2018-12-01 19:23     ` Carlos Pita
2018-12-02 11:58       ` Eric S Fraga
2018-12-02 14:50         ` Carlos Pita [this message]
2018-12-02 15:30           ` Carlos Pita
2018-12-02 20:42       ` Nicolas Goaziou
2018-12-02 21:05         ` Carlos Pita
2018-12-02 11:55     ` Eric S Fraga

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

  List information: https://www.orgmode.org/

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

  git send-email \
    --in-reply-to='CAELgYhd4gM0OfxmvLWt8-Mv7=fj35ZEaVCFRmW+jMNtTP-zN0Q@mail.gmail.com' \
    --to=carlosjosepita@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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

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).