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 WGd1G9nFqWNrCAAAbAwnHQ (envelope-from ) for ; Mon, 26 Dec 2022 17:03:37 +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 UESCG9nFqWNAFAAA9RJhRA (envelope-from ) for ; Mon, 26 Dec 2022 17:03:37 +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 D96B534611 for ; Mon, 26 Dec 2022 17:03:36 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p9pw7-0001Au-92; Mon, 26 Dec 2022 11:02: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 1p9pw5-0001Ai-3h for emacs-orgmode@gnu.org; Mon, 26 Dec 2022 11:02:45 -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 1p9pw2-0003vL-JP for emacs-orgmode@gnu.org; Mon, 26 Dec 2022 11:02:44 -0500 Received: from localhost ([::ffff:197.239.12.248]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103841.0000000063A9C5A2.00002B4D; Mon, 26 Dec 2022 09:02:40 -0700 Date: Mon, 26 Dec 2022 18:58:33 +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> <87fsd2qy4e.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87fsd2qy4e.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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672070617; 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=Ae8w+5YaqL38wTctAfEHRfhbv1T9PpXt8rGyr8beVOA=; b=LD1ifn8/qdZB/4ZVp+1E/CIQId/iVKo6fSwQMPa23tSk/ZjG4dQ+EuzeyeysxXSI+WQy7T y/znvmPnyZxVn8p+vTp7GfzAVUMGHAXnqHTrI4g5znkqY8BaQLrzPB19Np4mYxyZ6QFLS1 V6aa1cjixaaLWCa0nbgyvdn3QFCWnaAan43K4iy3jnPxd38lBYFtJsGw8iNFZVJ1wt7DUW TENg+XQ/3L6xrydspbW2/DBk3QQwDrm2cy+0D6uh64zpNUWzuX5txzrMbRiynOd0QKovZx HWy9SyvB3rgS4rK5uluykoKEJUK8KRfQJe8w4tT67BCbETFIF88E9H/5J9R1Cg== 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=1672070617; a=rsa-sha256; cv=none; b=nRF5QWDiUA18wUXcmv/rITAntws3F4f7U2k0FREVlbc7Sf4LIDfiysYHWZbfktAecUu5Gj dzuvxAeFCs+N3Ir4BKx+3xPL03STmJVVSqVhvvMHbHX25n8AuixG9hdih0b5BWzZ1vaqf3 fNnivseqYzNOxgN40Hsp3/vKAnR+Z/7mk9EjdYTqeREAAPNJAAYM1K0rYAk3BeF8ZEOzJf HUMpgNqNrA3cE7TvgJfJPP0HlmP7O7wIWJoH+RVThzNkinEeI2KKVns47v7eByyBxjESGa alt3fIEijUKfbm9MqGP1R9jsRiDHjDFvmYoaip/Yq/13TnqWUNuBNubImIxlqQ== X-Spam-Score: -2.33 X-Migadu-Queue-Id: D96B534611 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: -2.33 X-TUID: wCtnJr5Dos6T * Ihor Radchenko [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/