From: Ihor Radchenko <yantar92@posteo.net>
To: Jean Louis <bugs@gnu.support>
Cc: andre duarte bueno <bueno@lenep.uenf.br>, emacs-orgmode@gnu.org
Subject: Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,
Date: Mon, 26 Dec 2022 10:04:49 +0000 [thread overview]
Message-ID: <87fsd2qy4e.fsf@localhost> (raw)
In-Reply-To: <Y6hvhTRavIN9HTDw@protected.localdomain>
Jean Louis <bugs@gnu.support> writes:
>> > That is not first complaint, right? I would say it is obvious that
>> > such interface is not user friendly.
>>
>> Yes and no. Some users do not like it. Some users prefer the existing
>> one. Conclusion: even if we implement something better, it should be
>> backwards compatible.
>
> Remember, one cannot prefer something without having a choice!
>
> User preferring existing functions have basically more or less how
> many choices? One. So that is why they "prefer" it.
I vaguely recall some people voicing against new menu frameworks in the
past. That's why I said that some people prefer the existing one.
In any case, breaking the way existing menu works is not something we
can do without proposing a fallback.
https://bzg.fr/en/the-software-maintainers-pledge/
> QUESTION: You said that improvement to Org should be backwards
> compatible, but what exactly and specifically you mean in this case?
It means that we need to either keep the old menu code around and
provide an option to switch to it, or, better, implement the new menu
code in such a way that it does not change the current menu layouts and
bindings.
> The solution I have offered to you is the concept. Not the package.
> In that concept, by observing the code, you could see that it is
> possible:
> ...
> So what exactly has to be backwards compatiable?
> Is there anything you think it can't be made backwards compatible?
Layout mostly.
I do not think that you can re-create the existing menu layout if you
use Org buffer as menu.
>> >> This is because we use `read-char-exclusive'.
>> >
>> > Don't use what is blocking Emacs. Apart from Org mode I have never
>> > seen a package that blocks Emacs that I cannot even inspect keys.
>>
>> gnus, reftex, ediff.
>> (I do not mean that we should not improve Org in this regard)
>
> gnus -- does not have that function inside, but how I remember me of
> using Gnus, it never blocked the Emacs user interface, anything I used
> allowed me to switch to other buffers. Thus I cannot see the
> similarity to blocking user-unfriendly org-export-dispatch interface.
>
> reftex -- function is inside, but when invoked it does not block the
> Emacs user interface. I cannot see similarity to the blocking Org
> Export interface.
>
> ediff -- function `read-char-exclusive' is not inside and I have
> options which I can use without Emacs being blocked. I can switch from
> frame to frame, I can inspect every key.
I found these packages by searching the latest Emacs master.
read-char-exclusive is inside all of them.
In any case, I do not see much point arguing about this.
As I said, I am not against improving the menus in principle. We just
have constrains on how we can improve the existing menus.
>> There is code prototype down in the thread.
>> https://list.orgmode.org/orgmode/AM9PR09MB49770F57F33859770649C7C896AF9@AM9PR09MB4977.eurprd09.prod.outlook.com/
>
> I have downloaded org-select.el and tried demo1, demo2, demo3, and
> that is what we are talking about. It does the job well.
Yup. The discussion hanged at trying to write the existing menus with
that package. If someone™ volunteers to finish that part, it will be
welcome.
>> Thanks for the effort, but I'm afraid that it is not something we
>> want in Org core from maintenance perspective. Would be welcome as a
>> third-party package though.
>
> If you are the one among few responsible to modify Org and figure out
> how and where to modify it, then I understand it is large burden on
> you.
>
> Instead of talking of the burden, why not tackle accessibility and
> then let other people tell about needed accessibility (they tell but
> due to burden is difficult to follow) and make it so that it is
> non-blocking interface.
Can you please elaborate on the second paragraph? I feel that I am
missing the point you wanted to explain there.
>> 1. Your package is introducing a new formatting for menus and new
>> interaction paradigm. This is not backwards-compatible.
>
> The concept of non-blocking interface was obviously offered by Arthur
> Miller and now by me.
In the video, you are using Org mode commands inside menu, which is a
new concept for me.
> Almost 11 years ago, January 5th 2012, Nicolas Goaziou added those new
> functions like org-export-dispatch how I see it in the commit
> aeb1ee1c662cd2243c17cc99f6205a15fb3d9283.
>
> For 11 years Org Mode remained same, using blocking Org Export
> functions.
>
> No mouse? One cannot even switch buffer?
>
> Strange and weird to me.
>
> When user comes complaining think that there are other 100 users
> complaining.
I did not say that your concern is not a valid concern.
I only objected the concrete concept prototype you provided.
As I said, the ideal would be using transient for menus.
> With the publicly expressed attitude "it is burden for us" -- of
> course people will not even complain.
I think you get me wrongly. "It is a burden" also refers to "lets not
complicate Org code even further". Implementing and maintaining
non-trivial menu backends is not something that should be a part of
Org, if we have choice. Regardless how many code contributors Org has.
So, moving in the direction of having _more_ menu backends as part of
Org is not a good idea.
> My suggestion: involve more people into development.
Volunteers welcome! We don't have a magic want to involve more people.
Just trying to do our best to help the new contributors.
>> Org is already huge and maintaining a separate menu package _in
>> addition_ to all the pp existing staff is not a good idea.
>
> Then make it smaller by utilizing smarter methods.
Patches welcome!
Please remember that Org is actively developed by a handful of active
contributors. In the last 3 years, >100 commits are just from me,
Bastien, Nicolas, Kyle, and Timothy.
Refactoring menus has been in my todo list for a while, but it is not
the top-priority item for me, for example. Timothy had some plans to
implement transient support, but our time is not infinite.
>> 2. We are moving towards removing menu-specific code from Org in general
>> in favour of the existing menu frameworks. In particular, we plan to
>> change Org menus to use transient. See
>> https://orgmfode.org/list/8c364693bf6856e60cdd3e8b63ab0c9284d16733.camel@heagren.com
>>
>> Note that transient allows menu buffer navigation (C-s)
>
> We were speaking of "backwards compatible" and now I hear how
> menu-specific code is to be replaced by menu framework. Sorry, but I
> am getting confused.
Transient interaction model is the same with the existing Org menus: a
buffer is displayed explaining different options and user can toggle
various options before the main command is executed.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2022-12-26 10:06 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 [this message]
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
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=87fsd2qy4e.fsf@localhost \
--to=yantar92@posteo.net \
--cc=bueno@lenep.uenf.br \
--cc=bugs@gnu.support \
--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).