Sébastien Miquel writes:
> Ihor Radchenko writes:
The traditional user-facing approach for toggling staff in export is
setting export options.
>>> Indeed. Then I suggest that such use be described in the manual.
>>> Having the user create a whole new option in order to toggle a
>>> `chi
Ihor Radchenko writes:
The traditional user-facing approach for toggling staff in export is
setting export options.
Indeed. Then I suggest that such use be described in the manual.
Having the user create a whole new option in order to toggle a
`chikenize` package seems a bit unwieldy, however.
Sébastien Miquel writes:
>> The traditional user-facing approach for toggling staff in export is
>> setting export options.
>
> Indeed. Then I suggest that such use be described in the manual.
> Having the user create a whole new option in order to toggle a
> `chikenize` package seems a bit unwie
Hi Sebastien,
> I think it would be useful to support an easy way to toggle a feature
> on and off. Either the manual should describe the best way to make a
> feature depend on a user variable (this requires using the #+BIND
> keyword, I guess), or I’d like org to support a new keyword, such as
>
Ihor Radchenko writes:
I think it would be useful to support an easy way to toggle a feature
on and off. Either the manual should describe the best way to make a
feature depend on a user variable (this requires using the #+BIND
keyword, I guess), or I'd like org to support a new keyword, such as
Sébastien Miquel writes:
> I think it would be useful to support an easy way to toggle a feature
> on and off. Either the manual should describe the best way to make a
> feature depend on a user variable (this requires using the #+BIND
> keyword, I guess), or I'd like org to support a new keyword
Hi,
Timothy writes:
Notably, I’ve now got a draft manual entry (see the last patch attached), which
should go a long way to better explaining what this is without asking you to
wade through all the code comments 😄
Thank you for sharing your work Timothy, I've been using your export
features fo
Hi All,
Following some feedback I’ve received from a few people (including off-list),
here’s a v2 set of patches.
Notably, I’ve now got a draft manual entry (see the last patch attached), which
should go a long way to better explaining what this is without asking you to
wade through all the code
Hi,
Ihor wrote:
>> Timothy writes:
>>
>> “export features” allow for the specification of qualities of the org
buffer
>> being exported that imply certain “features”, and how those features may
be
>> implemented in a particular export.
Looks like a cool "feature" that would bring some structure
often we include content in export templates that is only
relevant in
particular situations.
“export features” allow for the specification of qualities of
the org buffer
being exported that imply certain “features”, and how those
features may be
implemented in a particular export.
now `\
Timothy writes:
> “export features” allow for the specification of qualities of the org buffer
> being exported that imply certain “features”, and how those features may be
> implemented in a particular export.
>
> This is done by augmenting the backend struct with two new fields:
> `feature-cond
Hello everyone,
I’m thrilled to finally be presenting a feature that I’ve been incubating for a
while now that I call “export features”. This work is based on the observation
that often we include content in export templates that is only relevant in
particular situations.
This leaves one having t
12 matches
Mail list logo
