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 DKSPCxJxqGPtAwEAbAwnHQ (envelope-from ) for ; Sun, 25 Dec 2022 16:49:38 +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 IK3JCRJxqGPtXgEAG6o9tA (envelope-from ) for ; Sun, 25 Dec 2022 16:49:38 +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 D8C6B9A60 for ; Sun, 25 Dec 2022 16:49:36 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p9TF3-0004OP-Ei; Sun, 25 Dec 2022 10:48:49 -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 1p9TF1-0004OF-R8 for emacs-orgmode@gnu.org; Sun, 25 Dec 2022 10:48:47 -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 1p9TEy-00044c-Ue for emacs-orgmode@gnu.org; Sun, 25 Dec 2022 10:48:47 -0500 Received: from localhost ([::ffff:197.239.13.211]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103841.0000000063A870DC.0000383C; Sun, 25 Dec 2022 08:48:44 -0700 Date: Sun, 25 Dec 2022 18:43:01 +0300 From: Jean Louis To: Ihor Radchenko Cc: 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: Ihor Radchenko , andre duarte bueno , emacs-orgmode@gnu.org References: <878rj469sk.fsf@localhost> <87a63bsn53.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87a63bsn53.fsf@localhost> 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-Seal: i=1; s=key1; d=yhetil.org; t=1671983377; a=rsa-sha256; cv=none; b=c9jva8o0830TfqcNPaOSEfbb+YRrPM0A35iwou1t4y8AODCHyk9FzW1r06t4xt/b1mUDgt y1PojFW75bobGv/M429c5qGtD6RulheH8llvrDX++Owje+tmvfQnn28Iv6HDp+e0+KAGYV iKSTu3BaPMrTEmJHt/SgYhuyCwjxGZ1jbWGEY/yUpI8ih9t51fuGG4Wih49DrRthM3/Lv5 I84VKUWDGz+HcKqA4zOMK/EZgPgISzc6VdXFrzdjvPHOmAuAy8w0FMlirwlrI1XutopsFz TDeytCmLDO+XW6G71JvTSfrQ/GfmQVlN7+ysSiSFr8ZU6K9CeCjB959B9X96qg== 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1671983377; 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=Mg+g39wgkISDDo0/S1Z834C+PORnYOaM2X7DB6uEVi8=; b=Xj0c1zh5yNqLxWW2HSHJwSQegZiqrHO4wd8y3Vy5vLxGq4qElDfLe4pgs0cel95DYtdQH/ HnVevfB6u+t7BsiTVX2YO01DEFPF3oBUXfgCrzQlUmHCaAlzZwUjYH16ZW+75jaCUoJS5s a/PHUbwhZwn3ZKta4xCr5bDm2cjRwiY0a7LEGoz+1MxapYFgKmoFAqsQxkJ6gtJZ1Sb3oy hzsSPQQ38jgiUFTLXo0XoiCnkEEXGGZjTVj1Le+x4TFYF8erSV99NI9+2nuR1GCXbz1qkn xIYwyeFQn58J01AU+spwjwJjfFjOUH3XvISGtu0SGmsa8lZRcxH4DjpvV3duyQ== X-Spam-Score: -3.62 X-Migadu-Queue-Id: D8C6B9A60 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: scn0.migadu.com X-Migadu-Spam-Score: -3.62 X-TUID: jS2Dd7wOer6A * Ihor Radchenko [2022-12-25 15:07]: > Jean Louis 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/