* Eduardo Ochs <eduardoo...@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/
