From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id qAk3HBByqWNTRAAAbAwnHQ (envelope-from ) for ; Mon, 26 Dec 2022 11:06:08 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id KGtGHBByqWPONgEA9RJhRA (envelope-from ) for ; Mon, 26 Dec 2022 11:06:08 +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 E894212252 for ; Mon, 26 Dec 2022 11:06:07 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p9kLx-0004Sa-8T; Mon, 26 Dec 2022 05:05:05 -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 1p9kLu-0004S4-LL for emacs-orgmode@gnu.org; Mon, 26 Dec 2022 05:05:02 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p9kLr-0001ZB-VB for emacs-orgmode@gnu.org; Mon, 26 Dec 2022 05:05:02 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D3E19240138 for ; Mon, 26 Dec 2022 11:04:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1672049097; bh=oUZE5UaFQdRTTx9lQkvD7IbG91RJLWWEfNKNowSVH08=; h=From:To:Cc:Subject:Date:From; b=GfAWE4Cy4kGo5b84jV5UJ6f3J9ceKKDqmeOn8nU4MReQZ3/uz1Z3gy+Y123CqtiFN JM5koHt+H5TErIiPSiC8YmZ3+2lh8g0/xOgIEYq0MnhloKnkgIDLgJ0nX/PAAV9tOl SExxldvs3Xodc3iRvhv2O73HlZPZS7ZySf6LJ6Kw2yxejSnuxrps0QkkfwMJjeTPim U0hH9vj7czS+SJ6kTY/14OTEsWwOMVdlUXuWx0LQm+dPvX7wa81OAzQKdmByWpNegD ZWc67pDXREgwnM50SAZct5F6Q96LJef1Yb26HETk1JWyptDfjS7tgPGgwptiTDjqOs skzM3gegJIqDg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NgYLG6pbwz9rxH; Mon, 26 Dec 2022 11:04:54 +0100 (CET) From: Ihor Radchenko To: Jean Louis Cc: andre duarte bueno , emacs-orgmode@gnu.org Subject: Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org, In-Reply-To: References: <878rj469sk.fsf@localhost> <87a63bsn53.fsf@localhost> Date: Mon, 26 Dec 2022 10:04:49 +0000 Message-ID: <87fsd2qy4e.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GAPPY_SUBJECT=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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=1672049168; 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:dkim-signature; bh=4jnlHmkYmzD+HUE21UJS5yFHRaxzDc8SzxK8GcU7zIo=; b=p1H52z5kAmHmBUFq2DS8ntg9cH1pSnK5v9QvKHglqGI7hQRMGsd4jBcEEsbVOqmlfHJTBC MEEFOUTgjbA8HK2kjDvBrPO4pEvGlG51iFMEaG4OX36EPyVmEWW8aOZzm2xPyqPiNbVy6w TmTDnXrTuooYbqIfhBaJnXsiPDS2cpi7L+n2jvYOBdbk9UMxtk4XeAcThLSQ9dHUVJ4BPc QIonr7a4UePGyxESZIrYlppigE/28Uhd6ObOl86GPdWbyvtj7gMrvsptORgjaI/sUTUQ2q Md2WPEO0DXmBLQQVdIiPbWdSjEymMozHfwdyVW6YmnSITkuMejYuHxIHNxwYiQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GfAWE4Cy; 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=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672049168; a=rsa-sha256; cv=none; b=sVrrWy8qa98k+bUnBBeJCMbT3KHuEWWe5fT7fLuGVbBrg2qlzpx0vFobc8ufNBRgGAORTV U1dCXP7/wW8lCFaUBzTaW0kxNDgXgMDkg1Foj16rE+MJOyVP0EgzTOpK+eVbc0X4pXfJtF TZngo2g+TWUApxkS7K1wKDRzAK3my6PZrVDRMvfdinsL/g0OeLexC4VNxf2pfrKIjIfnrS hpizc9PeB45lqwSV2Z1PNaKF7lpZFvmxtjCCwL3XDdtxSAnNVynrp82zKre2F+5uD0UX3A vbbJP9WMwJeuITucKyy9b9r4NQZgzHEbagCee0mc1vNcMMJZ5iLkth1PMt6zZg== X-Spam-Score: -5.47 X-Migadu-Queue-Id: E894212252 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GfAWE4Cy; 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=pass (policy=none) header.from=posteo.net X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -5.47 X-TUID: ZC77UGN6YBjr Jean Louis writes: >> > That is not first complaint, right? I would say it is obvious that >> > such interface is not user friendly.=20 >>=20 >> 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!=20 > > User preferring existing functions have basically more or less how > many choices? One. So that is why they "prefer" it.=20 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. >>=20 >> 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=E2=84=A2 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.=20 > > 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.=20 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.=20 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.ca= mel@heagren.com >>=20 >> 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. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at