From: Jean Louis <bugs@gnu.support>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,
Date: Sat, 7 Jan 2023 23:07:13 +0300 [thread overview]
Message-ID: <Y7nQ8dib5Y/m7DnG@protected.localdomain> (raw)
In-Reply-To: <tp849v$f20$1@ciao.gmane.io>
* 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/
next prev parent reply other threads:[~2023-01-07 20:12 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-17 20:57 Problems with C-c C-e file.org andre duarte bueno
2022-12-18 14:55 ` Ihor Radchenko
2022-12-19 21:10 ` Export Org with Org concept -- Re: Problems with C-c C-e file.org, Jean Louis
2022-12-25 12:06 ` Ihor Radchenko
2022-12-25 15:43 ` Jean Louis
2022-12-26 10:04 ` Ihor Radchenko
2022-12-26 15:58 ` Jean Louis
2022-12-27 10:46 ` Ihor Radchenko
2022-12-31 1:08 ` Eduardo Ochs
2022-12-31 6:19 ` Jean Louis
2023-01-01 14:02 ` Ihor Radchenko
2023-01-02 5:58 ` Eduardo Ochs
2023-01-02 11:07 ` Jean Louis
2023-01-03 9:48 ` Ihor Radchenko
2023-01-03 10:01 ` Eduardo Ochs
2023-01-03 12:15 ` Max Nikulin
2023-01-03 12:36 ` Eduardo Ochs
2023-01-05 11:07 ` Ihor Radchenko
2023-01-05 14:41 ` Alain.Cochard
2023-01-05 15:00 ` Max Nikulin
2023-01-05 15:18 ` Alain.Cochard
2023-01-05 20:37 ` Eduardo Ochs
2023-01-05 18:50 ` Jean Louis
2023-01-05 15:43 ` Eduardo Ochs
2023-01-04 11:08 ` Jean Louis
2023-01-05 11:16 ` Ihor Radchenko
2023-01-05 19:19 ` Jean Louis
2023-01-06 3:51 ` Max Nikulin
2023-01-07 9:04 ` Ihor Radchenko
2023-01-07 18:34 ` Jean Louis
2023-01-07 19:12 ` Jean Louis
2023-01-12 15:43 ` Max Nikulin
2023-01-13 9:41 ` Ihor Radchenko
2023-01-04 18:03 ` Jean Louis
2023-01-05 11:17 ` Ihor Radchenko
2023-01-05 19:37 ` Jean Louis
2023-01-06 3:24 ` Max Nikulin
2023-01-07 20:07 ` Jean Louis [this message]
2023-01-08 16:42 ` Max Nikulin
2023-01-07 9:09 ` Ihor Radchenko
2023-01-04 17:51 ` Jean Louis
2023-01-04 16:53 ` Jean Louis
2022-12-20 16:56 ` Problems with C-c C-e file.org Jean Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y7nQ8dib5Y/m7DnG@protected.localdomain \
--to=bugs@gnu.support \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).