From: "Sébastien Miquel" <email@example.com>
To: Ihor Radchenko <firstname.lastname@example.org>
Cc: emacs-orgmode <email@example.com>
Subject: Re: [POLL] Naming of "export features"
Date: Sun, 26 Feb 2023 14:06:32 +0000 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Ihor Radchenko writes:
> Only the simplest cases of prepending/appending staff.
> If we want to splice into the normal export template, users currently
> must either write an output filter or rewrite the trnascoders
> The proposed template system will provide more flexibility to modify the
> default export transcoders.
Reading your original proposal, I see nothing that provides more
flexibility. I can guess at how it would allow one to prepend/append
stuff to the output of the default transcoder. Anything more flexible
than that would require breaking these default transcoders into parts,
which you did not originally mention.
>> Here's a couple interesting examples that currently cannot, I think.
>> + a `multicol` heading property, that wraps the content of the
>> heading in a multicol environment.
> Could you please illustrate with examples?
Exported content would be:
>> + a `nocontent` property that do not export the content of the
> This can be done with :filter-parse-tree or :filter-headline
I guess. This isn't "couple of lines"-easy though.
>> + Some way to play with the numbering of section, beyond the
>> `unumbered` property.
> Could you elaborate what kind of "play" you are referring to?
I cannot think of anything that cannot be achieved through (somewhat
fragile) post-processing with `:filter-headline`.
Anyway, I was only trying to understand if your proposal could easily
do these things. What flexibility does it bring ?
>> It is indeed unfortunate that org doesn't provide an easy way to get
>> this behaviour, and achieving it would require the fragmentation
>> (templating ?) of at least some transcoders. I'm not sure that it
>> makes sense to do this for anything other than the headings
>> transcoders, and the main template.
> Currently, transcoders are opaque functions that expose a limited number
> of pre-defined settings. Turning them into templates will allow certain
> non-standard alternations that we cannot think of in advance. Without
> directly modifying the transcoder function code.
>> However, this seems orthogonal to your previous proposal. It is not
>> clear to me how it ties with your syntax.
> Could you elaborate?
See higher. More flexibility requires breaking up some transcoders
into pieces. AFAIU it, the proposal you originally described does not
bring any more flexibility beyond what can be done through short
advices, or indeed the `:filter-` functions. I'm not sure this
dedicated syntax is preferable to advices.
next prev parent reply other threads:[~2023-02-26 14:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 17:20 [PATCH] Introduce "export features" Timothy
2023-02-11 11:37 ` Ihor Radchenko
2023-02-20 17:41 ` Timothy
2023-02-24 12:51 ` Sébastien Miquel
2023-02-24 12:59 ` Ihor Radchenko
2023-02-24 21:47 ` Sébastien Miquel
2023-02-26 12:19 ` Ihor Radchenko
2023-02-26 13:04 ` Sébastien Miquel
2023-02-27 19:05 ` Ihor Radchenko
2023-02-25 3:15 ` Timothy
2023-02-21 14:22 ` [POLL] Naming of " Timothy
2023-02-22 1:46 ` Dr. Arne Babenhauserheide
2023-02-22 2:40 ` Timothy
2023-02-23 15:55 ` No Wayman
2023-02-23 16:17 ` No Wayman
2023-02-22 12:23 ` Ihor Radchenko
2023-02-23 15:31 ` No Wayman
2023-02-23 16:04 ` Bruce D'Arcus
2023-02-23 19:04 ` Ihor Radchenko
2023-02-23 19:55 ` Sébastien Miquel
2023-02-24 10:27 ` Ihor Radchenko
2023-02-24 12:46 ` Sébastien Miquel
2023-02-24 13:03 ` Ihor Radchenko
2023-02-24 21:38 ` Sébastien Miquel
2023-02-26 12:28 ` Ihor Radchenko
2023-02-26 14:06 ` Sébastien Miquel [this message]
2023-02-27 19:32 ` Ihor Radchenko
[not found] <email@example.com>
2023-02-23 15:06 ` No Wayman
2023-03-01 8:26 Pedro Andres Aranda Gutierrez
2023-03-01 9:41 ` Ihor Radchenko
2023-03-01 11:38 ` Pedro Andres Aranda Gutierrez
2023-03-02 11:30 ` Ihor Radchenko
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 public inbox
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).