Key bindings for Org export back-ends?

Key bindings for Org export back-ends?

[Jens Lechtenboerger]

Hi there,

I need to assign a key to an Org export back-end.  My first attempt
ended in a conflict, so I’d like to collect a (full?) list.

Built-in
- iCalendar: c
- HTML: h
- Texinfo: i
- LaTeX and Beamer: l
- Man: M
- Markdown: m
- ODT: o
- Org: O
- Publish: P
- Plain text: t

Contrib (ox-bibtex, ox-extra, ox-confluence without keys):
- Deck.js: d
- Freemind: f
- Groff: g
- Taskjuggler: J
- KOMA: k
- RSS: r
- s5: s

Other:
- ox-hugo [1]: H
- org-opml [2]: m (conflict with Markdown)
- org-reveal [3]: R
- org-re-reveal [4]: r (conflict with RSS)
- ox-rst [5]: r (conflict with RSS)
- ox-slimhtml [6]: s (conflict with s5)

So, these keys are taken:
c, d, f, g, h, H, i, J, k, l, M, m, o, O, P, R, r, s, t

Besides, SPC, DEL, C-a, C-b, C-f, C-n, C-p, C-s, C-v are taken.

Anyone with additional back-ends and keys?  Where could we document
the resulting list?

I’m thinking of changing org-re-reveal to p (for presentation) or v
(as occurring letter).  Or C-r?  So far, no back-end uses the
control key.  Any reasons not to do this?

Best wishes
Jens


[1] https://ox-hugo.scripter.co/
[2] https://github.com/org-opml/org-opml
[3] https://github.com/yjwen/org-reveal
[4] https://gitlab.com/oer/org-re-reveal
[5] https://github.com/msnoigrs/ox-rst
[6] https://github.com/balddotcat/ox-slimhtml

Re: Key bindings for Org export back-ends?

[Kaushal Modi]

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

On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger <lechten@wi.uni-muenster.de
wrote:

>
> - org-reveal [3]: R
> - org-re-reveal [4]: r (conflict with RSS)
>

I see that org-re-reveal is based off org-reveal. So do you see a use case
where people would `require' both org-reveal and org-re-reveal? If not,
then using the same binding as that of org-reveal should be fine too.


Where could we document the resulting list?
>

I'm pretty sure there are many more Org backends out there. For example, I
have a little ox-minutes backend that uses the M binding (and overrides the
binding for ox-man, but that's fine for me as I don't use ox-man).

We can start collecting a list of all Org backends on the Worg wiki. That's
a good idea. But doing so in order to not override the binding of some
other backend might not be possible.

I’m thinking of changing org-re-reveal to p (for presentation) or v
> (as occurring letter).


What about R as I suggested above?

  Or C-r?  So far, no back-end uses the
> control key.  Any reasons not to do this?
>

You could probably use C-<letter>, but one has to ensure that it doesn't
override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if
that override would actually be effective.

>

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

Re: Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 06:51, Kaushal Modi wrote:

> On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger <lechten@wi.uni-muenster.de
> wrote:
>
>> - org-reveal [3]: R
>> - org-re-reveal [4]: r (conflict with RSS)
>
> I see that org-re-reveal is based off org-reveal. So do you see a use case
> where people would `require' both org-reveal and org-re-reveal? If not,
> then using the same binding as that of org-reveal should be fine too.

I don’t recommend that but org-re-reveal should allow for a parallel
installation.  Therefore, I would like to bind a different key.

> I'm pretty sure there are many more Org backends out there. For example, I
> have a little ox-minutes backend that uses the M binding (and overrides the
> binding for ox-man, but that's fine for me as I don't use ox-man).
>
> We can start collecting a list of all Org backends on the Worg wiki. That's
> a good idea.

OK, let’s see whether additional input arrives.

> But doing so in order to not override the binding of some
> other backend might not be possible.

Fair enough.  At least some guidance will be given.

>> Or C-r?  So far, no back-end uses the
>> control key.  Any reasons not to do this?
>>
>
> You could probably use C-<letter>, but one has to ensure that it doesn't
> override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if
> that override would actually be effective.

On my machine using "?\C-r" instead of "?r" as letter works,
(resulting in integer number 18 in org-export-registered-backends).
However, the Org Export Dispatcher shows "[^R]" as key, which is not
ideal.

Best wishes
Jens

Re: Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 06:51, Kaushal Modi wrote:

> On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger <lechten@wi.uni-muenster.de
> wrote:
>
>> - org-reveal [3]: R
>> - org-re-reveal [4]: r (conflict with RSS)
>
> I see that org-re-reveal is based off org-reveal. So do you see a use case
> where people would `require' both org-reveal and org-re-reveal? If not,
> then using the same binding as that of org-reveal should be fine too.

I don’t recommend that but org-re-reveal should allow for a parallel
installation.  Therefore, I would like to bind a different key.

> I'm pretty sure there are many more Org backends out there. For example, I
> have a little ox-minutes backend that uses the M binding (and overrides the
> binding for ox-man, but that's fine for me as I don't use ox-man).
>
> We can start collecting a list of all Org backends on the Worg wiki. That's
> a good idea.

OK, let’s see whether additional input arrives.

> But doing so in order to not override the binding of some
> other backend might not be possible.

Fair enough.  At least some guidance will be given.

>> Or C-r?  So far, no back-end uses the
>> control key.  Any reasons not to do this?
>>
>
> You could probably use C-<letter>, but one has to ensure that it doesn't
> override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if
> that override would actually be effective.

On my machine using "?\C-r" instead of "?r" as letter works,
(resulting in integer number 18 in org-export-registered-backends).
However, the Org Export Dispatcher shows "[^R]" as key, which is not
ideal.

Best wishes
Jens

Re: Key bindings for Org export back-ends?

[Berry, Charles]

> On Feb 8, 2019, at 12:27 AM, Jens Lechtenboerger <lechten@wi.uni-muenster.de> wrote:
> 
> Hi there,
> 
> I need to assign a key to an Org export back-end.  My first attempt
> ended in a conflict, so I’d like to collect a (full?) list.
> 

I'm not trolling, but ...

There are about 30 packages on melpa.

And doing a search on GitHub:

`org-export-define-derived-backend  extension:.el language:"Emacs Lisp"'

