* Ihor Radchenko <yanta...@posteo.net> [2022-12-26 13:05]: > 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/
I have never said anything about "breaking the way existing menu works". The concept offered does not "break anything". If you mean key bindings, then retain key bindings. That is a choice. That was not part of the concept. I have defined the concept well and expressed me clear with points one by one. If you mean formatting of the text, how it looks like, then retain formatting of text. That is choice. That is not part of the offered concept. The concept is about usability related to non-blocking interface and mouse usage, speed and easy, and not about changing keybindings or formatting of text. > > 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. Good that you say that. I never talked about changing key bindings and menu layout, so that is something you may keep. > > 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. I can do, I see no problem there. What changes is that the menu would become liberated, non-blocking, and that user may use mouse to turn off/on the necessary options, and may move away from the Org Export buffer to other buffers and come back, no need to re-invoke and re-invoke the export buffer over and over again. It can remain on left side, right side, and by using mouse or keys it can export so many times faster than the existing ordinary org dispatch interface. So I guess we have misunderstanding, you think of layout and key bindings, and me I think of non-blocking interface. QUESTION: Should I now add the ordinary layout and keybindings and show you how it works? >From your side I expect that you tell me how do you use Org functions to discover new exports as to see how to automatically include such. > > 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. OK, but it is not related to the problem explained by original poster, and that was explained by me in past. DEFINITION OF PROBLEM: Problem is related to blocking interface and lack of usability: user cannot use keys to freely move inside of buffer and select options, cannot switch buffers, need to re-invoke the org export dispatcher each time for each export, and cannot use mouse. > 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. You have defined constraints to be the formatting (layout) and key bindings. Is there anything else? I believe there is something in org that recognizes various export options and implements menu, is it? > > 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. You may read the original post about the lack of usability (this is correct word I wanted to use instead of accessibility). You should not by using "burden" prevent people to freely say what they think about usability. And problems of maintenance are there many, I am sure, and it takes your time -- but such problems need not be expressed on this list for purpose not to prevent people reporting and improving Org. Person working in significant position in university complained about it. I am confident that professor has reason related to usability and that is what has to be discussed. Subject of discussion is not the burden in maintenance, make it different thread and ask people to contribute and delegate your tasks to other contributors. Promote contributing widely over website. The actual problem is there at hand, it is well defined. > >> 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. I can't understand what you mean. Which Org mode command do you mean? Is it on this first video: https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-19-23:36:10.ogv or on this second one: https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-20-19:33:59.ogv I made peculiar way to use Emacs buttons in Org derived mode, so you can click by mouse or ENTER, I could add SPACE, and one can fold options, also turn on/off global variables before export. Regarding formatting: I don't think that formatting and layouts were pretty dependant on the interface in the manner how it began in past, and then programmers kept using that concept for the sake of the interface, not for sake of users. If you are bound to foundation lacking usability, of course programmers must stick to that foundation. However, that does not help users become swift in exporting. And thus it is not bad to escape the formatting for something better. > 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. Obviously there is misunderstanding. It was said how it works. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/