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

[Ihor Radchenko]

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>