Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Max Nikulin]

On 08/01/2023 03:07, Jean Louis wrote:
> * Max Nikulin [2023-01-06 06:30]:
> > Could you, please, concentrate on your vision of proper
> > `org-export-registered-backends' design?
>
> I leave that to Org developers. That variable is not described well,
> neither mentioned in Org manual.

Org has user manual, but not developer manual. Doesn't 
`org-export-define-backend' provide enough details concerning 
`org-export-registered-backends'?

Your vision of `org-export-registered-backends' design might shed some 
light why you consider its design as poor. I do not see any real problem 
to use it as is with a better menu implementation.

> I can only reiterate my point which you did not understand. In Emacs
> there are thousands of extensions. There is mainstream Emacs and there
> are ELPA, and other repositories and all kinds of Emacs packages.

I am aware of it. In the context of export menu, third party package may 
register their export function.

> Based on that I don't find it consistent that in variable
> `org-export-registered-backends' Org has something like this:
>
> (85 "As UTF-8 buffer"
>            (lambda
>              (a s v b)
>              (org-ascii-export-as-ascii a s v b
>                                         '(:ascii-charset utf-8))))
>
> as that asks for key probably 85 to be defined for that specific
> function.
>
> And the design of that variable leads to Gordian knot of the tangled
> code because it demands from all other exporters and extensions to
> follow that principle.

I do not see any problem. The structure associates export functions, 
titles and hints for key bindings. It is normal for UI to have 
accelerator keys. If you do not like suggested key, you are free to 
override it in your menu framework. What code is tangled from your point 
of view? In the posted snippet I see a declaration of a function that 
should be exposed to UI.

> I recommend not binding authors of Org export packages to provide
> keys and let users be free to decide which keys to use for which
> export.

Allowing users to customize key bindings is not the same as imposing 
obligations to choose key bindings. You are free to not provide default 
key bindings or to shuffle menu entries by popularity for "convenience" 
in *your* packages. Default keys means consistency for novices and users 
who do not want to customize such aspects.

> And principle is not consistent to (info "(elisp) Key Binding Conventions")

I see just a minor issue that ESC ESC does not dismiss menu. C-g still 
works. Local variables dialog ("do you want to apply...") behaves 
similar to Org menus. There is enough room for improvements, but I would 
not call it a great trouble.

> I am repeating it thousands of times on website pages. If it disturbs
> you, is personal problem, which I can't help with.

I do not care what you are posting on some websites. I do not like that 
in messages sent to my email you are repeating the same obvious ideas 
even when asked to clarify your particular statements.