gave me over 9000 (!) results.

And  `org-export-define-derived-backend extension:.org language:Org'

gave me 54 more. Maybe some overlap.

I am sure there are false positives. Some do not have a :menu. Some are copies used in init files. Some in the *.org files might just be commentary. 

But still there are a lot out there.

===

Maybe a better angle is to think about how to extend the menu functionality to accommodate all of the possible collisions.  I'd offer to help in this, but I will not have any time for some weeks to come.

Chuck

p.s. I will go offline for a couple of weeks starting in 48 hours. So if I do not respond to a follow up, it is not because I am ignoring it.

Re: Key bindings for Org export back-ends?

[John Kitchin]

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

my goto solution to keymap collisions is hydra. Here is one that shows how
to make one for exporting in org-mode:

https://github.com/abo-abo/hydra/blob/master/hydra-ox.el


John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Fri, Feb 8, 2019 at 7:32 PM Berry, Charles <ccberry@ucsd.edu> wrote:

>
>
> > On Feb 8, 2019, at 12:27 AM, Jens Lechtenboerger <
> lechten@wi.uni-muenster.de> wrote:
> >
> > Hi there,
> >
> > I need to assign a key to an Org export back-end.  My first attempt
> > ended in a conflict, so I’d like to collect a (full?) list.
> >
>
> I'm not trolling, but ...
>
> There are about 30 packages on melpa.
>
> And doing a search on GitHub:
>
> `org-export-define-derived-backend  extension:.el language:"Emacs Lisp"'
>
> gave me over 9000 (!) results.
>
> And  `org-export-define-derived-backend extension:.org language:Org'
>
> gave me 54 more. Maybe some overlap.
>
> I am sure there are false positives. Some do not have a :menu. Some are
> copies used in init files. Some in the *.org files might just be
> commentary.
>
> But still there are a lot out there.
>
> ===
>
> Maybe a better angle is to think about how to extend the menu
> functionality to accommodate all of the possible collisions.  I'd offer to
> help in this, but I will not have any time for some weeks to come.
>
> Chuck
>
> p.s. I will go offline for a couple of weeks starting in 48 hours. So if I
> do not respond to a follow up, it is not because I am ignoring it.
>
>

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

Re: Key bindings for Org export back-ends?

[Berry, Charles]

John,

That's the ticket!

The only thing I miss in hydra-ox.el is being able to repeat subtree exports.

i.e. with the export dispatcher  when `C-c C-e C-s l l' is later followed by 'C-u C-c C-e', it navigates back to the right headline and exports the right subtree.

Thanks,

Chuck

> On Feb 8, 2019, at 5:20 PM, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> 
> my goto solution to keymap collisions is hydra. Here is one that shows how to make one for exporting in org-mode:
> 
> https://github.com/abo-abo/hydra/blob/master/hydra-ox.el
> 
> 
> John
> 

Re: Key bindings for Org export back-ends?

[Thomas S. Dye]

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

One place for the list of key bindings might be here:
https://orgmode.org/worg/exporters/index.html

All the best,
Tom

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

Re: Key bindings for Org export back-ends?

[Kaushal Modi]

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

On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye <tdye@hawaii.edu> wrote:

> One place for the list of key bindings might be here:
> https://orgmode.org/worg/exporters/index.html
>

That's a great idea! How about creating a single Org table with columns
like Name, Description, Binding, Core/Contributed, and then sort the rows
by the Binding column?

We can leave the obsolete exporters section separate as it is right now.

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

Re: Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 10:54, Kaushal Modi wrote:

> On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye <tdye@hawaii.edu> wrote:
>
>> One place for the list of key bindings might be here:
>> https://orgmode.org/worg/exporters/index.html
>>
>
> That's a great idea! How about creating a single Org table with columns
> like Name, Description, Binding, Core/Contributed, and then sort the rows
> by the Binding column?
>
> We can leave the obsolete exporters section separate as it is right now.

Should the description really go into a table?  Or might the table
just provide an overview before the current section “Core
exporters”?

Best wishes
Jens

Re: Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 22:03, Jens Lechtenboerger wrote:

> On 2019-02-08, at 10:54, Kaushal Modi wrote:
>
>> On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye <tdye@hawaii.edu> wrote:
>>
>>> One place for the list of key bindings might be here:
>>> https://orgmode.org/worg/exporters/index.html
>>>
>>
>> That's a great idea! How about creating a single Org table with columns
>> like Name, Description, Binding, Core/Contributed, and then sort the rows
>> by the Binding column?
>>
>> We can leave the obsolete exporters section separate as it is right now.
>
> Should the description really go into a table?  Or might the table
> just provide an overview before the current section “Core
> exporters”?

Actually, a similar table exists, marked as in progress:
https://orgmode.org/worg/exporters/ox-overview.html

Column “Worg Tutorial” is mostly empty.  Column “Org-mode Manual”
only contains entries for the upper half.  Should we combine both
into one, “Tutorial/Manual”?

Or is such a table a futile goal given the potential amount of
back-ends pointed out by Chuck in a parallel answer?

Best wishes
Jens