(Feature Request) add more entry points to configure some export functionality

(Feature Request) add more entry points to configure some export functionality

[Timothy]

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

It's me again!

We're now onto email 2/4. This one is a wish-list of entry points for customising export functionality (well, styling).
I'm a big fan of trying to make my documents look snazzy with minimal work (i.e. by cramming all the snazzyness in the back-end), which is why I was thrilled to be able to make use of customisations like org-html-checkbox-types (see https://tecosaur.github.io/emacs-config/config.html#change-checkbox-type for my use of it).

However, there are a two areas where I am really interested in seeing similar customisations, ideally without the need to advice-override org functions. In the hope that these may be developed, I'll detail them below.
LaTeX Export: Checkboxes
- I also want to be able to tweak the checkboxes here.

HTML Export: Headers
- I'd quite like to customise the generation of headers
This is with the aim of adding the rather nice github-style 🔗 to easily copy a link to that position to the clipboard.
From memory modifying this would require overriding a large function, which I didn't like the look of.

Best wishes,
tecosaur

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

(Feature Request) add more entry points to configure some export functionality

[Timothy]

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

It's me again!

We're now onto email 2/4. This one is a wish-list of entry points for customising export functionality (well, styling).
I'm a big fan of trying to make my documents look snazzy with minimal work (i.e. by cramming all the snazzyness in the back-end), which is why I was thrilled to be able to make use of customisations like org-html-checkbox-types (see https://tecosaur.github.io/emacs-config/config.html#change-checkbox-type for my use of it).

However, there are a two areas where I am really interested in seeing similar customisations, ideally without the need to advice-override org functions. In the hope that these may be developed, I'll detail them below.
LaTeX Export: Checkboxes
- I also want to be able to tweak the checkboxes here.

HTML Export: Headers
- I'd quite like to customise the generation of headers
This is with the aim of adding the rather nice github-style 🔗 to easily copy a link to that position to the clipboard.
From memory modifying this would require overriding a large function, which I didn't like the look of.

Best wishes,
Timothy


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

Re: (Feature Request) add more entry points to configure some export functionality

[Nicolas Goaziou]

Hello,

Timothy <tecosaur@gmail.com> writes:

> We're now onto email 2/4. This one is a wish-list of entry points for
> customising export functionality (well, styling).

Export framework has *many* entry points already.

See (info "(org)Advanced Export Configuration")

> I'm a big fan of trying to make my documents look snazzy with minimal
> work (i.e. by cramming all the snazzyness in the back-end), which is
> why I was thrilled to be able to make use of customisations like
> org-html-checkbox-types (see
> https://tecosaur.github.io/emacs-config/config.html#change-checkbox-type
> for my use of it).
>
> However, there are a two areas where I am really interested in seeing
> similar customisations, ideally without the need to advice-override
> org functions. In the hope that these may be developed, I'll detail
> them below.
> LaTeX Export: Checkboxes
> - I also want to be able to tweak the checkboxes here.

This is trivial with an item filter.

Regards,

-- 
Nicolas Goaziou

Re: (Feature Request) add more entry points to configure some export functionality

[Timothy]

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

Hi again Nicolas,

Once again, thanks for taking the time to respond. I can assure you that it's much appreciated :)
> Export framework has *many* entry points already.
It certainly does, that's part of why I love it!

By item filter, I assume you are referring to org-export-filter-item-functions. That looks quite promising. I just tried a minimal function to testit
(defun tec/org-export-latex-fancy-item-checkboxes (text backend info)
(pp text)
"")
However, I must admit I find myself somewhat overwhelmed by the output:

I've tried applying a simple regex replace, which produces a satisfactory output though, so perhaps I'll just ignore all the 'extra stuff' above.

