From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id qNANGr3Yr2N+QgEAbAwnHQ (envelope-from ) for ; Sat, 31 Dec 2022 07:37:49 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id +HNDGb3Yr2N3FwAAG6o9tA (envelope-from ) for ; Sat, 31 Dec 2022 07:37:49 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C2A7D24D6A for ; Sat, 31 Dec 2022 07:37:48 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBVU7-0004EW-J6; Sat, 31 Dec 2022 01:36:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBVU4-0004EJ-60 for emacs-orgmode@gnu.org; Sat, 31 Dec 2022 01:36:44 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBVU1-0001cg-N8 for emacs-orgmode@gnu.org; Sat, 31 Dec 2022 01:36:43 -0500 Received: from localhost ([::ffff:102.87.61.67]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055D55.0000000063AFD85A.00006CC1; Fri, 30 Dec 2022 23:36:09 -0700 Date: Sat, 31 Dec 2022 09:19:31 +0300 From: Jean Louis To: Eduardo Ochs Cc: Ihor Radchenko , andre duarte bueno , emacs-orgmode@gnu.org Subject: Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org, Message-ID: Mail-Followup-To: Eduardo Ochs , Ihor Radchenko , andre duarte bueno , emacs-orgmode@gnu.org References: <878rj469sk.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, GAPPY_SUBJECT=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672468669; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=+mlz+lnIkkaCAjLvmFBFIDUcI3TtFUU8O10pMOQVbpU=; b=Gq2Su+fXiD9+8iDSshyURcZa3Te6mFLueDeJFhVrA9V2EIRdOCUvhewfYYjQ8Zwn2EDnc7 eFU640l5quWaEpnw47hbcOlyAZ3Fgm8T39+8RnEJjviZAa9Kmi2wUQjrZWXEJj4li+pzy+ EHhoCooJfOtkRTRtuPaDMQBF9W0wW4laAW0X17sLKRkMahspP9A91mLtDMJpptW82o9jsH yu6Ci/ZBVsiYqoaBY4f+zMtkIQ6euYZeeJPFkf/iq7yFYpEgZuyZ49IPnVp2LpnWayQ2G0 iMsD2jITbZzRFG06F4NFwV+G9i7DKwqDeIQhalmPVVSM2+DvxO6s3OcKnhyOqg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672468669; a=rsa-sha256; cv=none; b=upWOklyguX1IiuqC6TZvegTK7u1ib3+WQx2uUQg8gz3xEjWgIMYQo7f3VEuR53Yzj//ppH W2fxlbR04/yis1C7DvIukJldoxHG5pbzS7tqeoM/90JQh6EkmvMxk8/bIMm12b0w0rxW7d JvAmBcX9C0BY/lLvesYNYMnd3hKCWJPITa466xaNlWagD6mfo3j2v+C7250eEKo2J151pB hrPJm7Vb2C3VNlUYAl9vb4LHqI9S0uM+I0mSu3MKTevHaL+R1+bt4Ncus5Tfx86LT+WmY5 TBDQJmXoXOF1J07SpTJEUf3Qp/f+DfqTVmP92PmYeVX/O9ahquzRs5pp57vbQA== X-Spam-Score: -1.34 X-Migadu-Queue-Id: C2A7D24D6A Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -1.34 X-TUID: ZKwCJOfUnank * Eduardo Ochs [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/