From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,
Date: Sun, 8 Jan 2023 23:42:02 +0700 [thread overview]
Message-ID: <tperos$vro$1@ciao.gmane.io> (raw)
In-Reply-To: <Y7nQ8dib5Y/m7DnG@protected.localdomain>
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.
next prev parent reply other threads:[~2023-01-08 16:43 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
2023-01-08 16:42 ` Max Nikulin [this message]
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='tperos$vro$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).