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

[Jean Louis <bugs@gnu.support>]

* Max Nikulin <manikulin@gmail.com> [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.

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.

Functions found in those packages may be commands (interactive), and
it is up to user how to bind those keys. 

Read (info "(elisp) Key Binding Conventions")

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.

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

So why do that?

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. 

I can think that by clicking first time on a menu item in RCD Org
Export, that I can ask user if to assign which key for that export,
and remember that option. Provide something like that, a helpful
assistance function that when some option is invoked multiple times,
that computer may offer to user to assign it permanently to some key.

Or when some prefix is invoked that user may decide which key to use,
and that key is remembered for next sessions.

In general, leave to users how to bind keys.

> Do not repeat that blocking menu is not convenient enough sometimes. 

I am repeating it thousands of times on website pages. If it disturbs
you, is personal problem, which I can't help with. Some things don't
get done unless points are repeated..

> Say what should be used instead of `org-export-registered-backends'.

Before to tell that, you should describe that variable better.

"List of backends currently available in the exporter.
This variable is set with `org-export-define-backend' and
`org-export-define-derived-backend' functions."

What I see from RCD Org Export view point is that:

- there is variable `org-export-backends' which says which exports are
  customized by user to be "there". In my case:

  org-export-backends ➜ (org odt md latex html ascii)

- I would like menu in RCD Org Export to appear for those backends
  which are customized by user. So I have 3 solutions, one is totally
  independent of Org mainstream, which would simply recognize those to
  me known exporting functions and show the menu of whatever packages
  are available for export, and other would be convenient, to
  recognize what user wants and offer only that. Or combination of
  those.

Sorry, I do not understand why `org-export-backends' do not recognize
all the pandoc based exports. I do understand why those exports appear
in the org-export-dispatch menu. 

Is then Org consistent to user that user can turn on, turn off, any
export that user wish or want?

Or is not consistent? It appears not consistent for ox-pandoc package.

If Org is not consistent, then I better build on the external
foundation without asking Org variables, but just recognizing which
functions already exist.

I can as well simply parse variable `org-pandoc-menu-entry' for
construction of the menu.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/