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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2022-12-25 15:07]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> > Apparently C-c C-e is capturing all events and not just keyboard
> >> > events!
> >
> > 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. 

QUESTION: You said that improvement to Org should be backwards
compatible, but what exactly and specifically you mean in this case?

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:

- to setup key bindings to emulate what org-export-dispatch does; it
  is up to you to set the key bindings to make it "backwards"
  compatible, and finally, (QUESTION) why should a new improvement to
  interface be backwards compatible?

  The underlying functions should be backwards compatible. 

- that it is possible to turn on/off necessary variables for export by
  single key or by mouse clicks or using cursor and ENTER; now if you
  wish to keep it "backwards compatible" use those IMHO complicated
  key bindings such as C-b C-s C-a, etc.

- interface does NOT block Emacs and buffer can remain for as long
  until it is invoked new time. User can freely keep the Org Export
  Dispatch buffer on screen and keep exporting various versions in the
  breeze. Any key may be inspected. User may switch to other buffers
  and come back what one cannot do with org-export-dispatch interface.

So what exactly has to be backwards compatiable?

Is there anything you think it can't be made backwards compatible?

> >> 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.

😎 Sorry, but none of your examples is equivalent to blocking Org
dispatch or Org agenda.

The concept offered to you from my side is equivalent to ediff concept
of using keys which is:

1. make a new derived mode (for any kind of mode)

2. define keys in that derived mode

3. remember which buffer is to be exported by using local variables

4. display options menu for Org Export export, to switch or toggle
   global variables in the buffer itself, which are necessary to
   modify exporting functions

5. use mouse, and ENTER, SPC, whatever keys you wish to choose options
   and make it freely backwards compatible

6. Help Emacs user not to get blocked while Emacs is waiting for
   keys. User shall be in control and be able to inspect keys and
   switch from buffer to buffer even during the exporting. 

To help Emacs user be able to get "out of Org Export" is important as
export deals with files, and files need be inspected. It is so much
faster to export Org file by using RCD Org Export than by common
interface.

Using `ediff' interface is the same concept, it is non-blocking,
user-liberating concept, which is taken for granted in Emacs, but
disabled in Org Export and Org Agenda, and where else.

> 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.

I would just not use text mode but for Org export I would use Org mode
as that is what users of Org are used to.

> > Here is the concept of using Org similar buffers to export Org
> > buffers:
> >
> > GNU Emacs package: rcd-org-export.el -- use Org to export Org:
> > https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-export-el-use-Org-to-export-Org-76272.html
> >
> > It is made for you, as concept, as I have already mentioned the
> > concept before months. 
> >
> > In general, this is Org mode, so why not use Org mode to export Org
> > mode?
> >
> > See the video demonstration:
> >
> > https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-19-23:36:10.ogv
> 
> 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.

> Why:
> 
> 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.

Formatting is not important, format it as you wish.

Myself I prefer it formatted in Org style as it is Org Export and
using Org buffers as menus is just fine.

There is no "new" interaction paradigm in using "keys" or
"mouse". That is Emacs built-in way of doing things.

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. 

With the publicly expressed attitude "it is burden for us" -- of
course people will not even complain. 

My suggestion: involve more people into development.

> If we add the package like yours into Org core, it will mean
> maintaining yet another piece of menu code in Org.

That was not my suggestion, but that you adopt the concept.

Arthur Miller gave you enough clues. You mentioned ediff, those are
concepts.

The core concept that is missing in Org Export and Agenda is
following:

1. Make it non-blocking, so that user can switch from buffer to buffer
   how one wants. This includes inspecting keys, functions, etc. You
   tear down the "self-documenting" part of Emacs if you disallow me
   as user to inspect keys. 

2. Make interface stay there in existence as buffer which remembers
   which buffer is to be exported, until quit or kill. This is useful
   because it is non-repetitive. There are no I guess already more
   than hundred of different Org exports. Let us use standard
   interface in Emacs, which is "keys" on keyboard, arrow keys,
   movements, mouse, SPC, RET, etc. This will minimize your burden
   because you do not need to demand from package developers to
   include new key bindings for their exports or to figure out
   yourself which key for which export function. You do not need any
   key, you have Emacs buttons, or Org links, let users use Org to
   export Org. Click or invoke the button.

3. Allow using mouse to activate links. Doug Engelbart would turn
   around in his grave watching how mouse compatible Emacs interface
   cannot use mouse.

> 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.

> 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.

Though it is very good proposal to switch to user friendly
interface. I hope that one can inspect keys, switch buffers, and
remain in freedom as user.

> 3. Ideally, we should also adopt the existing menu layouts using
>    transient. If not possible, we should consolidate the menu code into
>    a separate simple library. Something just enough to replicate the
>    existing functionality. With minimal maintenance. The thread I linked
>    is one of such efforts.

The next day I figured out that I will need functionality many times,
so here is the RCD Dashboard that has features to toggle global
variables by using mouse and keys.

GNU Emacs package: rcd-dashboard.el -- Tool to build Emacs dashboards:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-dashboard-el-Tool-to-build-Emacs-dashboards-76668.html

and here is the RCD Org Agenda Dashboard built with it:

GNU Emacs package: rcd-org-agenda-dashboard.el -- RCD Org Agenda Dashboard:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-agenda-dashboard-el-RCD-Org-Agenda-Dashboard-76669.html

all based on the concept from:

GNU Emacs package: rcd-org-export.el -- use Org to export Org:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-export-el-use-Org-to-export-Org-76272.html

and for next 10 years of Org accessibility, good reference about user
interface designs:

Humanize accessibility | UX design | Accessibility for Teams:
https://accessibility.digital.gov/ux/humanize-accessibility/

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/