I still feel that it would be nicer to have the body of this cl-case (from org-latex-item) be a variable, but I'm quite happy to have a working solution!
(checkbox (cl-case (org-element-property :checkbox item)
(on "$\\boxtimes$")
(off "$\\square$")
(trans "$\\boxminus$")))
Lastly, might you be able to shed any light on the feasibility of my desire to adjust the generation of HTML headers? I'm specifically looking to insert an element like this within the <h?> ... </h?> block:m
<a id="user-content-caveats-qa-etc-etc" class="anchor" aria-hidden="true" href="#theHeaderID">(Link Icon)</a>

Thanks,
Timothy

On May 19 2020, at 3:31 pm, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello, Timothy writes: > We're now onto email 2/4. This one is a wish-list of entry points for > customising export functionality (well, styling). Export framework has *many* entry points already. See (info "(org)Advanced Export Configuration") > I'm a big fan of trying to make my documents look snazzy with minimal > work (i.e. by cramming all the snazzyness in the back-end), which is > why I was thrilled to be able to make use of customisations like > org-html-checkbox-types (see > https://tecosaur.github.io/emacs-config/config.html#change-checkbox-type > for my use of it). > > However, there are a two areas where I am really interested in seeing > similar customisations, ideally without the need to advice-override > org functions. In the hope that these may be developed, I'll detail > them below. > LaTeX Export: Checkboxes > - I also want to be able to tweak the checkboxes here. This is trivial with an item filter. Regards, -- Nicolas Goaziou


[-- Attachment #2.1: Type: text/html, Size: 3640 bytes --]

[-- Attachment #2.2: Pasted File.png --]
[-- Type: image/png, Size: 97871 bytes --]

[-- Attachment #2.3: Pasted File.png --]
[-- Type: image/png, Size: 7301 bytes --]

Re: (Feature Request) add more entry points to configure some export functionality

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

> Once again, thanks for taking the time to respond. I can assure you
> that it's much appreciated :)

You're welcome.

> By item filter, I assume you are referring to org-export-filter-item-functions. That looks quite promising. I just tried a minimal function to testit
> (defun tec/org-export-latex-fancy-item-checkboxes (text backend info)
>     (pp text)
>     "")
> However, I must admit I find myself somewhat overwhelmed by the
> output:

You asked for it, though, using `pp'.

   #("string" X Y (properties))

is just a string, with properties attached. If you simply return `text',
you will only see

  "string"

> I've tried applying a simple regex replace, which produces
> a satisfactory output though, so perhaps I'll just ignore all the
> 'extra stuff' above.

Exactly. The "extra stuff" is there for more advanced uses, when you
need information about the surrounding of the string you are going to
change.

> *
> I still feel that it would be nicer to have the body of this cl-case (from org-latex-item) be a variable, but I'm quite happy to have a working solution!
> 	 (checkbox (cl-case (org-element-property :checkbox item)
> 		     (on "$\\boxtimes$")
> 		     (off "$\\square$")
> 		     (trans "$\\boxminus$")))

Maybe. OTOH, Org has already so many variables…

> Lastly, might you be able to shed any light on the feasibility of my desire to adjust the generation of HTML headers? I'm specifically looking to insert an element like this within the <h?> ... </h?> block:m
> <a id="user-content-caveats-qa-etc-etc" class="anchor"
> aria-hidden="true" href="#theHeaderID">(Link Icon)</a>

I don't know HTML enough to help you. You may want to look into headline
and section filters.

Re: (Feature Request) add more entry points to configure some export functionality

[Timothy]

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

Nicolas,

> You asked for it, though, using `pp'.
I guess I did, didn't I 😅

> is just a string, with properties attached. If you simply return `text', you will only see "string"
Good to know, thanks :)

>> I still feel that it would be nicer to have the body of this cl-case (from org-latex-item) be a variable
> Maybe. OTOH, Org has already so many variables…
Indeed. Though my 2c on this sort of thing that the most important factor is consistency. IMO if org-html-checkbox-types exists, then an equivalent should also exist for other primary/default export backends.

> I don't know HTML enough to help you. You may want to look into headline and section filters.
Looks like this can do it for me! I still prefer doing this at-generation, but I'll take this too.

Seems to be working :) https://tecosaur.github.io/emacs-config/config.html#header-anchors
Timothy

On May 19 2020, at 5:29 pm, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Timothy writes: > Once again, thanks for taking the time to respond. I can assure you > that it's much appreciated :) You're welcome. > By item filter, I assume you are referring to org-export-filter-item-functions. That looks quite promising. I just tried a minimal function to testit > (defun tec/org-export-latex-fancy-item-checkboxes (text backend info) > (pp text) > "") > However, I must admit I find myself somewhat overwhelmed by the > output: You asked for it, though, using `pp'. #("string" X Y (properties)) is just a string, with properties attached. If you simply return `text', you will only see "string" > I've tried applying a simple regex replace, which produces > a satisfactory output though, so perhaps I'll just ignore all the > 'extra stuff' above. Exactly. The "extra stuff" is there for more advanced uses, when you need information about the surrounding of the string you are going to change. > * > I still feel that it would be nicer to have the body of this cl-case (from org-latex-item) be a variable, but I'm quite happy to have a working solution! > (checkbox (cl-case (org-element-property :checkbox item) > (on "$\\boxtimes$") > (off "$\\square$") > (trans "$\\boxminus$"))) Maybe. OTOH, Org has already so many variables… > Lastly, might you be able to shed any light on the feasibility of my desire to adjust the generation of HTML headers? I'm specifically looking to insert an element like this within the ... block:m > aria-hidden="true" href="#theHeaderID">(Link Icon) I don't know HTML enough to help you. You may want to look into headline and section filters.


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

Re: (Feature Request) add more entry points to configure some export functionality

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

As a side note, I think sending plain text messages, instead of HTML, is
better, at least on a (this?) mailing list.

> Indeed. Though my 2c on this sort of thing that the most important
> factor is consistency. IMO if org-html-checkbox-types exists, then an
> equivalent should also exist for other primary/default export
> backends.

This argument doesn't scale. There's no guarantee an equivalent is
meaningful in every export back end. E.g., what is the HTML equivalent
for `org-latex-classes', or `org-latex-default-table-environment'?

In any case, if a "consistency patrol" wants to look into export back
ends and handle "fixable" inconsistencies, why not. I assume this
requires a good knowledge in every output format so as to make sure this
is consistent everywhere.

Re: (Feature Request) add more entry points to configure some export functionality

[Timothy]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> As a side note, I think sending plain text messages, instead of HTML,
> is better, at least on a (this?) mailing list.
Good news on that front --- I didn't think my mail client did that, turns
out that it does :)

> This argument doesn't scale. There's no guarantee an equivalent is
> meaningful in every export back end. E.g., what is the HTML equivalent
> for `org-latex-classes', or `org-latex-default-table-environment'?

Oh nothing like this should be applied blindly, it just seems /somewhat/
sensible to me that if the same feature exists in two commonly used export
backends, that you'd want to either be able to configure it in both or
neither ¯\_(ツ)_/¯

> In any case, if a "consistency patrol" wants to look into export back
> ends and handle "fixable" inconsistencies, why not. I assume this
> requires a good knowledge in every output format so as to make sure this
> is consistent everywhere.

I like consistancy, but not enough to sign up for that :P

Timothy.

On May 19 2020, at 9:17 pm, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Timothy <tecosaur@gmail.com> writes:
>  
> As a side note, I think sending plain text messages, instead of HTML, is
> better, at least on a (this?) mailing list.
>  
>> Indeed. Though my 2c on this sort of thing that the most important
>> factor is consistency. IMO if org-html-checkbox-types exists, then an
>> equivalent should also exist for other primary/default export
>> backends.
>  
> This argument doesn't scale. There's no guarantee an equivalent is
> meaningful in every export back end. E.g., what is the HTML equivalent
> for `org-latex-classes', or `org-latex-default-table-environment'?
>  
> In any case, if a "consistency patrol" wants to look into export back
> ends and handle "fixable" inconsistencies, why not. I assume this
> requires a good knowledge in every output format so as to make sure this
> is consistent everywhere.
>