Problems with C-c C-e file.org

Problems with C-c C-e file.org

[andre duarte bueno]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

When I try to export file.org  using C-c C-e the window with the list of
possibilities appears. But it appears incomplete(visualization), so I try
to use the mouse to view the other export options and the system is
completely blocked. Every mouse click is captured and displayed in the
command window. And it doesn't allow you to do anything else. I am forced
to cancel the command without completing it.
Apparently C-c C-e is capturing all events and not just keyboard events!

*André Duarte Bueno*
*Professor Associado LENEP/CCT/UENF*
*Chefe Setor Modelagem Matemática e Computacional*

*UENF* - Universidade Estadual do Norte Fluminense - Darcy Ribeiro
*CCT* - Centro de Ciências e Tecnologias
*LENEP* - Laboratório de Engenharia e Exploração de Petróleo
Rodovia Amaral Peixoto, km 163, Avenida Brenand S/N
CEP:   27925-310 - Imboassica - Macaé - RJ - Brasil
Fone:   +55 (22)  2765-6500 geral / *(22) 2765-6563 *sala / (22)
99954-2635 cel
Fax:     +55 (22) 2765-6565
e-mail:  <andreduartebueno@gmail.com>
e-mail institucional: <bueno@lenep.uenf.br>
Site do Professor:  https://sites.google.com/view/professorandreduartebueno/

[-- Attachment #2: Type: text/html, Size: 1654 bytes --]

Re: Problems with C-c C-e file.org

[Ihor Radchenko]

andre duarte bueno <bueno@lenep.uenf.br> writes:

> When I try to export file.org  using C-c C-e the window with the list of
> possibilities appears. But it appears incomplete(visualization), so I try
> to use the mouse to view the other export options and the system is
> completely blocked. Every mouse click is captured and displayed in the
> command window. And it doesn't allow you to do anything else. I am forced
> to cancel the command without completing it.
> Apparently C-c C-e is capturing all events and not just keyboard events!

This is because we use `read-char-exclusive'.
Another option could be `read-char', but that would make clicking work
as C-g.

Alternative menu designs have been discussed in
https://list.orgmode.org/orgmode/AM9PR09MB497743D21FA1C908392413F496D99@AM9PR09MB4977.eurprd09.prod.outlook.com/

... but they are not easy to implement.

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

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2022-12-18 17:57]:
> andre duarte bueno <bueno@lenep.uenf.br> writes:
> 
> > When I try to export file.org  using C-c C-e the window with the list of
> > possibilities appears. But it appears incomplete(visualization), so I try
> > to use the mouse to view the other export options and the system is
> > completely blocked. Every mouse click is captured and displayed in the
> > command window. And it doesn't allow you to do anything else. I am forced
> > to cancel the command without completing it.
> > 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. 

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

> Alternative menu designs have been discussed in
> https://list.orgmode.org/orgmode/AM9PR09MB497743D21FA1C908392413F496D99@AM9PR09MB4977.eurprd09.prod.outlook.com/

I did not find anything on that link.

You have the Org menu, right? You can export it from menu, it could be
so simple.

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

Package is made for you Ihor, as a concept of non-blocking export, it
is not functional.

You can now make automatic discovery of export packages and implement
it in Org if you wish. 

As if not, I am sure that I can finish it and have that export working
well for my export backends.

-- 
Jean

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

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

Re: Problems with C-c C-e file.org

[Jean Louis]

* andre duarte bueno <bueno@lenep.uenf.br> [2022-12-18 12:30]:
> When I try to export file.org  using C-c C-e the window with the list of
> possibilities appears. But it appears incomplete(visualization), so I try
> to use the mouse to view the other export options and the system is
> completely blocked. Every mouse click is captured and displayed in the
> command window. And it doesn't allow you to do anything else. I am forced
> to cancel the command without completing it.
> Apparently C-c C-e is capturing all events and not just keyboard events!

That problem is solved with my package RCD Org Export, see video
demonstration here:

https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-20-19:33:59.ogv

You may let me know what type of Org exports you need and I will make
sure that my Emacs Lisp package supports it. It is non-blocking and
allows mouse usage.

More about it:

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

-- 
Jean

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

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

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

[Ihor Radchenko]

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.

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

>> Alternative menu designs have been discussed in
>> https://list.orgmode.org/orgmode/AM9PR09MB497743D21FA1C908392413F496D99@AM9PR09MB4977.eurprd09.prod.outlook.com/
>
> I did not find anything on that link.

There is code prototype down in the thread.
https://list.orgmode.org/orgmode/AM9PR09MB49770F57F33859770649C7C896AF9@AM9PR09MB4977.eurprd09.prod.outlook.com/

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

Why:

1. Your package is introducing a new formatting for menus and new
   interaction paradigm. This is not backwards-compatible.
   If we add the package like yours into Org core, it will mean
   maintaining yet another piece of menu code in Org. Org is already
   huge and maintaining a separate menu package _in addition_ to all the
   existing staff is not a good idea.

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://orgmode.org/list/8c364693bf6856e60cdd3e8b63ab0c9284d16733.camel@heagren.com

   Note that transient allows menu buffer navigation (C-s)

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.

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

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/

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>

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

[Jean Louis]

* 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/

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

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

Yes, that's what I was referring to. I am not against non-blocking
interface per se.

> QUESTION: Should I now add the ordinary layout and keybindings and
> show you how it works?

It will be a good first step forward, yes.
If we move in this direction, we will need to find some way to replace
all the menus, like agenda menu, attach menu, clock menu, capture menu,
export menu, tag menu, etc.

We have one shared interface in `org-mks', which might be tweaked a
starting point.

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

For export menu, the relevant function is `org-export--dispatch-ui'.

> You have defined constraints to be the formatting (layout) and key
> bindings.
>
> Is there anything else?

I don't think so. The basic idea is to not break workflows that worked
in the past.

> I believe there is something in org that recognizes various export
> options and implements menu, is it? 

Mostly a collection of ad-hoc code all across Org. See the above.

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

Here. <RET> on the menus toggling the checklist.
The approach used in the existing menus is entering a dedicated key or
key sequence to select/unselect options.

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

You may be right, but, as stated in the article I referenced, "I won't
lecture you [the user] on why the new experience is better."

If you think that we need to throw that existing approach away
completely and use the one you proposed, I'd suggest implementing the
better menu framework as independent package instead, allow plugging it
into Org, and then maybe switch to it in future if many users use the
alternative framework instead of the default one.

Combining the two is better though. IMHO.

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

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

[Eduardo Ochs]

On Mon, 19 Dec 2022 at 18:13, Jean Louis <bugs@gnu.support> wrote:
>
> * Ihor Radchenko <yantar92@posteo.net> [2022-12-18 17:57]:
> > andre duarte bueno <bueno@lenep.uenf.br> writes:
> >
> > > When I try to export file.org  using C-c C-e the window with the list of
> > > possibilities appears. But it appears incomplete(visualization), so I try
> > > to use the mouse to view the other export options and the system is
> > > completely blocked. Every mouse click is captured and displayed in the
> > > command window. And it doesn't allow you to do anything else. I am forced
> > > to cancel the command without completing it.
> > > 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.
>
> > 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.

Hi Jean Louis,

did you solve your problem? Did you find a way to replace the blocking
code by something else?

I stumbled on exactly the same problem some months ago, and it drove
me nuts:

https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html Edrx 1
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00098.html Ihor 2
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00106.html Edrx 3
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00111.html Ihor 4
http://angg.twu.net/e/org.e.html#org-export-dispatch

My conclusion was that Org is much harder to learn than I thought.
It's easy to learn if:

  1) you're a "user", or
  2) you know a lot about debugging Emacs, or
  3) the developers like your questions.

My holidays have just started, and I'm planning to work on (2).

Btw, at some point I gave up trying to find the functions that the
dispatcher calls, and I just defined this "function with a very short
name" that [c]ompiles the current .org file to HTML:

  (defun c () (interactive) (eek "C-c C-e h h"))

Refs:

  (find-eev-quick-intro "3. Elisp hyperlinks" "eek")
  (find-eev-quick-intro "7.4. Commands with very short names")
  http://angg.twu.net/eev-intros/find-eev-quick-intro.html#3
  http://angg.twu.net/eev-intros/find-eev-quick-intro.html#7.4

Cheers,
  Eduardo Ochs
  http://angg.twu.net/eepitch.html
  http://angg.twu.net/2021-org-for-non-users.html

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

[Jean Louis]

* Eduardo Ochs <eduardoochs@gmail.com> [2022-12-31 04:11]:
> Hi Jean Louis,
> 
> did you solve your problem? Did you find a way to replace the
> blocking code by something else?

Of course, for me personally, I have fully solved it, you can see
video here:

https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-20-19:33:59.ogv

And I will add over time the detection of any possible export backend
that I may find. What export backends is available, it will be
detected and then automatically expanded like Org headings for it, and
what user does not want, shall be detected and not shown.

I think that original code for Org came into existance before 10+
years as back then there were maybe just few keybindings, maybe just
2-3 keybindings. So it was all about pure export.

Over the time Org developed the need for toggling of options such as:

** Export Options

- [ ] Export body only - [b]
- [ ] Export only current subtree - [s]
- [ ] Export asynchronously - [a]
- [ ] Export visible only - [v]
- [ ] Force publishing - [f]

then other backends appeared. And that caused over time that users did
not have any more just 2-3 keys, but it became a full screen now, with
variables to be toggled. 

By the way, the above heading "Export Options" I could freely copy
from the RCD Org Export interface, while something like that is
impossible when using M-x org-export-dispatch function or "C-c C-e"

Nobody in 10 years looked how it can be improved, so people just kept
adopting it.

 really does not and cannot
fit in the primary frame where there was only few keys to export Org.

The arguments that come up are that user has to toggle variables
shortly before export, maintenance problems, etc. 

Ihor mentioned few possible modes like ediff, that is similar or
blocking to Org Export dispatch screen -- but in reality is not. I
have inspected ediff menu buffer and found I can inspect any key, I
can move to other windows, my Emacs with ediff was not blocked. It was
not relevant comparison.

> I stumbled on exactly the same problem some months ago, and it drove
> me nuts:
> 
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html Edrx 1
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00098.html Ihor 2
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00106.html Edrx 3
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00111.html Ihor 4
> http://angg.twu.net/e/org.e.html#org-export-dispatch

Yes, and when there is one of users speaking about it, there are maybe
hundreds of others who stumble upon it and probably never come back. 

> My conclusion was that Org is much harder to learn than I thought.
> It's easy to learn if:
> 
>   1) you're a "user", or
>   2) you know a lot about debugging Emacs, or
>   3) the developers like your questions.

I know that Eli does not use Org. And many people using Org are not
developers, apparently they master Org useful functions. 

We could say there are very simply Org functions and more complex.

Simplicity lies in this example:

* My heading

My text

** DONE My subheading
   CLOSED: [2022-12-31 Sat 08:44]

** TODO My subheading

- [ ] My task
- [ ] My task

When just few Org elements are used it is simple. Org documentation
talks about all the other more complex functions. 

Back to export, why use a buffer for export that does not even look
like Org bufer? 

When we list the now available number of Org export backends, it is
already huge list. It simply is not any more compatible to the idea
before 10 years when somebody used 2-3 keys to export Org.

And the code complexity is unbelievable to me. It is tangled in the
manner how I am personally not used to when using Lisp or Scheme. My I
like shorter functions, each doing something, but Org functions like
`org-export--dispatch-ui' is 176 lines.

That function tries to add functionality to Org that already exists
when user defines derived modes with key bindings.

You can inspect the package I made for that:

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

But then later I made RCD Dashboard that generalizes the concepts from
that package:

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

Then I started making similarly RCD Org Agenda interface:

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

I can add options to it later.

> My holidays have just started, and I'm planning to work on (2).

There could be eev buffer to export Org, and such buffer need not be
blocking.

Solving toggling of variables is easy:

- it should be derived mode, it could also be Org mode

Instead of following:

** Export Options

- [ ] Export body only - [b]
- [ ] Export only current subtree - [s]
- [ ] Export asynchronously - [a]
- [ ] Export visible only - [v]
- [ ] Force publishing - [f]


** Export Options

(ee-org-export-body-only) ➜ ON
(ee-org-export-only-current-subtree) ➜ SUBTREE
(ee-org-export-asynchronouse) ➜ OFF
(ee-org-export-visible) ➜ OFF
(ee-org-export-force-publishing) ➜ ON

And for those above toggles you would or could make it so that there
is visual replacement of the text such as "ON/OFF" or "SUBTREE/BODY".

Then other functions such as these below, could be replaced with eev
functions.

** Export to Org

*** Export as Org buffer
*** Export as Org file and open
*** Export as Org file

** Export to HTML

*** Export as HTML buffer
*** Export as HTML file and open
*** Export as HTML file

My solution in RCD Org Export is not purely Org based, it uses Emacs
buttons directly. This is for reason of updating options visually,
like you can see on video. 

However, all of the options may be implemented in Emacs Lisp that is
embedded in Org mode Elisp links, including the options to update
visually and demonstrate what has been toggled and what not. 

> Btw, at some point I gave up trying to find the functions that the
> dispatcher calls, and I just defined this "function with a very short
> name" that [c]ompiles the current .org file to HTML:
> 
>   (defun c () (interactive) (eek "C-c C-e h h"))

You can't easily inspect Org Agenda or Org Dispatch Interface because
interfaces are blocking.

It means you cannot invoke `C-h k' to inspect any key. This defeats
the purpose of Emacs to be self-documenting, as user is prevented to
quickly find the function on key.


