Style editing issues/questions for follow and insert processors

bdarcus commented 3 years ago

Use cases

Jane is an Ivy user who has this insert processor configured, but also wants access to csl styles.
Sam is a bibtex-actions biblatex user who wants to use this follow processor, including editing a citation style from the hydra.

Details

One issue with the org-cite design is insert processors are less modular than they could be, unless you use org-cite-make-insert-processor.

I do use it, so can separately specify functions for editing the style, and inserting the keys, and it is therefore easy for people to create an alternative that uses a different style UI.

But you don't.

Perhaps you could add an extension point to your insert processor to allow a different one be used here?

I'm totally agnostic, BTW, where a really kick-ass, general, style editing UI lives.

I am currently in the process of splitting out mine into a separate oc-bibtex-actions-insert.el file:

https://github.com/bdarcus/bibtex-actions/pull/197

But my goal is one that works well across any export processor, and which generates the previews from those export processors, so that they are always accurate, and the code is simpler to maintain.

cc @andras-simonyi

PS - I'm learning that the long-term future of the ivy module in Doom is uncertain (there's been talk of deprecating it). So it's possible I can't include the full package with the insert processor anyway. Even if so, the question is relevant more widely, and certainly to the hydra.

jkitchin commented 3 years ago

Use case

Jane is an Ivy user who has this insert processor configured, but also wants access to csl and biblatex styles.

Jane should add all the styles she wants to use to ` org-ref-cite-styles' before loading the package. I added some documentation to the readme on how to do that.

Details

One issue with the org-cite design is insert processors are less modular than they could be, unless you use org-cite-make-insert-processor.

I don't understand what you mean here. That function just returns a function. It doesn't make it more modular for users, only slightly more modular for processor authors, and that is at the expense of the way org-cite-make-insert-processor defines insertion and limitations of completing-read.

I do use it, so can separately specify functions for editing the style, and inserting the keys, and it is therefore easy for people to create an alternative that uses a different style UI.

But you don't.

Perhaps you could add an extension point to your insert processor to allow a different one be used here?

Anyone can already customize this as:

(org-cite-register-processor 'my-inserter :insert (org-cite-make-insert-processor #'my-key-selector #'org-ref-cite-select-style))

(setq org-cite-insert-processor 'my-inserter)

right? Then they can choose whatever UI they want and whatever style selector they want. The style selector sort of depends on the export processor though, at least to the extent that you can't put any old style in there; the exporter might not support it.

The org-ref-cite style selector is agnostic, so you can plug it in if you want. I don't see how to make this inserter any more agnostic or flexible than what is described above.

I'm totally agnostic, BTW, where a really kick-ass, general, style editing UI lives.

I am currently in the process of splitting out mine into a separate oc-bibtex-actions-insert.el file:

bdarcus/bibtex-actions#197

But my goal is one that works well across any export processor, and which generates the previews from those export processors, so that they are always accurate, and the code is simpler to maintain.

I feel like this is not possible. What would you do in an org-file that is going to be used for multiple exports, e.g. There will be a pdf version (via latex), an html version, an ODT version, and a plain text version. What does an accurate preview even mean? It will be different depending on the output.

cc @andras-simonyi

bdarcus commented 3 years ago

OK, I'll assume this is solvable also.

Thanks!

On this:

I feel like this is not possible. What would you do in an org-file that is going to be used for multiple exports, e.g. There will be a pdf version (via latex), an html version, an ODT version, and a plain text version. What does an accurate preview even mean? It will be different depending on the output.

The idea was just to run it to produce the plain text output, since it's not intended to be WYWIWG; more just help the user know what style to choose.

So for the TeX processors, would produce the same output as we have in our current UIs, but CSL would produce the kind of output you see in the csl-activate processor (which is also not a precise representation, and uses a default style).

The user would likely be able to choose which to display, and/or it would be auto-configured based on the export processors the user has set up.

Might even involve curated input example, to be sure to show what some of the variants (notable "full" and "caps) will produce.

jkitchin / org-ref-cite