From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlos Pita Subject: Re: Feature request: simplify usage of special blocks (for beamer) Date: Sun, 2 Dec 2018 11:50:19 -0300 Message-ID: References: <87a7lpxfsc.fsf@gmail.com> <87woosw378.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000076dc05057c0b277a" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTT4s-000432-KO for emacs-orgmode@gnu.org; Sun, 02 Dec 2018 09:50:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTT4r-0002vR-74 for emacs-orgmode@gnu.org; Sun, 02 Dec 2018 09:50:34 -0500 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]:34852) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gTT4r-0002uy-1x for emacs-orgmode@gnu.org; Sun, 02 Dec 2018 09:50:33 -0500 Received: by mail-yb1-xb29.google.com with SMTP id z2-v6so4275490ybj.2 for ; Sun, 02 Dec 2018 06:50:33 -0800 (PST) In-Reply-To: <87woosw378.fsf@gmail.com> 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" To: emacs-orgmode@gnu.org --00000000000076dc05057c0b277a Content-Type: text/plain; charset="UTF-8" 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 --00000000000076dc05057c0b277a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

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

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

But facilitati= ng powerful backend specific mechanisms to the user that prefer to exploit = the advantages of a particular backend, by somehow hindering his/her abilit= y to later export to a different format, that's important too. And, bes= ides backend-specific stuff, don't forget there are user-specific exten= sions, as mine above, that deliberately sacrifice generality. All this is i= n 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=20 exposing a block "special type" it could also expose the block=20 "special argument" as an uninterpreted string for the backend to= =20 interpret it. To emphasize this point: I'm not proposing that the core= =20 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 gl= adly 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 p= roposed 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 und= erstood that, by doing so, ability to export to another backends may be com= promised. I understand this proposal could be more controversial, tough.

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

1. Mentio= n special blocks in the beamer export documentation as an alternative to su= bsectioning.

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

3. Make the latex backend interpret this :arg= s property as options for the underlying latex environment.

<= /div>Best regards
--
Carlos
--00000000000076dc05057c0b277a--