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

[Jean Louis <bugs@gnu.support>]

* Ihor Radchenko <yantar92@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/