-- 
Jean

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

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

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

[Ihor Radchenko]

Eduardo Ochs <eduardoochs@gmail.com> writes:

> My conclusion was that Org is much harder to learn than I thought.
> It's easy to learn if:
>
>   1) you're a "user", or
>   2) you know a lot about debugging Emacs, or
>   3) the developers like your questions.

I hope that (3) is not your experience with Org ML. If it is, I'd rather
say "developers understand questions". At least from my perspective.
Your approach is rather unusual for me, making it difficult to follow
even after detailed explanations.

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

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

[Eduardo Ochs]

On Sun, 1 Jan 2023 at 11:02, Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Eduardo Ochs <eduardoochs@gmail.com> writes:
>
> > My conclusion was that Org is much harder to learn than I thought.
> > It's easy to learn if:
> >
> >   1) you're a "user", or
> >   2) you know a lot about debugging Emacs, or
> >   3) the developers like your questions.
>
> I hope that (3) is not your experience with Org ML. If it is, I'd rather
> say "developers understand questions". At least from my perspective.
> Your approach is rather unusual for me, making it difficult to follow
> even after detailed explanations.

Hi Ihor,

(3) _is_ my experience with the Org mailing list.

What I meant by "the developers like your questions" was roughly:
"recognizing that that person deserves help, and giving him tools that
would let him solve his problems in hours instead of in months or
years".

For example, in this thread

https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html

no one considered that if I was asking that then maybe it would be a
good idea to make `org-export-dispatch' more hackeable by beginners...

For example, someone could have said "can you try this? Copy that
function to other file, replace its lines foo and bar by the lines
plic and bletch, and use the ideas in these two blog posts to debug
and inspect its data structures"... but no, that didn't happen - I've
asked lots of technical questions here over the years and never got
detailed answers like that, only answers whose technical details _were
kept as short as possible_, and whose explanations were much closer to
"in English" than to "in Lisp".

A few days ago I added subtitles to my video about "Org for
Non-Users". The links are here,

  http://angg.twu.net/2021-org-for-non-users.html

and some people will prefer to just read this:

  http://angg.twu.net/eev-videos/2021-org-for-non-users.vtt
  http://angg.twu.net/SUBTITLES/2021-org-for-non-users.lua.html

It explains with examples how a "non-user" thinks, and it shows what I
mean by "explanations in Lisp".

  Cheers =/,
    Eduardo

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

[Jean Louis]

I was reading about Orgdown, Karl, please keep the name, and don't
mind the group.

* Eduardo Ochs <eduardoochs@gmail.com> [2023-01-02 09:01]:
> (3) _is_ my experience with the Org mailing list.
> 
> What I meant by "the developers like your questions" was roughly:
> "recognizing that that person deserves help, and giving him tools that
> would let him solve his problems in hours instead of in months or
> years".
> 
> For example, in this thread
> 
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html
> 
> no one considered that if I was asking that then maybe it would be a
> good idea to make `org-export-dispatch' more hackeable by
> beginners...

By the way, I have idea to make Org Export in 3 different ways more,
one that is very hackable and introspective and one that can be edited
as plain text file how users wish and want, then they can reuse the
file to have their menu. Imagine.

> For example, someone could have said "can you try this? Copy that
> function to other file, replace its lines foo and bar by the lines
> plic and bletch, and use the ideas in these two blog posts to debug
> and inspect its data structures"... but no, that didn't happen - I've
> asked lots of technical questions here over the years and never got
> detailed answers like that, only answers whose technical details _were
> kept as short as possible_, and whose explanations were much closer to
> "in English" than to "in Lisp".

The Org manual is there with pointers. Let me know links to your
questions, maybe we find some more pointers to it.

> A few days ago I added subtitles to my video about "Org for
> Non-Users". The links are here,
> 
>   http://angg.twu.net/2021-org-for-non-users.html

Where is the eev file of the page?

--
Jean

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

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

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

[Ihor Radchenko]

Eduardo Ochs <eduardoochs@gmail.com> writes:

> (3) _is_ my experience with the Org mailing list.
>
> What I meant by "the developers like your questions" was roughly:
> "recognizing that that person deserves help, and giving him tools that
> would let him solve his problems in hours instead of in months or
> years".
>
> For example, in this thread
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html

To be fair, your another message copy got some replies:
https://list.orgmode.org/CADs++6j+oPnSA8pO7_sbCTmhOg5v_BEzkr6vBB1ECfHBprKmFQ@mail.gmail.com/

> no one considered that if I was asking that then maybe it would be a
> good idea to make `org-export-dispatch' more hackeable by beginners...

In any case, we are here now, after the discussion resurfaced.

> For example, someone could have said "can you try this? Copy that
> function to other file, replace its lines foo and bar by the lines
> plic and bletch, and use the ideas in these two blog posts to debug
> and inspect its data structures"... but no, that didn't happen - I've
> asked lots of technical questions here over the years and never got
> detailed answers like that, only answers whose technical details _were
> kept as short as possible_, and whose explanations were much closer to
> "in English" than to "in Lisp".

I recommend following up on the replies if you find them incomplete.

There are no guarantees that exhaustive detailed replies will be given -
they take a lot of time to write and are often not necessary.

> A few days ago I added subtitles to my video about "Org for
> Non-Users". The links are here,
>
>   http://angg.twu.net/2021-org-for-non-users.html
>
> and some people will prefer to just read this:
>
>   http://angg.twu.net/eev-videos/2021-org-for-non-users.vtt
>   http://angg.twu.net/SUBTITLES/2021-org-for-non-users.lua.html
>
> It explains with examples how a "non-user" thinks, and it shows what I
> mean by "explanations in Lisp".

I get it, but you cannot force me to reply like this. I simply do not
think this way - when I try to reply to questions on ML, I do it the way
I can. I cannot adapt the explanation style that is foreign to me.

If you find something in mine (or other's) replies not clear, just ask
to clarify.

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

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

[Eduardo Ochs]

On Tue, 3 Jan 2023 at 06:47, Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Eduardo Ochs <eduardoochs@gmail.com> writes:
>
> > (3) _is_ my experience with the Org mailing list.
> >
> > What I meant by "the developers like your questions" was roughly:
> > "recognizing that that person deserves help, and giving him tools that
> > would let him solve his problems in hours instead of in months or
> > years".
> >
> > For example, in this thread
> >
> > https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00674.html
>
> To be fair, your another message copy got some replies:
> https://list.orgmode.org/CADs++6j+oPnSA8pO7_sbCTmhOg5v_BEzkr6vBB1ECfHBprKmFQ@mail.gmail.com/
>
> > no one considered that if I was asking that then maybe it would be a
> > good idea to make `org-export-dispatch' more hackeable by beginners...
>
> In any case, we are here now, after the discussion resurfaced.
>
> > For example, someone could have said "can you try this? Copy that
> > function to other file, replace its lines foo and bar by the lines
> > plic and bletch, and use the ideas in these two blog posts to debug
> > and inspect its data structures"... but no, that didn't happen - I've
> > asked lots of technical questions here over the years and never got
> > detailed answers like that, only answers whose technical details _were
> > kept as short as possible_, and whose explanations were much closer to
> > "in English" than to "in Lisp".
>
> I recommend following up on the replies if you find them incomplete.
>
> There are no guarantees that exhaustive detailed replies will be given -
> they take a lot of time to write and are often not necessary.
>
> > A few days ago I added subtitles to my video about "Org for
> > Non-Users". The links are here,
> >
> >   http://angg.twu.net/2021-org-for-non-users.html
> >
> > and some people will prefer to just read this:
> >
> >   http://angg.twu.net/eev-videos/2021-org-for-non-users.vtt
> >   http://angg.twu.net/SUBTITLES/2021-org-for-non-users.lua.html
> >
> > It explains with examples how a "non-user" thinks, and it shows what I
> > mean by "explanations in Lisp".
>
> I get it, but you cannot force me to reply like this. I simply do not
> think this way - when I try to reply to questions on ML, I do it the way
> I can. I cannot adapt the explanation style that is foreign to me.
>
> If you find something in mine (or other's) replies not clear, just ask
> to clarify.

Ok, let me try something else.

Can you send to me - here to the mailing list - a version of
`org-export-dispatch', and also of other functions if needed, in which
the parts that call `read-char-exclusive' are replaced by something
non-blocking?

  Thanks in advance =),
    Eduardo Ochs

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

[Max Nikulin]

On 03/01/2023 17:01, Eduardo Ochs wrote:
> 
> Can you send to me - here to the mailing list - a version of
> `org-export-dispatch', and also of other functions if needed, in which
> the parts that call `read-char-exclusive' are replaced by something
> non-blocking?

Eduardo, I am sorry, but from my opinion it is too much. Perhaps you are 
just not realizing that resources of developers are rather limited. 
Getting rid of `read-char-exclusive' in Org menus requires significant 
amount of work. Nobody argues that it would be a great improvement, but 
it is necessary to make changes that are not obvious at first glance. It 
would lead to confusing behavior otherwise.

Jean might be happy with the posted mock-up. Unfortunately that code is 
too far from been ready to be used for all users. E.g. it does not use 
`org-export-registered-backends', not to mention that all menus in the 
package should be consistent. It is OK to have a bunch of repetitive 
code for a demo, but it can not be taken as is.

Ihor dedicates a lot of time for development and maintaining of Org. 
Other developers are significantly less active last months. Often 
authors of code are not participating in discussions because several 
years have been passed since that time and they are busy with other 
projects. So your questions may noticeable efforts from other persons 
unfamiliar with some code to "read" it for you. Org code is not ideal, 
but it is rarely too obscure. Nobody intentionally adds obstacles that 
hamper readability. Sometimes it is necessary to make decisions not 
realizing actual consequences just to move forward. If you need code 
friendly for beginners then find a friend who can rewrite the code in 
the style you like (of course, it should be maintainable as well).

At first I believed that on your own way you are just avoiding reading 
comments and docstring in ox.el that are helpful to discover actual 
functions in export backends that do the job. E.g. docstring of 
`org-export-define-backend' and its usage in other files is rather 
informative.

I am lost what is your actual needs after your request to rewrite the 
export dispatcher for you.

After all, if you can not figure out which function is called by the 
dispatcher, instrument for debugging some transcoder function and export 
some file. You will get call stack.

Be realistic, time and experience are limited resources, not all code 
deserves blog posts. Source code is a communication channel as well.

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

[Eduardo Ochs]

[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]

On Tue, 3 Jan 2023, 09:23 Max Nikulin, <manikulin@gmail.com> wrote:

> On 03/01/2023 17:01, Eduardo Ochs wrote:
> >
> > Can you send to me - here to the mailing list - a version of
> > `org-export-dispatch', and also of other functions if needed, in which
> > the parts that call `read-char-exclusive' are replaced by something
> > non-blocking?
>
> Eduardo, I am sorry, but from my opinion it is too much. Perhaps you are
> just not realizing that resources of developers are rather limited.
> Getting rid of `read-char-exclusive' in Org menus requires significant
> amount of work. Nobody argues that it would be a great improvement, but
> it is necessary to make changes that are not obvious at first glance. It
> would lead to confusing behavior otherwise.
>
> Jean might be happy with the posted mock-up. Unfortunately that code is
> too far from been ready to be used for all users. E.g. it does not use
> `org-export-registered-backends', not to mention that all menus in the
> package should be consistent. It is OK to have a bunch of repetitive
> code for a demo, but it can not be taken as is.
>
> Ihor dedicates a lot of time for development and maintaining of Org.
> Other developers are significantly less active last months. Often
> authors of code are not participating in discussions because several
> years have been passed since that time and they are busy with other
> projects. So your questions may noticeable efforts from other persons
> unfamiliar with some code to "read" it for you. Org code is not ideal,
> but it is rarely too obscure. Nobody intentionally adds obstacles that
> hamper readability. Sometimes it is necessary to make decisions not
> realizing actual consequences just to move forward. If you need code
> friendly for beginners then find a friend who can rewrite the code in
> the style you like (of course, it should be maintainable as well).
>
> At first I believed that on your own way you are just avoiding reading
> comments and docstring in ox.el that are helpful to discover actual
> functions in export backends that do the job. E.g. docstring of
> `org-export-define-backend' and its usage in other files is rather
> informative.
>
> I am lost what is your actual needs after your request to rewrite the
> export dispatcher for you.
>
> After all, if you can not figure out which function is called by the
> dispatcher, instrument for debugging some transcoder function and export
> some file. You will get call stack.
>
> Be realistic, time and experience are limited resources, not all code
> deserves blog posts. Source code is a communication channel as well.
>

