From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 0HR4JFNsx1+mKwAA0tVLHw (envelope-from ) for ; Wed, 02 Dec 2020 10:28:35 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id uOBVIFNsx1/TIAAAB5/wlQ (envelope-from ) for ; Wed, 02 Dec 2020 10:28:35 +0000 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 F0AF894043A for ; Wed, 2 Dec 2020 10:28:34 +0000 (UTC) Received: from localhost ([::1]:59198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkPNA-0002aR-Hg for larch@yhetil.org; Wed, 02 Dec 2020 05:28:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48280) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkPAH-0004Zx-LY for emacs-orgmode@gnu.org; Wed, 02 Dec 2020 05:15:13 -0500 Received: from static.rcdrun.com ([95.85.24.50]:36207) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkPAC-0002Uq-7k for emacs-orgmode@gnu.org; Wed, 02 Dec 2020 05:15:13 -0500 Received: from localhost ([::ffff:197.157.0.57]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0007.000000005FC76929.000060DA; Wed, 02 Dec 2020 10:15:04 +0000 Date: Wed, 2 Dec 2020 13:12:26 +0300 From: Jean Louis To: Ihor Radchenko Subject: Re: One vs many directories Message-ID: References: <87mtz84om9.fsf@localhost> <87360yegmg.fsf@web.de> <87h7pdc0q8.fsf@web.de> <87ft4xbqwm.fsf@localhost> <87wny89rj7.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87wny89rj7.fsf@localhost> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Dr. Arne Babenhauserheide" , Texas Cyberthal , emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: 1.22 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: F0AF894043A X-Spam-Score: 1.22 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: ptmSC+ubaiFj * Ihor Radchenko [2020-11-26 16:29]: > > Sorry for that vague expression. Let us say I open Completions buffer > > I can switch into it, inspect it, ask for defined keys, evaluate with > > M-:, Emacs allows me to remain in the window and go to other > > window. Agenda buffer does not do that, this is probably because it > > just waits for any key and does not allow anything else. That means I > > will open Agenda and I cannot switch to other window, so I will close > > agenda to switch. Maybe I have 10 TODO keywords, I have to open file, > > I open Agenda again, aha, T... then close agenda, open file see > > keyword, then open agenda again. Repetitions without end and user is > > unable to use multiple windows. This really need not be so. > > It appears to me (correct me if I am wrong) that you haven't tried > agenda multi-occur/keyword/etc searches. I know multi-occur and tried it. Functions of org-agenda are useful while initial menu window of org-agenda is so much less useful and I speak of menu, not of individual functions. If it is Org agenda, I see no reason why it could not be displayed in Org mode being read-only and having buffer not killed when user press q. We spoke of standard Emacs way. Normally buffers are not killed. If I press q in Dired buffer is just buried, not killed. I find Org agenda useful and I would be maybe moving to *Agenda Commands* buffer by using (next-buffer) and (prev-buffer) and those are key bindings like hyper key - move-end-of-line and hyper key - move-beginning of line. It is my standard behavior to move to one buffer and go to other buffer. User could have one tab open for Org agenda menu, other tab for work. Why invoke all time C-c a to access org agenda. I am not speaking for me personally, I am giving you clear comparison of that menu to mu4e or org-agenda menu and other pop-up features that do not block user in using Emacs. Org agenda menu blocks the interface! When invoking package-list-packages it does not block me moving to other buffers and also offers complex menu system and key bindings. Buffer is not killed but burried when I press q. Functions of org agenda are fine, this is reference to blocking of Emacs interface while opening Org agenda buffer. It diminishes usability. I guess nobody cares. It is how it is. No need to consult external references such as https://www.nngroup.com/articles/usability-101-introduction-to-usability/ No need even to look how other parts of Emacs are interacting with user and to harmonize the menu. > > You know how agenda is made like the 1985 BASIC menu in Commodore > > C=64, but even back then there was better interface for such menus. > > FYI. Transient.el - menu dispatcher in popular magit package also does > not let you switch buffers. So, apparently many people would not agree > that it is so terrible design. Compare things to things that are better not to things that are worse. You have to read more about usability. To know what is the problem you have to research and not assume that if nobody says anything that it is usable enough. Nobody complains. I did not hear complain, so it must be perfect. Irony. That is not how interfaces get improved and definitely not how developer would discover if something is wrong. If developer is waiting for somebody to complain that will be too late. Thousands of users will have problems that were not told to developer. Was there any methodology to decide what is good user menu? Reference: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ Was there any survey here to ask about any usability?! Hypothetical question. > P.S. Nothing prevents you from calling, i.e. M-x org-occur or binding it > to a key of your choice. Personally I know that. I speak for general usability. You know that I have my system of doing things with or without Org mode.