Hi Max,

sorry, I thought that that would be something like a 5-line change... =(

A few messages again I mentioned that one of my plans for these holidays
was to learn several techniques for debugging elisp that I've postponing
learning for ages. I'll do that and then I'll try solving this problem
again.

  Cheers =/,
    Eduardo

[-- Attachment #2: Type: text/html, Size: 3852 bytes --]

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-03 15:18]:
> Eduardo, I am sorry, but from my opinion it is too much. Perhaps you are
> just not realizing that resources of developers are rather limited. Getting
> rid of `read-char-exclusive' in Org menus requires significant amount of
> work.

Yeah, right, I have spent few hours to make

GNU Emacs package: rcd-org-export.el -- use Org to export Org:
2022-12-25 18:16:06.397296+03

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

And from there I developed RCD Dashboard on
2022-12-25 17:44:11.336142+03

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 now I have full set of dashboards with people being assigned to
tasks, plans, programs, projects, agenda, etc.

Because I can't agree to your statements, that is why I use the user
friendly Org mode based RCD Org Export Dashboard instead of standard
Org blocking, user-unfriendly one.

> Nobody argues that it would be a great improvement, but it is
> necessary to make changes that are not obvious at first glance. It
> would lead to confusing behavior otherwise.

Nothing is obvious when it is not obvious. I got it.

> Jean might be happy with the posted mock-up.

The posted mock-up is not any more mock-up but daily used dashboard to
export Org.

> Unfortunately that code is too far from been ready to be used for
> all users.

So how far? Like few hours?

> E.g. it does not use `org-export-registered-backends', not to
> mention that all menus in the package should be consistent.

I am aware of it, thanks.

Feel free to make it. 

Do you really need it?

Though, we speak here of non-blicking Org Export, and there are many
ways to do it, we speak of decisions that are not user friendly, made
before more than 10 years.

There was enough time to use whatever one wish. I can't wait for
somebody in mainstream Org to make it user friendly, mouse clickable,
and so there is enough of it for you to adapt it to your own needs as
in main stream. 

If you people wish.

If you look at the RCD Dashboard, then how "menus" should look like
may be left to user to decide. So far nobody uses my package that I
know, and in that case, I will not keep improving what is not so far
found as interesting for users. 

It works for me so well. That is why I use it.

Feel free to bend your fingers with C-c C-e C-a C-f C-s, and I will
keep using the mouse device to export Org.

> It is OK to have a bunch of repetitive code for a demo, but it can
> not be taken as is.

You have not say that you like the functionality. Underlying
repetitive stuff is not important.

And I rather like that repetitive style than the Gordian knot of the
Org code.

> I am lost what is your actual needs after your request to rewrite
> the export dispatcher for you.

It can be rewritten in simple text, actually in Org mode alone it can
work. That is up to those who are interested. 

Why develop something when there is no interest?

I guess it must be 5-6 years that I was talking about sharing headings
by e-mail, XMPP, SMS, etc. and since then I have received bunch of
dollars because of those features. None of it was implemented in Org,
because sharing is not part of it, or decisions, or developers
burdens, etc. 

That is example of "why develop features when there is no interest for
it". 

Good that Emacs is extensible by every user, otherwise it would be one
way road with Org.

-- 
Jean

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

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

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

[Jean Louis]

Pointers for you Eduardo:

(find-efunction 'org-export-dispatch)
(find-efunction 'org-export--dispatch-ui)
(progn (find-efunction 'org-export--dispatch-ui) (forward-line 48))
(progn (find-efunction 'org-export--dispatch-ui) (search-forward "Export scope"))
(find-efunction 'org-export-define-backend)
(find-library "ox-html")
(progn (find-library "ox-html") (search-forward "Export to HTML"))


-- 
Jean

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

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

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

[Jean Louis]

> Can you send to me - here to the mailing list - a version of
> `org-export-dispatch', and also of other functions if needed, in which
> the parts that call `read-char-exclusive' are replaced by something
> non-blocking?

There is no Org version of menu that does not block. That it is there
is due to initial notion that some functions should be run on single
key, which is not bad in itself. Then people followed and continued
developing on that foundation creating tangled functions.

(find-function 'org-export--dispatch-ui)

So in Org, currently, there is only the blocking way. Functions in Org
Export or Org Agenda, can't be inspected interactively by using
commands like {C-h k}, you can inspect sources directly.

What you are asking is what my package offers:

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

You may inspect how functions look like:
(find-function 'org-html-export-as-html)

Then description:

org-html-export-as-html is an autoloaded interactive byte-compiled
Lisp function in ‘ox-html.el’.

(org-html-export-as-html &optional ASYNC SUBTREEP VISIBLE-ONLY
BODY-ONLY EXT-PLIST)

Basically ASYNC, SUBTREEP, VISIBLE-ONLY and BODY-ONLY are expected to
be either NON-NIL or NIL, and by using those switches, you use the
function to export.

What the function:

(find-function 'org-export--dispatch-ui) 

does is making sure to "highlight" (irony) when user press this or
that key, like when user press the highlighted "h", that then the
subsequent key like "H" appears highlighted, indicating to user that
after pressing first key, there are just few other options left.

Then in general Org Export works like this:

First the underlying information:

- It recognizes which export are available. What is worse, because of
  the not well taught design every OTHER package for Org export lean
  on the same blocking interface foundation, and keep adding to it!

  This is because developers of extensions for Emacs do not have other
  choice, or their package would not be included in
  org-export-dispatch

  Bad design, dictates more bad design.

  And if you ask me, of course that even simple change to interface
  creates havoc in all of those known and unknown Org export packages.

  Then there is the Org Broom that makes sure some apparently large,
  objectively small problems, end up under the carpet.

Then visibly what Org Export does for user is following:

- Show to user options to toggle variables like ASYNC, SUBTREEP,
  VISIBLE-ONLY, BODY-ONLY, they are supposed to be handled in real
  time. 

- Recognize which various exports among hundreds of them are available
  and display them for user to press one among hundreds of possible
  key combinations

- Then export function is invoked with paramenters ASYNC SUBTREEP
  VISIBLE-ONLY BODY-ONLY EXT-PLIST, while some exports not support all
  of them

To develop export library requires adapting to previously embedded or
hard coded expectation of mainstream Org. 

Notion is now that the interface will be changed to transient, which
does something similar more or less. I don't know of mouse support in
transient, but what I have seen, it does not look like it.

For you to make eev based export is easy, just toggling of variables
and recognizing which export options are there, generating temporary
eev buffers as usual.

Objective reality points
------------------------

- Within Emacs there are many multi key commands. If user wish to see
  which key follows which key, can use packages like `which-key' or
  similar. 

  Thus, it is superficial to involve some kind of highlighting single
  keys. That idea could have work very good for developer who made
  it. If I get used to it and acquire habit of it, I will keep using
  it and develop more by same principle.
  
- That toggling variables need blocking screen is not coherent, as it
  doesn't. A derived mode may define any keys, and instead of "C-b"
  there can be simply "b" for "body-only" toggling. 

- Using control key, like C-b, to toggle variables makes sense only in
  writable buffers.

- For each single export users are forced by design to again click
  "C-c C-e" and again invoke "h H" or other similar functions. This
  fact alone makes Org less usable.

- Using emacsclient during Org Export is not feasible.

- Emacs get blocked.

- It ignores mouse and normal keyboard movements, it blocks Emacs and
  invoking emacsclient during Org Export or Org Agenda gives
  surprising impossible looking effects; this will not change with
  transient adoption.

- Usability get forgotten.

- Package RCD Org Export, proves, that export screen may remain all the
  time visible, without blocking Emacs, and user may within seconds
  export to various different formats.

-- 
Jean

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

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

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-03 15:18]:
> Jean might be happy with the posted mock-up. Unfortunately that code is too
> far from been ready to be used for all users. E.g. it does not use
> `org-export-registered-backends', not to mention that all menus in the
> package should be consistent. It is OK to have a bunch of repetitive code
> for a demo, but it can not be taken as is.

After looking into it, into `org-export-registered-backends', I will
not use it, neither follow the chain of poor design.

Users can get the choice otherwise in my package. I can have my own
setup and recognition of various exports. 

I can't follow the bad design that happen to take place, so I will not
lean on this below, I find that complex, while it need not be.

Value:
(#s(org-export-backend :name texinfo :parent nil :transcoders
		       ((bold . org-texinfo-bold)
			(center-block . org-texinfo-center-block)
			(clock . org-texinfo-clock)
			(code . org-texinfo-code)
			(drawer . org-texinfo-drawer)
			(dynamic-block . org-texinfo-dynamic-block)
			(entity . org-texinfo-entity)
			(example-block . org-texinfo-example-block)
			(export-block . org-texinfo-export-block)
			(export-snippet . org-texinfo-export-snippet)
			(fixed-width . org-texinfo-fixed-width)
			(footnote-definition . org-texinfo-footnote-definition)
			(footnote-reference . org-texinfo-footnote-reference)
			(headline . org-texinfo-headline)
			(inline-src-block . org-texinfo-inline-src-block)
			(inlinetask . org-texinfo-inlinetask)
			(italic . org-texinfo-italic)
			(item . org-texinfo-item)
			(keyword . org-texinfo-keyword)
			(line-break . org-texinfo-line-break)
			(link . org-texinfo-link)
			(node-property . org-texinfo-node-property)
			(paragraph . org-texinfo-paragraph)
			(plain-list . org-texinfo-plain-list)
			(plain-text . org-texinfo-plain-text)
			(planning . org-texinfo-planning)
			(property-drawer . org-texinfo-property-drawer)
			(quote-block . org-texinfo-quote-block)
			(radio-target . org-texinfo-radio-target)
			(section . org-texinfo-section)
			(special-block . org-texinfo-special-block)
			(src-block . org-texinfo-src-block)
			(statistics-cookie . org-texinfo-statistics-cookie)
			(strike-through . org-texinfo-strike-through)
			(subscript . org-texinfo-subscript)
			(superscript . org-texinfo-superscript)
			(table . org-texinfo-table)
			(table-cell . org-texinfo-table-cell)
			(table-row . org-texinfo-table-row)
			(target . org-texinfo-target)
			(template . org-texinfo-template)
			(timestamp . org-texinfo-timestamp)
			(underline . org-texinfo-underline)
			(verbatim . org-texinfo-verbatim)
			(verse-block . org-texinfo-verse-block))
		       :options
		       ((:texinfo-filename "TEXINFO_FILENAME" nil nil t)
			(:texinfo-class "TEXINFO_CLASS" nil org-texinfo-default-class t)
			(:texinfo-header "TEXINFO_HEADER" nil nil newline)
			(:texinfo-post-header "TEXINFO_POST_HEADER" nil nil newline)
			(:subtitle "SUBTITLE" nil nil parse)
			(:subauthor "SUBAUTHOR" nil nil newline)
			(:texinfo-dircat "TEXINFO_DIR_CATEGORY" nil nil t)
			(:texinfo-dirtitle "TEXINFO_DIR_TITLE" nil nil t)
			(:texinfo-dirdesc "TEXINFO_DIR_DESC" nil nil t)
			(:texinfo-printed-title "TEXINFO_PRINTED_TITLE" nil nil t)
			(:texinfo-classes nil nil org-texinfo-classes)
			(:texinfo-format-headline-function nil nil org-texinfo-format-headline-function)
			(:texinfo-node-description-column nil nil org-texinfo-node-description-column)
			(:texinfo-active-timestamp-format nil nil org-texinfo-active-timestamp-format)
			(:texinfo-inactive-timestamp-format nil nil org-texinfo-inactive-timestamp-format)
			(:texinfo-diary-timestamp-format nil nil org-texinfo-diary-timestamp-format)
			(:texinfo-link-with-unknown-path-format nil nil org-texinfo-link-with-unknown-path-format)
			(:texinfo-tables-verbatim nil nil org-texinfo-tables-verbatim)
			(:texinfo-table-scientific-notation nil nil org-texinfo-table-scientific-notation)
			(:texinfo-table-default-markup nil nil org-texinfo-table-default-markup)
			(:texinfo-text-markup-alist nil nil org-texinfo-text-markup-alist)
			(:texinfo-format-drawer-function nil nil org-texinfo-format-drawer-function)
			(:texinfo-format-inlinetask-function nil nil org-texinfo-format-inlinetask-function))
		       :filters
		       ((:filter-headline . org-texinfo--filter-section-blank-lines)
			(:filter-parse-tree . org-texinfo--normalize-headlines)
			(:filter-section . org-texinfo--filter-section-blank-lines)
			(:filter-final-output . org-texinfo--untabify))
		       :blocks nil :menu
		       (105 "Export to Texinfo"
			    ((116 "As TEXI file" org-texinfo-export-to-texinfo)
			     (105 "As INFO file" org-texinfo-export-to-info)
			     (111 "As INFO file and open"
				  (lambda
				    (a s v b)
				    (if a
					(org-texinfo-export-to-info t s v b)
				      (org-open-file
				       (org-texinfo-export-to-info nil s v b))))))))
   #s(org-export-backend :name man :parent nil :transcoders
			 ((babel-call . org-man-babel-call)
			  (bold . org-man-bold)
			  (center-block . org-man-center-block)
			  (code . org-man-code)
			  (drawer . org-man-drawer)
			  (dynamic-block . org-man-dynamic-block)
			  (entity . org-man-entity)
			  (example-block . org-man-example-block)
			  (export-block . org-man-export-block)
			  (export-snippet . org-man-export-snippet)
			  (fixed-width . org-man-fixed-width)
			  (footnote-definition . org-man-footnote-definition)
			  (footnote-reference . org-man-footnote-reference)
			  (headline . org-man-headline)
			  (horizontal-rule . org-man-horizontal-rule)
			  (inline-babel-call . org-man-inline-babel-call)
			  (inline-src-block . org-man-inline-src-block)
			  (inlinetask . org-man-inlinetask)
			  (italic . org-man-italic)
			  (item . org-man-item)
			  (keyword . org-man-keyword)
			  (line-break . org-man-line-break)
			  (link . org-man-link)
			  (node-property . org-man-node-property)
			  (paragraph . org-man-paragraph)
			  (plain-list . org-man-plain-list)
			  (plain-text . org-man-plain-text)
			  (planning . org-man-planning)
			  (property-drawer . org-man-property-drawer)
			  (quote-block . org-man-quote-block)
			  (radio-target . org-man-radio-target)
			  (section . org-man-section)
			  (special-block . org-man-special-block)
			  (src-block . org-man-src-block)
			  (statistics-cookie . org-man-statistics-cookie)
			  (strike-through . org-man-strike-through)
			  (subscript . org-man-subscript)
			  (superscript . org-man-superscript)
			  (table . org-man-table)
			  (table-cell . org-man-table-cell)
			  (table-row . org-man-table-row)
			  (target . org-man-target)
			  (template . org-man-template)
			  (timestamp . org-man-timestamp)
			  (underline . org-man-underline)
			  (verbatim . org-man-verbatim)
			  (verse-block . org-man-verse-block))
			 :options
			 ((:man-class "MAN_CLASS" nil nil t)
			  (:man-class-options "MAN_CLASS_OPTIONS" nil nil t)
			  (:man-header-extra "MAN_HEADER" nil nil newline)
			  (:man-tables-centered nil nil org-man-tables-centered)
			  (:man-tables-verbatim nil nil org-man-tables-verbatim)
			  (:man-table-scientific-notation nil nil org-man-table-scientific-notation)
			  (:man-source-highlight nil nil org-man-source-highlight)
			  (:man-source-highlight-langs nil nil org-man-source-highlight-langs))
			 :filters nil :blocks nil :menu
			 (77 "Export to MAN"
			     ((109 "As MAN file" org-man-export-to-man)
			      (112 "As PDF file" org-man-export-to-pdf)
			      (111 "As PDF file and open"
				   (lambda
				     (a s v b)
				     (if a
					 (org-man-export-to-pdf t s v b)
				       (org-open-file
					(org-man-export-to-pdf nil s v b))))))))
   #s(org-export-backend :name icalendar :parent ascii :transcoders
			 ((clock . ignore)
			  (footnote-definition . ignore)
			  (footnote-reference . ignore)
			  (headline . org-icalendar-entry)
			  (inlinetask . ignore)
			  (planning . ignore)
			  (section . ignore)
			  (inner-template lambda
					  (c i)
					  c)
			  (template . org-icalendar-template))
			 :options
			 ((:exclude-tags "ICALENDAR_EXCLUDE_TAGS" nil org-icalendar-exclude-tags split)
			  (:with-timestamps nil "<" org-icalendar-with-timestamps)
			  (:icalendar-alarm-time nil nil org-icalendar-alarm-time)
			  (:icalendar-categories nil nil org-icalendar-categories)
			  (:icalendar-date-time-format nil nil org-icalendar-date-time-format)
			  (:icalendar-include-bbdb-anniversaries nil nil org-icalendar-include-bbdb-anniversaries)
			  (:icalendar-include-body nil nil org-icalendar-include-body)
			  (:icalendar-include-sexps nil nil org-icalendar-include-sexps)
			  (:icalendar-include-todo nil nil org-icalendar-include-todo)
			  (:icalendar-store-UID nil nil org-icalendar-store-UID)
			  (:icalendar-timezone nil nil org-icalendar-timezone)
			  (:icalendar-use-deadline nil nil org-icalendar-use-deadline)
			  (:icalendar-use-scheduled nil nil org-icalendar-use-scheduled))
			 :filters
			 ((:filter-headline . org-icalendar-clear-blank-lines))
			 :blocks nil :menu
			 (99 "Export to iCalendar"
			     ((102 "Current file" org-icalendar-export-to-ics)
			      (97 "All agenda files"
				  (lambda
				    (a s v b)
				    (org-icalendar-export-agenda-files a)))
			      (99 "Combine all agenda files"
				  (lambda
				    (a s v b)
				    (org-icalendar-combine-agenda-files a))))))
   #s(org-export-backend :name beamer :parent latex :transcoders
			 ((bold . org-beamer-bold)
			  (export-block . org-beamer-export-block)
			  (export-snippet . org-beamer-export-snippet)
			  (headline . org-beamer-headline)
			  (item . org-beamer-item)
			  (keyword . org-beamer-keyword)
			  (link . org-beamer-link)
			  (plain-list . org-beamer-plain-list)
			  (radio-target . org-beamer-radio-target)
			  (template . org-beamer-template))
			 :options
			 ((:headline-levels nil "H" org-beamer-frame-level)
			  (:latex-class "LATEX_CLASS" nil "beamer" t)
			  (:beamer-subtitle-format nil nil org-beamer-subtitle-format)
			  (:beamer-column-view-format "COLUMNS" nil org-beamer-column-view-format)
			  (:beamer-theme "BEAMER_THEME" nil org-beamer-theme)
			  (:beamer-color-theme "BEAMER_COLOR_THEME" nil nil t)
			  (:beamer-font-theme "BEAMER_FONT_THEME" nil nil t)
			  (:beamer-inner-theme "BEAMER_INNER_THEME" nil nil t)
			  (:beamer-outer-theme "BEAMER_OUTER_THEME" nil nil t)
			  (:beamer-header "BEAMER_HEADER" nil nil newline)
			  (:beamer-environments-extra nil nil org-beamer-environments-extra)
			  (:beamer-frame-default-options nil nil org-beamer-frame-default-options)
			  (:beamer-outline-frame-options nil nil org-beamer-outline-frame-options)
			  (:beamer-outline-frame-title nil nil org-beamer-outline-frame-title))
			 :filters nil :blocks nil :menu
			 (108 1
			      ((66 "As LaTeX buffer (Beamer)" org-beamer-export-as-latex)
			       (98 "As LaTeX file (Beamer)" org-beamer-export-to-latex)
			       (80 "As PDF file (Beamer)" org-beamer-export-to-pdf)
			       (79 "As PDF file and open (Beamer)"
				   (lambda
				     (a s v b)
				     (if a
					 (org-beamer-export-to-pdf t s v b)
				       (org-open-file
					(org-beamer-export-to-pdf nil s v b))))))))
   #s(org-export-backend :name pandoc :parent org :transcoders
			 ((latex-environment . org-pandoc-latex-environ)
			  (link . org-pandoc-link)
			  (table . org-pandoc-table)
			  (template . org-pandoc-template)
			  (paragraph . org-pandoc-paragraph)
			  (src-block . org-pandoc-src-block))
			 :options
			 ((:pandoc-options "PANDOC_OPTIONS" nil nil space)
			  (:pandoc-extensions "PANDOC_EXTENSIONS" nil nil space)
			  (:pandoc-metadata "PANDOC_METADATA" nil nil space)
			  (:pandoc-variables "PANDOC_VARIABLES" nil nil space)
			  (:epub-chapter-level "EPUB_CHAPTER_LEVEL" nil nil t)
			  (:epub-cover-image "EPUB_COVER" nil nil t)
			  (:epub-stylesheet "EPUB_STYLESHEET" nil nil t)
			  (:epub-embed-font "EPUB_EMBED_FONT" nil nil newline)
			  (:epub-meta "EPUB_META" nil nil newline)
			  (:epub-css "EPUB_CSS" nil nil newline)
			  (:epub-rights "EPUB_RIGHTS" nil nil newline)
			  (:bibliography "BIBLIOGRAPHY"))
			 :filters nil :blocks nil :menu
			 (112 "export via pandoc"
			      ((52 "to html5 and open." org-pandoc-export-to-html5-and-open)
			       (36 "as html5." org-pandoc-export-as-html5)
			       (53 "to html5-pdf and open." org-pandoc-export-to-html5-pdf-and-open)
			       (37 "to html5-pdf." org-pandoc-export-to-html5-pdf)
			       (60 "to slideous and open." org-pandoc-export-to-slideous-and-open)
			       (44 "as slideous." org-pandoc-export-as-slideous)
			       (61 "to ms-pdf and open." org-pandoc-export-to-ms-pdf-and-open)
			       (45 "to ms-pdf." org-pandoc-export-to-ms-pdf)
			       (98 "to beamer-pdf and open." org-pandoc-export-to-beamer-pdf-and-open)
			       (66 "to beamer-pdf." org-pandoc-export-to-beamer-pdf)
			       (99 "to context-pdf and open." org-pandoc-export-to-context-pdf-and-open)
			       (67 "to context-pdf." org-pandoc-export-to-context-pdf)
			       (100 "to docbook5 and open." org-pandoc-export-to-docbook5-and-open)
			       (68 "as docbook5." org-pandoc-export-as-docbook5)
			       (101 "to epub3 and open." org-pandoc-export-to-epub3-and-open)
			       (69 "to epub3." org-pandoc-export-to-epub3)
			       (103 "to gfm and open." org-pandoc-export-to-gfm-and-open)
			       (71 "as gfm." org-pandoc-export-as-gfm)
			       (104 "to html4 and open." org-pandoc-export-to-html4-and-open)
			       (72 "as html4." org-pandoc-export-as-html4)
			       (105 "to icml and open." org-pandoc-export-to-icml-and-open)
			       (73 "as icml." org-pandoc-export-as-icml)
			       (106 "to json and open." org-pandoc-export-to-json-and-open)
			       (74 "as json." org-pandoc-export-as-json)
			       (108 "to latex-pdf and open." org-pandoc-export-to-latex-pdf-and-open)
			       (76 "to latex-pdf." org-pandoc-export-to-latex-pdf)
			       (109 "to man and open." org-pandoc-export-to-man-and-open)
			       (77 "as man." org-pandoc-export-as-man)
			       (110 "to native and open." org-pandoc-export-to-native-and-open)
			       (78 "as native." org-pandoc-export-as-native)
			       (111 "to odt and open." org-pandoc-export-to-odt-and-open)
			       (79 "to odt." org-pandoc-export-to-odt)
			       (112 "to pptx and open." org-pandoc-export-to-pptx-and-open)
			       (80 "to pptx." org-pandoc-export-to-pptx)
			       (114 "to rtf and open." org-pandoc-export-to-rtf-and-open)
			       (82 "as rtf." org-pandoc-export-as-rtf)
			       (117 "to dokuwiki and open." org-pandoc-export-to-dokuwiki-and-open)
			       (85 "as dokuwiki." org-pandoc-export-as-dokuwiki)
			       (118 "to revealjs and open." org-pandoc-export-to-revealjs-and-open)
			       (86 "as revealjs." org-pandoc-export-as-revealjs)
			       (119 "to mediawiki and open." org-pandoc-export-to-mediawiki-and-open)
			       (87 "as mediawiki." org-pandoc-export-as-mediawiki)
			       (120 "to docx and open." org-pandoc-export-to-docx-and-open)
			       (88 "to docx." org-pandoc-export-to-docx)
			       (121 "to slidy and open." org-pandoc-export-to-slidy-and-open)
			       (89 "as slidy." org-pandoc-export-as-slidy)
			       (122 "to dzslides and open." org-pandoc-export-to-dzslides-and-open)
			       (90 "as dzslides." org-pandoc-export-as-dzslides))))
   #s(org-export-backend :name org :parent nil :transcoders
			 ((babel-call . org-org-identity)
			  (bold . org-org-identity)
			  (center-block . org-org-identity)
			  (clock . org-org-identity)
			  (code . org-org-identity)
			  (diary-sexp . org-org-identity)
			  (drawer . org-org-identity)
			  (dynamic-block . org-org-identity)
			  (entity . org-org-identity)
			  (example-block . org-org-identity)
			  (export-block . org-org-export-block)
			  (fixed-width . org-org-identity)
			  (footnote-definition . ignore)
			  (footnote-reference . org-org-identity)
			  (headline . org-org-headline)
			  (horizontal-rule . org-org-identity)
			  (inline-babel-call . org-org-identity)
			  (inline-src-block . org-org-identity)
			  (inlinetask . org-org-identity)
			  (italic . org-org-identity)
			  (item . org-org-identity)
			  (keyword . org-org-keyword)
			  (latex-environment . org-org-identity)
			  (latex-fragment . org-org-identity)
			  (line-break . org-org-identity)
			  (link . org-org-link)
			  (node-property . org-org-identity)
			  (template . org-org-template)
			  (paragraph . org-org-identity)
			  (plain-list . org-org-identity)
			  (planning . org-org-identity)
			  (property-drawer . org-org-identity)
			  (quote-block . org-org-identity)
			  (radio-target . org-org-identity)
			  (section . org-org-section)
			  (special-block . org-org-identity)
			  (src-block . org-org-identity)
			  (statistics-cookie . org-org-identity)
			  (strike-through . org-org-identity)
			  (subscript . org-org-identity)
			  (superscript . org-org-identity)
			  (table . org-org-identity)
			  (table-cell . org-org-identity)
			  (table-row . org-org-identity)
			  (target . org-org-identity)
			  (timestamp . org-org-timestamp)
			  (underline . org-org-identity)
			  (verbatim . org-org-identity)
			  (verse-block . org-org-identity))
			 :options nil :filters
			 ((:filter-parse-tree . org-org--add-missing-sections))
			 :blocks nil :menu
			 (79 "Export to Org"
			     ((79 "As Org buffer" org-org-export-as-org)
			      (111 "As Org file" org-org-export-to-org)
			      (118 "As Org file and open"
				   (lambda
				     (a s v b)
				     (if a
					 (org-org-export-to-org t s v b)
				       (org-open-file
					(org-org-export-to-org nil s v b))))))))
   #s(org-export-backend :name odt :parent nil :transcoders
			 ((bold . org-odt-bold)
			  (center-block . org-odt-center-block)
			  (clock . org-odt-clock)
			  (code . org-odt-code)
			  (drawer . org-odt-drawer)
			  (dynamic-block . org-odt-dynamic-block)
			  (entity . org-odt-entity)
			  (example-block . org-odt-example-block)
			  (export-block . org-odt-export-block)
			  (export-snippet . org-odt-export-snippet)
			  (fixed-width . org-odt-fixed-width)
			  (footnote-definition . org-odt-footnote-definition)
			  (footnote-reference . org-odt-footnote-reference)
			  (headline . org-odt-headline)
			  (horizontal-rule . org-odt-horizontal-rule)
			  (inline-src-block . org-odt-inline-src-block)
			  (inlinetask . org-odt-inlinetask)
			  (italic . org-odt-italic)
			  (item . org-odt-item)
			  (keyword . org-odt-keyword)
			  (latex-environment . org-odt-latex-environment)
			  (latex-fragment . org-odt-latex-fragment)
			  (line-break . org-odt-line-break)
			  (link . org-odt-link)
			  (node-property . org-odt-node-property)
			  (paragraph . org-odt-paragraph)
			  (plain-list . org-odt-plain-list)
			  (plain-text . org-odt-plain-text)
			  (planning . org-odt-planning)
			  (property-drawer . org-odt-property-drawer)
			  (quote-block . org-odt-quote-block)
			  (radio-target . org-odt-radio-target)
			  (section . org-odt-section)
			  (special-block . org-odt-special-block)
			  (src-block . org-odt-src-block)
			  (statistics-cookie . org-odt-statistics-cookie)
			  (strike-through . org-odt-strike-through)
			  (subscript . org-odt-subscript)
			  (superscript . org-odt-superscript)
			  (table . org-odt-table)
			  (table-cell . org-odt-table-cell)
			  (table-row . org-odt-table-row)
			  (target . org-odt-target)
			  (template . org-odt-template)
			  (timestamp . org-odt-timestamp)
			  (underline . org-odt-underline)
			  (verbatim . org-odt-verbatim)
			  (verse-block . org-odt-verse-block))
			 :options
			 ((:odt-styles-file "ODT_STYLES_FILE" nil org-odt-styles-file t)
			  (:description "DESCRIPTION" nil nil newline)
			  (:keywords "KEYWORDS" nil nil space)
			  (:subtitle "SUBTITLE" nil nil parse)
			  (:odt-content-template-file nil nil org-odt-content-template-file)
			  (:odt-display-outline-level nil nil org-odt-display-outline-level)
			  (:odt-fontify-srcblocks nil nil org-odt-fontify-srcblocks)
			  (:odt-format-drawer-function nil nil org-odt-format-drawer-function)
			  (:odt-format-headline-function nil nil org-odt-format-headline-function)
			  (:odt-format-inlinetask-function nil nil org-odt-format-inlinetask-function)
			  (:odt-inline-formula-rules nil nil org-odt-inline-formula-rules)
			  (:odt-inline-image-rules nil nil org-odt-inline-image-rules)
			  (:odt-pixels-per-inch nil nil org-odt-pixels-per-inch)
			  (:odt-table-styles nil nil org-odt-table-styles)
			  (:odt-use-date-fields nil nil org-odt-use-date-fields)
			  (:with-latex nil "tex" org-odt-with-latex)
			  (:latex-header "LATEX_HEADER" nil nil newline))
			 :filters
			 ((:filter-parse-tree org-odt--translate-latex-fragments org-odt--translate-description-lists org-odt--translate-list-tables org-odt--translate-image-links))
			 :blocks nil :menu
			 (111 "Export to ODT"
			      ((111 "As ODT file" org-odt-export-to-odt)
			       (79 "As ODT file and open"
				   (lambda
				     (a s v b)
				     (if a
					 (org-odt-export-to-odt t s v)
				       (org-open-file
					(org-odt-export-to-odt nil s v)
					'system)))))))
   #s(org-export-backend :name md :parent html :transcoders
			 ((bold . org-md-bold)
			  (center-block . org-md--convert-to-html)
			  (code . org-md-verbatim)
			  (drawer . org-md--identity)
			  (dynamic-block . org-md--identity)
			  (example-block . org-md-example-block)
			  (export-block . org-md-export-block)
			  (fixed-width . org-md-example-block)
			  (headline . org-md-headline)
			  (horizontal-rule . org-md-horizontal-rule)
			  (inline-src-block . org-md-verbatim)
			  (inlinetask . org-md--convert-to-html)
			  (inner-template . org-md-inner-template)
			  (italic . org-md-italic)
			  (item . org-md-item)
			  (keyword . org-md-keyword)
			  (line-break . org-md-line-break)
			  (link . org-md-link)
			  (node-property . org-md-node-property)
			  (paragraph . org-md-paragraph)
			  (plain-list . org-md-plain-list)
			  (plain-text . org-md-plain-text)
			  (property-drawer . org-md-property-drawer)
			  (quote-block . org-md-quote-block)
			  (section . org-md-section)
			  (special-block . org-md--convert-to-html)
			  (src-block . org-md-example-block)
			  (table . org-md--convert-to-html)
			  (template . org-md-template)
			  (verbatim . org-md-verbatim))
			 :options
			 ((:md-footnote-format nil nil org-md-footnote-format)
			  (:md-footnotes-section nil nil org-md-footnotes-section)
			  (:md-headline-style nil nil org-md-headline-style))
			 :filters
			 ((:filter-parse-tree . org-md-separate-elements))
			 :blocks nil :menu
			 (109 "Export to Markdown"
			      ((77 "To temporary buffer"
				   (lambda
				     (a s v b)
				     (org-md-export-as-markdown a s v)))
			       (109 "To file"
				    (lambda
				      (a s v b)
				      (org-md-export-to-markdown a s v)))
			       (111 "To file and open"
				    (lambda
				      (a s v b)
				      (if a
					  (org-md-export-to-markdown t s v)
					(org-open-file
					 (org-md-export-to-markdown nil s v))))))))
   #s(org-export-backend :name latex :parent nil :transcoders
			 ((bold . org-latex-bold)
			  (center-block . org-latex-center-block)
			  (clock . org-latex-clock)
			  (code . org-latex-code)
			  (drawer . org-latex-drawer)
			  (dynamic-block . org-latex-dynamic-block)
			  (entity . org-latex-entity)
			  (example-block . org-latex-example-block)
			  (export-block . org-latex-export-block)
			  (export-snippet . org-latex-export-snippet)
			  (fixed-width . org-latex-fixed-width)
			  (footnote-definition . org-latex-footnote-definition)
			  (footnote-reference . org-latex-footnote-reference)
			  (headline . org-latex-headline)
			  (horizontal-rule . org-latex-horizontal-rule)
			  (inline-src-block . org-latex-inline-src-block)
			  (inlinetask . org-latex-inlinetask)
			  (italic . org-latex-italic)
			  (item . org-latex-item)
			  (keyword . org-latex-keyword)
			  (latex-environment . org-latex-latex-environment)
			  (latex-fragment . org-latex-latex-fragment)
			  (line-break . org-latex-line-break)
			  (link . org-latex-link)
			  (node-property . org-latex-node-property)
			  (paragraph . org-latex-paragraph)
			  (plain-list . org-latex-plain-list)
			  (plain-text . org-latex-plain-text)
			  (planning . org-latex-planning)
			  (property-drawer . org-latex-property-drawer)
			  (quote-block . org-latex-quote-block)
			  (radio-target . org-latex-radio-target)
			  (section . org-latex-section)
			  (special-block . org-latex-special-block)
			  (src-block . org-latex-src-block)
			  (statistics-cookie . org-latex-statistics-cookie)
			  (strike-through . org-latex-strike-through)
			  (subscript . org-latex-subscript)
			  (superscript . org-latex-superscript)
			  (table . org-latex-table)
			  (table-cell . org-latex-table-cell)
			  (table-row . org-latex-table-row)
			  (target . org-latex-target)
			  (template . org-latex-template)
			  (timestamp . org-latex-timestamp)
			  (underline . org-latex-underline)
			  (verbatim . org-latex-verbatim)
			  (verse-block . org-latex-verse-block)
			  (latex-math-block . org-latex-math-block)
			  (latex-matrices . org-latex-matrices))
			 :options
			 ((:latex-class "LATEX_CLASS" nil org-latex-default-class t)
			  (:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
			  (:latex-header "LATEX_HEADER" nil nil newline)
			  (:latex-header-extra "LATEX_HEADER_EXTRA" nil nil newline)
			  (:description "DESCRIPTION" nil nil parse)
			  (:keywords "KEYWORDS" nil nil parse)
			  (:subtitle "SUBTITLE" nil nil parse)
			  (:latex-active-timestamp-format nil nil org-latex-active-timestamp-format)
			  (:latex-caption-above nil nil org-latex-caption-above)
			  (:latex-classes nil nil org-latex-classes)
			  (:latex-default-figure-position nil nil org-latex-default-figure-position)
			  (:latex-default-table-environment nil nil org-latex-default-table-environment)
			  (:latex-default-table-mode nil nil org-latex-default-table-mode)
			  (:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
			  (:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
			  (:latex-footnote-separator nil nil org-latex-footnote-separator)
			  (:latex-format-drawer-function nil nil org-latex-format-drawer-function)
			  (:latex-format-headline-function nil nil org-latex-format-headline-function)
			  (:latex-format-inlinetask-function nil nil org-latex-format-inlinetask-function)
			  (:latex-hyperref-template nil nil org-latex-hyperref-template t)
			  (:latex-image-default-scale nil nil org-latex-image-default-scale)
			  (:latex-image-default-height nil nil org-latex-image-default-height)
			  (:latex-image-default-option nil nil org-latex-image-default-option)
			  (:latex-image-default-width nil nil org-latex-image-default-width)
			  (:latex-images-centered nil nil org-latex-images-centered)
			  (:latex-inactive-timestamp-format nil nil org-latex-inactive-timestamp-format)
			  (:latex-inline-image-rules nil nil org-latex-inline-image-rules)
			  (:latex-link-with-unknown-path-format nil nil org-latex-link-with-unknown-path-format)
			  (:latex-listings nil nil org-latex-listings)
			  (:latex-listings-langs nil nil org-latex-listings-langs)
			  (:latex-listings-options nil nil org-latex-listings-options)
			  (:latex-minted-langs nil nil org-latex-minted-langs)
			  (:latex-minted-options nil nil org-latex-minted-options)
			  (:latex-prefer-user-labels nil nil org-latex-prefer-user-labels)
			  (:latex-subtitle-format nil nil org-latex-subtitle-format)
			  (:latex-subtitle-separate nil nil org-latex-subtitle-separate)
			  (:latex-table-scientific-notation nil nil org-latex-table-scientific-notation)
			  (:latex-tables-booktabs nil nil org-latex-tables-booktabs)
			  (:latex-tables-centered nil nil org-latex-tables-centered)
			  (:latex-text-markup-alist nil nil org-latex-text-markup-alist)
			  (:latex-title-command nil nil org-latex-title-command)
			  (:latex-toc-command nil nil org-latex-toc-command)
			  (:latex-compiler "LATEX_COMPILER" nil org-latex-compiler)
			  (:date "DATE" nil "\\today" parse))
			 :filters
			 ((:filter-options . org-latex-math-block-options-filter)
			  (:filter-paragraph . org-latex-clean-invalid-line-breaks)
			  (:filter-parse-tree org-latex-math-block-tree-filter org-latex-matrices-tree-filter org-latex-image-link-filter)
			  (:filter-verse-block . org-latex-clean-invalid-line-breaks))
			 :blocks nil :menu
			 (108 "Export to LaTeX"
			      ((76 "As LaTeX buffer" org-latex-export-as-latex)
			       (108 "As LaTeX file" org-latex-export-to-latex)
			       (112 "As PDF file" org-latex-export-to-pdf)
			       (111 "As PDF file and open"
				    (lambda
				      (a s v b)
				      (if a
					  (org-latex-export-to-pdf t s v b)
					(org-open-file
					 (org-latex-export-to-pdf nil s v b))))))))
   #s(org-export-backend :name html :parent nil :transcoders
			 ((bold . org-html-bold)
			  (center-block . org-html-center-block)
			  (clock . org-html-clock)
			  (code . org-html-code)
			  (drawer . org-html-drawer)
			  (dynamic-block . org-html-dynamic-block)
			  (entity . org-html-entity)
			  (example-block . org-html-example-block)
			  (export-block . org-html-export-block)
			  (export-snippet . org-html-export-snippet)
			  (fixed-width . org-html-fixed-width)
			  (footnote-reference . org-html-footnote-reference)
			  (headline . org-html-headline)
			  (horizontal-rule . org-html-horizontal-rule)
			  (inline-src-block . org-html-inline-src-block)
			  (inlinetask . org-html-inlinetask)
			  (inner-template . org-html-inner-template)
			  (italic . org-html-italic)
			  (item . org-html-item)
			  (keyword . org-html-keyword)
			  (latex-environment . org-html-latex-environment)
			  (latex-fragment . org-html-latex-fragment)
			  (line-break . org-html-line-break)
			  (link . org-html-link)
			  (node-property . org-html-node-property)
			  (paragraph . org-html-paragraph)
			  (plain-list . org-html-plain-list)
			  (plain-text . org-html-plain-text)
			  (planning . org-html-planning)
			  (property-drawer . org-html-property-drawer)
			  (quote-block . org-html-quote-block)
			  (radio-target . org-html-radio-target)
			  (section . org-html-section)
			  (special-block . org-html-special-block)
			  (src-block . org-html-src-block)
			  (statistics-cookie . org-html-statistics-cookie)
			  (strike-through . org-html-strike-through)
			  (subscript . org-html-subscript)
			  (superscript . org-html-superscript)
			  (table . org-html-table)
			  (table-cell . org-html-table-cell)
			  (table-row . org-html-table-row)
			  (target . org-html-target)
			  (template . org-html-template)
			  (timestamp . org-html-timestamp)
			  (underline . org-html-underline)
			  (verbatim . org-html-verbatim)
			  (verse-block . org-html-verse-block))
			 :options
			 ((:html-doctype "HTML_DOCTYPE" nil org-html-doctype)
			  (:html-container "HTML_CONTAINER" nil org-html-container-element)
			  (:description "DESCRIPTION" nil nil newline)
			  (:keywords "KEYWORDS" nil nil space)
			  (:html-html5-fancy nil "html5-fancy" org-html-html5-fancy)
			  (:html-link-use-abs-url nil "html-link-use-abs-url" org-html-link-use-abs-url)
			  (:html-link-home "HTML_LINK_HOME" nil org-html-link-home)
			  (:html-link-up "HTML_LINK_UP" nil org-html-link-up)
			  (:html-mathjax "HTML_MATHJAX" nil "" space)
			  (:html-equation-reference-format "HTML_EQUATION_REFERENCE_FORMAT" nil org-html-equation-reference-format t)
			  (:html-postamble nil "html-postamble" org-html-postamble)
			  (:html-preamble nil "html-preamble" org-html-preamble)
			  (:html-head "HTML_HEAD" nil org-html-head newline)
			  (:html-head-extra "HTML_HEAD_EXTRA" nil org-html-head-extra newline)
			  (:subtitle "SUBTITLE" nil nil parse)
			  (:html-head-include-default-style nil "html-style" org-html-head-include-default-style)
			  (:html-head-include-scripts nil "html-scripts" org-html-head-include-scripts)
			  (:html-allow-name-attribute-in-anchors nil nil org-html-allow-name-attribute-in-anchors)
			  (:html-divs nil nil org-html-divs)
			  (:html-checkbox-type nil nil org-html-checkbox-type)
			  (:html-extension nil nil org-html-extension)
			  (:html-footnote-format nil nil org-html-footnote-format)
			  (:html-footnote-separator nil nil org-html-footnote-separator)
			  (:html-footnotes-section nil nil org-html-footnotes-section)
			  (:html-format-drawer-function nil nil org-html-format-drawer-function)
			  (:html-format-headline-function nil nil org-html-format-headline-function)
			  (:html-format-inlinetask-function nil nil org-html-format-inlinetask-function)
			  (:html-home/up-format nil nil org-html-home/up-format)
			  (:html-indent nil nil org-html-indent)
			  (:html-infojs-options nil nil org-html-infojs-options)
			  (:html-infojs-template nil nil org-html-infojs-template)
			  (:html-inline-image-rules nil nil org-html-inline-image-rules)
			  (:html-link-org-files-as-html nil nil org-html-link-org-files-as-html)
			  (:html-mathjax-options nil nil org-html-mathjax-options)
			  (:html-mathjax-template nil nil org-html-mathjax-template)
			  (:html-metadata-timestamp-format nil nil org-html-metadata-timestamp-format)
			  (:html-postamble-format nil nil org-html-postamble-format)
			  (:html-preamble-format nil nil org-html-preamble-format)
			  (:html-prefer-user-labels nil nil org-html-prefer-user-labels)
			  (:html-self-link-headlines nil nil org-html-self-link-headlines)
			  (:html-table-align-individual-fields nil nil org-html-table-align-individual-fields)
			  (:html-table-caption-above nil nil org-html-table-caption-above)
			  (:html-table-data-tags nil nil org-html-table-data-tags)
			  (:html-table-header-tags nil nil org-html-table-header-tags)
			  (:html-table-use-header-tags-for-first-column nil nil org-html-table-use-header-tags-for-first-column)
			  (:html-tag-class-prefix nil nil org-html-tag-class-prefix)
			  (:html-text-markup-alist nil nil org-html-text-markup-alist)
			  (:html-todo-kwd-class-prefix nil nil org-html-todo-kwd-class-prefix)
			  (:html-toplevel-hlevel nil nil org-html-toplevel-hlevel)
			  (:html-use-infojs nil nil org-html-use-infojs)
			  (:html-validation-link nil nil org-html-validation-link)
			  (:html-viewport nil nil org-html-viewport)
			  (:html-inline-images nil nil org-html-inline-images)
			  (:html-table-attributes nil nil org-html-table-default-attributes)
			  (:html-table-row-open-tag nil nil org-html-table-row-open-tag)
			  (:html-table-row-close-tag nil nil org-html-table-row-close-tag)
			  (:html-xml-declaration nil nil org-html-xml-declaration)
			  (:html-wrap-src-lines nil nil org-html-wrap-src-lines)
			  (:html-klipsify-src nil nil org-html-klipsify-src)
			  (:html-klipse-css nil nil org-html-klipse-css)
			  (:html-klipse-js nil nil org-html-klipse-js)
			  (:html-klipse-selection-script nil nil org-html-klipse-selection-script)
			  (:infojs-opt "INFOJS_OPT" nil nil)
			  (:creator "CREATOR" nil org-html-creator-string)
			  (:with-latex nil "tex" org-html-with-latex)
			  (:latex-header "LATEX_HEADER" nil nil newline))
			 :filters
			 ((:filter-options . org-html-infojs-install-script)
			  (:filter-parse-tree . org-html-image-link-filter)
			  (:filter-final-output . org-html-final-function))
			 :blocks nil :menu
			 (104 "Export to HTML"
			      ((72 "As HTML buffer" org-html-export-as-html)
			       (104 "As HTML file" org-html-export-to-html)
			       (111 "As HTML file and open"
				    (lambda
				      (a s v b)
				      (if a
					  (org-html-export-to-html t s v b)
					(org-open-file
					 (org-html-export-to-html nil s v b))))))))
   #s(org-export-backend :name ascii :parent nil :transcoders
			 ((bold . org-ascii-bold)
			  (center-block . org-ascii-center-block)
			  (clock . org-ascii-clock)
			  (code . org-ascii-code)
			  (drawer . org-ascii-drawer)
			  (dynamic-block . org-ascii-dynamic-block)
			  (entity . org-ascii-entity)
			  (example-block . org-ascii-example-block)
			  (export-block . org-ascii-export-block)
			  (export-snippet . org-ascii-export-snippet)
			  (fixed-width . org-ascii-fixed-width)
			  (footnote-reference . org-ascii-footnote-reference)
			  (headline . org-ascii-headline)
			  (horizontal-rule . org-ascii-horizontal-rule)
			  (inline-src-block . org-ascii-inline-src-block)
			  (inlinetask . org-ascii-inlinetask)
			  (inner-template . org-ascii-inner-template)
			  (italic . org-ascii-italic)
			  (item . org-ascii-item)
			  (keyword . org-ascii-keyword)
			  (latex-environment . org-ascii-latex-environment)
			  (latex-fragment . org-ascii-latex-fragment)
			  (line-break . org-ascii-line-break)
			  (link . org-ascii-link)
			  (node-property . org-ascii-node-property)
			  (paragraph . org-ascii-paragraph)
			  (plain-list . org-ascii-plain-list)
			  (plain-text . org-ascii-plain-text)
			  (planning . org-ascii-planning)
			  (property-drawer . org-ascii-property-drawer)
			  (quote-block . org-ascii-quote-block)
			  (radio-target . org-ascii-radio-target)
			  (section . org-ascii-section)
			  (special-block . org-ascii-special-block)
			  (src-block . org-ascii-src-block)
			  (statistics-cookie . org-ascii-statistics-cookie)
			  (strike-through . org-ascii-strike-through)
			  (subscript . org-ascii-subscript)
			  (superscript . org-ascii-superscript)
			  (table . org-ascii-table)
			  (table-cell . org-ascii-table-cell)
			  (table-row . org-ascii-table-row)
			  (target . org-ascii-target)
			  (template . org-ascii-template)
			  (timestamp . org-ascii-timestamp)
			  (underline . org-ascii-underline)
			  (verbatim . org-ascii-verbatim)
			  (verse-block . org-ascii-verse-block))
			 :options
			 ((:subtitle "SUBTITLE" nil nil parse)
			  (:ascii-bullets nil nil org-ascii-bullets)
			  (:ascii-caption-above nil nil org-ascii-caption-above)
			  (:ascii-charset nil nil org-ascii-charset)
			  (:ascii-global-margin nil nil org-ascii-global-margin)
			  (:ascii-format-drawer-function nil nil org-ascii-format-drawer-function)
			  (:ascii-format-inlinetask-function nil nil org-ascii-format-inlinetask-function)
			  (:ascii-headline-spacing nil nil org-ascii-headline-spacing)
			  (:ascii-indented-line-width nil nil org-ascii-indented-line-width)
			  (:ascii-inlinetask-width nil nil org-ascii-inlinetask-width)
			  (:ascii-inner-margin nil nil org-ascii-inner-margin)
			  (:ascii-links-to-notes nil nil org-ascii-links-to-notes)
			  (:ascii-list-margin nil nil org-ascii-list-margin)
			  (:ascii-paragraph-spacing nil nil org-ascii-paragraph-spacing)
			  (:ascii-quote-margin nil nil org-ascii-quote-margin)
			  (:ascii-table-keep-all-vertical-lines nil nil org-ascii-table-keep-all-vertical-lines)
			  (:ascii-table-use-ascii-art nil nil org-ascii-table-use-ascii-art)
			  (:ascii-table-widen-columns nil nil org-ascii-table-widen-columns)
			  (:ascii-text-width nil nil org-ascii-text-width)
			  (:ascii-underline nil nil org-ascii-underline)
			  (:ascii-verbatim-format nil nil org-ascii-verbatim-format))
			 :filters
			 ((:filter-headline . org-ascii-filter-headline-blank-lines)
			  (:filter-parse-tree org-ascii-filter-paragraph-spacing org-ascii-filter-comment-spacing)
			  (:filter-section . org-ascii-filter-headline-blank-lines))
			 :blocks nil :menu
			 (116 "Export to Plain Text"
			      ((65 "As ASCII buffer"
				   (lambda
				     (a s v b)
				     (org-ascii-export-as-ascii a s v b
								'(:ascii-charset ascii))))
			       (97 "As ASCII file"
				   (lambda
				     (a s v b)
				     (org-ascii-export-to-ascii a s v b
								'(:ascii-charset ascii))))
			       (76 "As Latin1 buffer"
				   (lambda
				     (a s v b)
				     (org-ascii-export-as-ascii a s v b
								'(:ascii-charset latin1))))
			       (108 "As Latin1 file"
				    (lambda
				      (a s v b)
				      (org-ascii-export-to-ascii a s v b
								 '(:ascii-charset latin1))))
			       (85 "As UTF-8 buffer"
				   (lambda
				     (a s v b)
				     (org-ascii-export-as-ascii a s v b
								'(:ascii-charset utf-8))))
			       (117 "As UTF-8 file"
				    (lambda
				      (a s v b)
				      (org-ascii-export-to-ascii a s v b
								 '(:ascii-charset utf-8))))))))


-- 
Jean

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

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

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

[Ihor Radchenko]

Eduardo Ochs <eduardoochs@gmail.com> writes:

> sorry, I thought that that would be something like a 5-line change... =(
>
> A few messages again I mentioned that one of my plans for these holidays
> was to learn several techniques for debugging elisp that I've postponing
> learning for ages. I'll do that and then I'll try solving this problem
> again.

One way could be M-x debug-on-entry <RET> read-char-exclusive <RET> and
then running the dispatcher. This will pause Elisp execution and leave
the export menu buffer actionable.

However, I doubt that you can make much use of the buffer itself - it is
nothing but text. You need to read the source to understand the logic.
You can use the source code links Jean provided.

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

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> Though, we speak here of non-blicking Org Export, and there are many
> ways to do it, we speak of decisions that are not user friendly, made
> before more than 10 years.
>
> There was enough time to use whatever one wish. I can't wait for
> somebody in mainstream Org to make it user friendly, mouse clickable,
> and so there is enough of it for you to adapt it to your own needs as
> in main stream. 

I was hoping that you might be interested to provide a patch for Org
upstream.

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

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> * Max Nikulin <manikulin@gmail.com> [2023-01-03 15:18]:
>> Jean might be happy with the posted mock-up. Unfortunately that code is too
>> far from been ready to be used for all users. E.g. it does not use
>> `org-export-registered-backends', not to mention that all menus in the
>> package should be consistent. It is OK to have a bunch of repetitive code
>> for a demo, but it can not be taken as is.
>
> After looking into it, into `org-export-registered-backends', I will
> not use it, neither follow the chain of poor design.
>
> Users can get the choice otherwise in my package. I can have my own
> setup and recognition of various exports. 
>
> I can't follow the bad design that happen to take place, so I will not
> lean on this below, I find that complex, while it need not be.

Could you please elaborate what is bad about the design and maybe
provide some ideas how it can be improved?

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

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

[Alain.Cochard]

Ihor Radchenko writes on Thu  5 Jan 2023 11:07:

 > However, I doubt that you can make much use of the buffer itself -
 > it is nothing but text.

Without my suggesting that anything at all should be done, I am
commenting that sometimes one might need that text, if only for
personal notes, and it would be convenient if one could access all
buffers just like we can for (say) the *Messages* buffer. For example,
I recently needed what is seen in the *Org Select* buffer.  I wasted a
bit of time trying, then an extra bit of time managing otherwise.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.cochard@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France     | [ slot available for rent ]

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

[Max Nikulin]

On 05/01/2023 21:41, Alain.Cochard wrote:
> 
> I am
> commenting that sometimes one might need that text, if only for
> personal notes, and it would be convenient if one could access all
> buffers just like we can for (say) the *Messages* buffer. For example,
> I recently needed what is seen in the *Org Select* buffer.  I wasted a
> bit of time trying, then an extra bit of time managing otherwise.

Sometimes I start emacs in a terminal application to copy some "special" 
text (holding [Shift]).

I do not like that in a Gtk window I can not select text appeared in the 
echo area using mouse.

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

[Alain.Cochard]

Max Nikulin writes on Thu  5 Jan 2023 22:00:

 > Sometimes I start emacs in a terminal application to copy some
 > "special" text (holding [Shift]).

Great!  It worked for the *Org Select* buffer.

I did not know that trick. 

Thanks.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.cochard@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France     | [ slot available for rent ]

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

[Eduardo Ochs]

On Thu, 5 Jan 2023 at 08:06, Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Eduardo Ochs <eduardoochs@gmail.com> writes:
>
> > sorry, I thought that that would be something like a 5-line change... =(
> >
> > A few messages again I mentioned that one of my plans for these holidays
> > was to learn several techniques for debugging elisp that I've postponing
> > learning for ages. I'll do that and then I'll try solving this problem
> > again.
>
> One way could be M-x debug-on-entry <RET> read-char-exclusive <RET> and
> then running the dispatcher. This will pause Elisp execution and leave
> the export menu buffer actionable.
>
> However, I doubt that you can make much use of the buffer itself - it is
> nothing but text. You need to read the source to understand the logic.
> You can use the source code links Jean provided.

Hi Ihor,

thanks, good idea! A few days ago I had a similar idea, but mine
was worse... I found, by running this,

  (find-orggrep "grep --color=auto -nH --null -e read-char-exclusive *.el")

that `read-char-exclusive' appears in 29 places in the Org
source, and I was thinking of replacing some of them by a
`my-read-char-exclusive', and then set a breakpoint in
`my-read-char-exclusive'...

I have just tried running this in an Org file,

  (debug-on-entry        'read-char-exclusive)
  (eek "C-c C-e")
  (cancel-debug-on-entry 'read-char-exclusive)

and after running the first two sexps above with my favorite
variant of `C-x C-e' the backtrace showed me that this

  (find-efunction 'org-export--dispatch-action "read-char-exclusive")

is the occurrence that matters - the one inside
`org-export--dispatch-action'. I'll play more with that
soon!

  Cheers =),
    Eduardo Ochs
    http://angg.twu.net/#eev

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

[Jean Louis]

* Alain.Cochard@unistra.fr <Alain.Cochard@unistra.fr> [2023-01-05 17:46]:
> Ihor Radchenko writes on Thu  5 Jan 2023 11:07:
> 
>  > However, I doubt that you can make much use of the buffer itself -
>  > it is nothing but text.
> 
> Without my suggesting that anything at all should be done, I am
> commenting that sometimes one might need that text, if only for
> personal notes, and it would be convenient if one could access all
> buffers just like we can for (say) the *Messages* buffer. For example,
> I recently needed what is seen in the *Org Select* buffer.  I wasted a
> bit of time trying, then an extra bit of time managing otherwise.

Thanks for feedback.

I could when there are 5 people with feedback, there may be other 500
thinking about it.

-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-05 14:16]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Though, we speak here of non-blicking Org Export, and there are many
> > ways to do it, we speak of decisions that are not user friendly, made
> > before more than 10 years.
> >
> > There was enough time to use whatever one wish. I can't wait for
> > somebody in mainstream Org to make it user friendly, mouse clickable,
> > and so there is enough of it for you to adapt it to your own needs as
> > in main stream. 
> 
> I was hoping that you might be interested to provide a patch for Org
> upstream.

Question is: did you try it out?

Once you try it out, then let me know to continue.


The Concept and More Ideas:
---------------------------

1. You can create derived mode, for example Org derived mode.

2. You can create key bindings freely for that derived mode.

3. You can create read-only, temporary buffers for export in that
   derived mode.

4. Because it is read only, similar to modal modes, you do not need
   complicated key bindings, you don't need to use C-combinations for
   few simple things, use simply letter. 

5. Though it implies you can use same key bindings for
   "compatibility", but I would say it rather honestly for bad habits,
   as in the derived.

6. Thus you may make toggling functions.

7. You are free to draw in the buffer and give to user visual feedback
   of what you have toggled or set. Draw it as you wish, ON/OFF or
   BODY/SCOPE, or similar.

8. Use global variables for toggling of Org export settings.

9. Constuct Org elisp: links, but do they support key bindings? You
   can define both.

10. You could even "remember" the global variables in such Org export
    file simply by using file variables.  

11. Org links could provide export.


-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-05 14:17]:
> Could you please elaborate what is bad about the design and maybe
> provide some ideas how it can be improved?

There was choice back in time, before 10 years, to provide to user few
keys to run some functions, like Org export. That itself is not bad,
but when it started expanding into now more than 100+ different
exports, Org requires every new package to define what? Keys? So every
package author is supposed to provide keys and various snippets of
text, because they have to accommodate initial and outdated notion on
using simple menu.

Org Export is not any more simple menu.

And Org users are in quite peculiar mode, with headings, TODO, tags,
so in my personal logic it does not make sense NOT to provide to Org
users Org based buffers where they can fold or unfold headings, freely
use mouse to export, or keys, and watch in one window the buffer with
menu like RCD Org Export, and in other windows other exports appearing
in various versions, minimizing repetition, and helping user become
more efficient.

The ideas have been sent as concept to you, then as full package,
which I now use daily, so it is to derive the mode, define key
bindings, decide how to display toggling of variables for body, scope,
async, etc. and generate hyperlinks for export.

RCD Dashboard package is made to help other similar things to be
created, and I wish to liberate it even from Org mode.

I use daily RCD Dashboard, as it is package for packages in now
multiple screens appearing automatically, imagine intersections of
elementary objects like headings, or files, with their names,
appearing in generated Org buffers with hyperlinks.

-- 
Jean

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

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

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

[Eduardo Ochs]

On Thu, 5 Jan 2023 at 12:19, <Alain.Cochard@unistra.fr> wrote:
>
> Max Nikulin writes on Thu  5 Jan 2023 22:00:
>
>  > Sometimes I start emacs in a terminal application to copy some
>  > "special" text (holding [Shift]).
>
> Great!  It worked for the *Org Select* buffer.
>
> I did not know that trick.

Hi Alain,

here is what I am doing to try to understand those buffers using
eev-isms. I am keeping this in one part of my notes,

  (org-mode)
  (debug-on-entry        'read-char-exclusive)
  (eek "C-c C-e")
  (cancel-debug-on-entry 'read-char-exclusive)
  (fundamental-mode)

and to make the "*Org Export Dispatcher*" appear I run the first three
sexps with my favorite variant of `C-e C-x C-e'.

Then I did this to pretty-print the buffer-list,

  (find-eppp (buffer-list))

and this to save the contents of that buffer in a variable:

  (with-current-buffer "*Org Export Dispatcher*"
    (setq o (buffer-string)))

Cheers,
  Eduardo Ochs
  http://angg.twu.net/#eev

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

[Max Nikulin]

On 06/01/2023 02:37, Jean Louis wrote:
> * Ihor Radchenko [2023-01-05 14:17]:
>> Could you please elaborate what is bad about the design and maybe
>> provide some ideas how it can be improved?
> 
> There was choice back in time, before 10 years, to provide to user few
> keys to run some functions, like Org export.

Sorry, but your response just repeats complains concerning blocking menu 
that you posted earlier many times. I do not see anything related to 
your original statement:

> After looking into it, into `org-export-registered-backends', I will
> not use it, neither follow the chain of poor design.

Could you, please, concentrate on your vision of proper 
`org-export-registered-backends' design? Personally, I see no major 
issues, the approach is usual for enabling third-party plugins. From my 
point of view, the structure is organized well enough to allow 
alternative implementations of export menu. That is why I am surprised 
that such statement appeared in a topic dedicated to UI.

Do not repeat that blocking menu is not convenient enough sometimes. Say 
what should be used instead of `org-export-registered-backends'.

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

[Max Nikulin]

On 06/01/2023 02:19, Jean Louis wrote:
> 
> The Concept and More Ideas:
> ---------------------------

Was there any messages with arguments that Org should stick to blocking 
menu?

It is not about UI ideas, it is not about counting people who agrees 
that menu should be non-blocking (I do not remember who is on the 
opposite side).

It is about providing a patch that implements a better menu UI. Of 
course, the code must be maintainable and it should not have confusing 
behavior.

For a while quick and dirty blocking menu allowed to emerge great 
variety of export backends and to postpone issues related to interaction 
between buffers when user is not restricted in respect to jumping to 
another buffer.

Making more noise and repeating obvious ideas does not help to create a 
consistent implementation.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> I was hoping that you might be interested to provide a patch for Org
>> upstream.
>
> Question is: did you try it out?
>
> Once you try it out, then let me know to continue.

I did try it. I am in favour of the non-blocking menu. Other people
participating in this discussion too.

As I said, the requirement to get it into the core is re-creating
previous layout and bindings. The layout and bindings may be
customizable, but they must be available.

> The Concept and More Ideas:
> ---------------------------
>
> 1. You can create derived mode, for example Org derived mode.

This has pros and cons. Org derived mode means that personal
customization, including key bindings and themes, may affect menus. This
may or may not be desired.

> 2. You can create key bindings freely for that derived mode.

+1

> 3. You can create read-only, temporary buffers for export in that
>    derived mode.

I am not sure what you are referring to.

> 4. Because it is read only, similar to modal modes, you do not need
>    complicated key bindings, you don't need to use C-combinations for
>    few simple things, use simply letter. 

Same as what we do now in the menus. I do not think that we need to
change the existing bindings (by default).

> 5. Though it implies you can use same key bindings for
>    "compatibility", but I would say it rather honestly for bad habits,
>    as in the derived.

As I said earlier, "bad habits" is a judgment. We will not break user
experience if we don't have to. It includes existing bindings.

Introducing alternatives is possible though.

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

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> * Ihor Radchenko <yantar92@posteo.net> [2023-01-05 14:17]:
>> Could you please elaborate what is bad about the design and maybe
>> provide some ideas how it can be improved?
>
> ...
> The ideas have been sent as concept to you, then as full package,
> which I now use daily, so it is to derive the mode, define key
> bindings, decide how to display toggling of variables for body, scope,
> async, etc. and generate hyperlinks for export.

I though that you objected the design of `org-export-define-backend' and
the backend objects. Menus have little to do with it, merely following
the key bindings suggested by export backend authors.

If you just object the export menu system, let's go back to the main
discussion about non-blocking menus in other branches of this thread.

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

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-07 12:04]:
> As I said, the requirement to get it into the core is re-creating
> previous layout and bindings. The layout and bindings may be
> customizable, but they must be available.

You have got the concept, you may implement it.

> > The Concept and More Ideas:
> > ---------------------------
> >
> > 1. You can create derived mode, for example Org derived mode.
> 
> This has pros and cons. Org derived mode means that personal
> customization, including key bindings and themes, may affect menus. This
> may or may not be desired.

It was example of the mode. You may use any mode you wish. I said it
is example. 

Though I do not know how personal customization may affect the
generated temporary Org buffer which sole purpose is to invoke
functions.

If for example, export of body only is somewhere customized than
package similar to RCD Org Export may set those variables
correspondingly, or recognize user's options.

> > 3. You can create read-only, temporary buffers for export in that
> >    derived mode.
> 
> I am not sure what you are referring to.

You have to review the concept I have sent. A temporary generated
buffer is used as menu, in read-only mode. Of course you don't want to
users to write into temporary generated buffer (RCD Org Export), but
if they really want, they can turn off read-only-mode. Because you
wish to setup key bindings, you should use derived mode. I am
referring to concept how you would do the non-blocking menu.


> > 4. Because it is read only, similar to modal modes, you do not need
> >    complicated key bindings, you don't need to use C-combinations for
> >    few simple things, use simply letter. 
> 
> Same as what we do now in the menus. I do not think that we need to
> change the existing bindings (by default).

All is your choice. I am giving you concept on which you can build.

> > 5. Though it implies you can use same key bindings for
> >    "compatibility", but I would say it rather honestly for bad habits,
> >    as in the derived.
> 
> As I said earlier, "bad habits" is a judgment. We will not break user
> experience if we don't have to. It includes existing bindings.
> 
> Introducing alternatives is possible though.

Of course it is judgment, and nothing wrong with it, I keep judging
it, that is why I don't use it, it is disturbing. All opinions are
judgments. Though my judgments are based on experience with Org and
many other software, it is informed opinion, not just a biased opinion
without inspection. It is opinion with a solution. People make
opinions all the time, that something is judgment is obvious.


-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-07 12:04]:
> > The Concept and More Ideas:
> > ---------------------------
> >
> > 1. You can create derived mode, for example Org derived mode.
> 
> This has pros and cons. Org derived mode means that personal
> customization, including key bindings and themes, may affect menus. This
> may or may not be desired.

OK so to be constructive, you have to start somewhere.

Question is:

1. Do you want Org Export menus to appear in non-blocking buffer? So
   far I understood, answer is YES.

2. Then do you want derived buffer? If yes, which one? It is necessary
   as to be able to assign key bindings that work only in such
   buffer. My recommendation is that it is derived from org-mode.

   I can't see how personal customization affects the buffer look. The
   theme or Org themes if such exist may affect it, so what? That was
   choice of the user. Emacs themes anyway affect the current org
   export buffer.

   Those are very minor issue, decide if you wish derived mode, and
   make definition for it.

> > 2. You can create key bindings freely for that derived mode.
> 
> +1

Then make list of what is always to be there and with which key
bindings.

I would say make a package that is separate from Org so that it can be
add-on for some time, until people can test it.

Once there is list of options which always must be there, with key
bindings, then you make functions to display those options.

-- 
Jean

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

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

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-06 06:30]:
> Could you, please, concentrate on your vision of proper
> `org-export-registered-backends' design? 

I leave that to Org developers. That variable is not described well,
neither mentioned in Org manual.

I can only reiterate my point which you did not understand. In Emacs
there are thousands of extensions. There is mainstream Emacs and there
are ELPA, and other repositories and all kinds of Emacs packages.

Functions found in those packages may be commands (interactive), and
it is up to user how to bind those keys. 

Read (info "(elisp) Key Binding Conventions")

Based on that I don't find it consistent that in variable
`org-export-registered-backends' Org has something like this:

(85 "As UTF-8 buffer"
	   (lambda
	     (a s v b)
	     (org-ascii-export-as-ascii a s v b
					'(:ascii-charset utf-8))))

as that asks for key probably 85 to be defined for that specific
function.

And the design of that variable leads to Gordian knot of the tangled
code because it demands from all other exporters and extensions to
follow that principle.

And principle is not consistent to (info "(elisp) Key Binding Conventions")

So why do that?

I recommend not binding authors of Org export packages to provide
keys and let users be free to decide which keys to use for which
export. 

I can think that by clicking first time on a menu item in RCD Org
Export, that I can ask user if to assign which key for that export,
and remember that option. Provide something like that, a helpful
assistance function that when some option is invoked multiple times,
that computer may offer to user to assign it permanently to some key.

Or when some prefix is invoked that user may decide which key to use,
and that key is remembered for next sessions.

In general, leave to users how to bind keys.

> Do not repeat that blocking menu is not convenient enough sometimes. 

I am repeating it thousands of times on website pages. If it disturbs
you, is personal problem, which I can't help with. Some things don't
get done unless points are repeated..

> Say what should be used instead of `org-export-registered-backends'.

Before to tell that, you should describe that variable better.

"List of backends currently available in the exporter.
This variable is set with `org-export-define-backend' and
`org-export-define-derived-backend' functions."

What I see from RCD Org Export view point is that:

- there is variable `org-export-backends' which says which exports are
  customized by user to be "there". In my case:

  org-export-backends ➜ (org odt md latex html ascii)

- I would like menu in RCD Org Export to appear for those backends
  which are customized by user. So I have 3 solutions, one is totally
  independent of Org mainstream, which would simply recognize those to
  me known exporting functions and show the menu of whatever packages
  are available for export, and other would be convenient, to
  recognize what user wants and offer only that. Or combination of
  those.

Sorry, I do not understand why `org-export-backends' do not recognize
all the pandoc based exports. I do understand why those exports appear
in the org-export-dispatch menu. 

Is then Org consistent to user that user can turn on, turn off, any
export that user wish or want?

Or is not consistent? It appears not consistent for ox-pandoc package.

If Org is not consistent, then I better build on the external
foundation without asking Org variables, but just recognizing which
functions already exist.

I can as well simply parse variable `org-pandoc-menu-entry' for
construction of the menu.

-- 
Jean

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

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

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

[Max Nikulin]

On 08/01/2023 03:07, Jean Louis wrote:
> * Max Nikulin [2023-01-06 06:30]:
>> Could you, please, concentrate on your vision of proper
>> `org-export-registered-backends' design?
> 
> I leave that to Org developers. That variable is not described well,
> neither mentioned in Org manual.

Org has user manual, but not developer manual. Doesn't 
`org-export-define-backend' provide enough details concerning 
`org-export-registered-backends'?

Your vision of `org-export-registered-backends' design might shed some 
light why you consider its design as poor. I do not see any real problem 
to use it as is with a better menu implementation.

> I can only reiterate my point which you did not understand. In Emacs
> there are thousands of extensions. There is mainstream Emacs and there
> are ELPA, and other repositories and all kinds of Emacs packages.

I am aware of it. In the context of export menu, third party package may 
register their export function.

> Based on that I don't find it consistent that in variable
> `org-export-registered-backends' Org has something like this:
> 
> (85 "As UTF-8 buffer"
> 	   (lambda
> 	     (a s v b)
> 	     (org-ascii-export-as-ascii a s v b
> 					'(:ascii-charset utf-8))))
> 
> as that asks for key probably 85 to be defined for that specific
> function.
> 
> And the design of that variable leads to Gordian knot of the tangled
> code because it demands from all other exporters and extensions to
> follow that principle.

I do not see any problem. The structure associates export functions, 
titles and hints for key bindings. It is normal for UI to have 
accelerator keys. If you do not like suggested key, you are free to 
override it in your menu framework. What code is tangled from your point 
of view? In the posted snippet I see a declaration of a function that 
should be exposed to UI.

 > I recommend not binding authors of Org export packages to provide
 > keys and let users be free to decide which keys to use for which
 > export.

Allowing users to customize key bindings is not the same as imposing 
obligations to choose key bindings. You are free to not provide default 
key bindings or to shuffle menu entries by popularity for "convenience" 
in *your* packages. Default keys means consistency for novices and users 
who do not want to customize such aspects.

> And principle is not consistent to (info "(elisp) Key Binding Conventions")

I see just a minor issue that ESC ESC does not dismiss menu. C-g still 
works. Local variables dialog ("do you want to apply...") behaves 
similar to Org menus. There is enough room for improvements, but I would 
not call it a great trouble.

> I am repeating it thousands of times on website pages. If it disturbs
> you, is personal problem, which I can't help with.

I do not care what you are posting on some websites. I do not like that 
in messages sent to my email you are repeating the same obvious ideas 
even when asked to clarify your particular statements.

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

[Max Nikulin]

On 07/01/2023 16:04, Ihor Radchenko wrote:
> 
> As I said, the requirement to get it into the core is re-creating
> previous layout and bindings. The layout and bindings may be
> customizable, but they must be available.

I would say, a layout that is not worse than the current one. Org menus 
may have more than 1 column and it is advantage for wide windows. A 
distant goal might be a menu that is more flexible and may adapt for 
single column suitable for a narrow side window.

Another issue is accessibility. Too long menus are likely terrible for 
users relying on Emacspeak. I have no idea how to deal with such case, 
perhaps a better organized hierarchy unveiled level by level. API 
conventions that allows to change menu implementation may be a rescue as 
well.

Tim Cross. Re: Proposal: 'executable' org-capture-templaes. Mon, 06 Jun 
2022 09:05:29 +1000 https://list.orgmode.org/87sfoi1xde.fsf@gmail.com/

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 07/01/2023 16:04, Ihor Radchenko wrote:
>> 
>> As I said, the requirement to get it into the core is re-creating
>> previous layout and bindings. The layout and bindings may be
>> customizable, but they must be available.
>
> I would say, a layout that is not worse than the current one. Org menus 
> may have more than 1 column and it is advantage for wide windows. A 
> distant goal might be a menu that is more flexible and may adapt for 
> single column suitable for a narrow side window.
>
> Another issue is accessibility. Too long menus are likely terrible for 
> users relying on Emacspeak. I have no idea how to deal with such case, 
> perhaps a better organized hierarchy unveiled level by level. API 
> conventions that allows to change menu implementation may be a rescue as 
> well.
>
> Tim Cross. Re: Proposal: 'executable' org-capture-templaes. Mon, 06 Jun 
> 2022 09:05:29 +1000 https://list.orgmode.org/87sfoi1xde.fsf@gmail.com/

I do not insist of extending the functionality. Step one is re-creating
the existing one, including echoing the selected menus, as we do
already.

If we can achieve this, the whole menu library might be moved out of Org
into Emacs core and get further developed there. But it is too early to
talk about this now. I first want to see (with real working patches for
Org) if it is feasible to re-create the existing menus using the
proposed approach.

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