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 aPouD/RBnWIW0AAAbAwnHQ (envelope-from ) for ; Mon, 06 Jun 2022 01:53:24 +0200 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 QJArDvRBnWIqEAAAG6o9tA (envelope-from ) for ; Mon, 06 Jun 2022 01:53:24 +0200 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 7FB1522934 for ; Mon, 6 Jun 2022 01:53:23 +0200 (CEST) Received: from localhost ([::1]:49816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ny03d-0002oi-QG for larch@yhetil.org; Sun, 05 Jun 2022 19:53:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36510) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ny038-0002nc-1N for emacs-orgmode@gnu.org; Sun, 05 Jun 2022 19:52:50 -0400 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:51890) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ny036-0001Cq-2j for emacs-orgmode@gnu.org; Sun, 05 Jun 2022 19:52:49 -0400 Received: by mail-pj1-x1030.google.com with SMTP id cx11so11506298pjb.1 for ; Sun, 05 Jun 2022 16:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=eC03lVngMj0xGdd2YAtjG2n0Kao1tIyXKVSyjeODo04=; b=b7kWOwH0g2LNZe8i1R/NrMHH6HI08uOGjqDWZI+KgQCQxT5UGwYjgumSgWZQGmjXiU l+96xHrGKIi826akxV2D5bVdw3IOA+xLKJ7CYU3sRYvmdjUxg7s49dIGmYrFwVytxzRi j8z6J8nhb/bqDUYFuTfeGf/Am9OkLp5pmZjlUxwEW+FJWVwUghPc75uONVQawHZB44L/ 3br8oweBfKTVeq2kGob0bX0hLdH6koMvSNYHxT1niHz6XU4z1BRD4sPhoHCKMdlbi/jY Q3dy1BcKN4R52Awweozy0pnGLUdzw1OuNK5c5ArXnFIirPKr8Aiiu1XVhIe/oJAJvihE AeXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=eC03lVngMj0xGdd2YAtjG2n0Kao1tIyXKVSyjeODo04=; b=XEOYkvACOmkzV77dRnUObBYXIUPvmkw2yy5YOFqAfFukImrPEPtHdxiDsRzF7eXpxR JGjXdMqDAC6u7VA8MAabP1gFvoQRE4p4BDgkm5N8knROjKw+hUjWdE9Um4rN+O241ajQ uej5G1/6RoaODA9RskD3mq/WLq+zFTNVYkkSCqoS31l0aZJqKXU7Ucs/qACPSUNtPfaq N/qzJTWPG/zBfVMcEgX492EX1KtwrQDB2uCGnbUrXievYfQVHLDx6b4j+WQTrKxvEJE5 fgeLG3cHuajujcJDiMe+D3PEj9kaaepLsJy378vvhAYOz5EAsrMQ/J7uKfCkEGz8o8rt UCYg== X-Gm-Message-State: AOAM533FdMT2WZ1npba7FWxtuSOcJbfhuXzf/u63cPRYuhUFEOTYQIWl TnRcQfubAcZPuHbrl05CJQ2mxUYXdJM= X-Google-Smtp-Source: ABdhPJzGTCJNA+rjZ3J3oAgbA9eMg9soiGKAGld3jof2lBqJIrIYhSkWW+LnE3Rq72b1Ky6JAnG4Pw== X-Received: by 2002:a17:902:ef45:b0:155:cede:5a9d with SMTP id e5-20020a170902ef4500b00155cede5a9dmr21461442plx.93.1654473165806; Sun, 05 Jun 2022 16:52:45 -0700 (PDT) Received: from dingbat (2001-44b8-31f2-bb00-3884-712f-51c3-8d43.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:3884:712f:51c3:8d43]) by smtp.gmail.com with ESMTPSA id 187-20020a6204c4000000b0051bc721b838sm7490596pfe.188.2022.06.05.16.52.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 16:52:45 -0700 (PDT) References: <87mtf3tui1.fsf@localhost> <87pmjyco0x.fsf@localhost> <87fskrobiw.fsf@localhost> <87a6ay1enh.fsf@localhost> <87zgisvuu5.fsf@localhost> User-agent: mu4e 1.7.26; emacs 28.1.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: Proposal: 'executable' org-capture-templaes Date: Mon, 06 Jun 2022 09:05:29 +1000 In-reply-to: Message-ID: <87sfoi1xde.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1030.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1654473203; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=eC03lVngMj0xGdd2YAtjG2n0Kao1tIyXKVSyjeODo04=; b=kcNCFOqnEwh4+u7hPgWcjJeRbXvh7xvYlidnMJ4FvTBFXP9gz239curzz3raQ6tFYbYFRl Y4CNMx/tZ++0cgfVvVoqG+20DW3lt/k3PMjfQBvEF4EKG0Qnw2bFuY0jOSzcjueMniljEN /MKp98DtKWn4N3M+KGaiglmGZs8LmxmA07TBJu3YNA8yelebwuPnFe/lTEGvMxvPT5bFef zaJZouaj4VMXnWlQem2BF1+eSsGEFWyp7EtvM7sAwN5OUTAvMkjMKkw6RoBrlH+RPChUI9 yFlQea4ikwnmkCp3grmGuMgRvJ/0xmxrSFqrQf9dA3ulmFd1NDzFhCj09iprRQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654473203; a=rsa-sha256; cv=none; b=uAyITqB2gx+pVCPVBGXU4z5+BaeNElLgMN8Teg9aG/rI0j18AFZGFDlULQF+cnJHpuSpxp MFYtXd5yWROhfDgMxl0tmIttPC/inGChKpND2eFR8wfzWi8T/n4wURlgv09yNAzQkQky3t 7jk6qcEd7SUl+70GdrJbIHuYb7NgJj44lzzU2DGULc47Ts3AiO/KNvyAvA6DMjN/7Jl5S4 VbdMGmgoJ/jsUX3GwwZMVR+639P0npP1AiDf6NgtgyDZFr++lW266B8+TDhTn0kLTLlW7W +YnH5WhEBAh2dpqbPRgU6FZFmaAMnpQ5lTUyUzKgC0vRWESYEA2NEpXKu9r7Mw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=b7kWOwH0; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Spam-Score: -4.01 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=b7kWOwH0; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Queue-Id: 7FB1522934 X-Spam-Score: -4.01 X-Migadu-Scanner: scn0.migadu.com X-TUID: TLe7JDwxkSht Arthur Miller writes: > Ihor Radchenko writes: > >> Arthur Miller writes: >> >>> However before I continue, I am thinking of ditching the 'read-key' completely >>> and switching to "standard" Emacs way of implementing interactivity via mode and >>> mode-map. I am currently playing with such implementation, which to me appears >>> both simpler (code reduction) and more flexible, but it does change the mental >>> model of how clients of org-mks are used, for example org-capture. >>> >>> I don't think it should be a deal-breaker, but that is my personal opinion, so I >>> would like to hear if that change would be acceptable or not? >> >> Could you provide a bit more details? How exactly will the usage differ >> from read-key? > > I just wrote a much more detailed descrpition of what I have done so far, and > some dificulties I have to solve before I continue, and some discussion of how > it might work in answer to Mikulins question and concerns. > > Short here: it will be ordinary text buffer, read only of course, with its own > major mode derived from special mode and buffer local key maps, instead of major > mode global maps, so user can just press a key in the buffer itself instead of > being prompted. > > Single task workflow, I believe, can be guaranteed by allowing > only one menu buffer per application, for example one org-capture menu at a > time, but multiple applications could work since they will have different named > buffers. > > This is a suggestions. I really dislike the read-key implementation of org-mks, > I don't think it is very easy to hack it in order to extend it, but I don't know > if it is possible to block Emacs when using ordinary key map mechanism. If > someone knows how to do it, I am all ears :). > > Hope it explains a bit. > > Thanks for the help! I'm not sure I really understand the exact goal you have here. To me, it feels like yet another input selection/menu/completion scheme and I'm not clear on how it will be an improvement or why do something 'different' in org compared to other modes etc. However, I also don't have any problems using the existing capture interface, so perhaps I just don't have the number or complexity of capture choices to expose issues/limitations wiht the existing approach. The main 'concern' (well, not really a concern, but ....) I have is that Emacs already has far too many solutions along this line, which makes it harder to get a consistent UI. I also feel this is one of those areas which appears to be really easy to 'fix' or improve, but also has a lot of hidden complexity which only becomes evident once lots of different users and workflows try to use it. One very big warning I would like to raise to ensure it is taken into consideration is accessibility. This can have two significant effects with respect to the types of things you are doing - 1. I am a vision impaired user. While considered legally to be blind, I do have some very limited vision (less than 5%). I use very large fonts. (assume a 25 x 80 screen). 2. I use Emacspeak to provide text-to-speech support. Emacspeak works primarily by adding 'advice' to key functions which take the core bit of text and send it to a text-to-speech synthesizer to generate spoken output. One thing which is important with any 'menu' or selection solution is that we can move through the choices so that they get spoken again i.e. review the choices. Choice review is very important, especially when there are lots of choices or when there are nested choices. Some solutions are better at this than others. Sometimes, this is only possible by selecting the 'prompt' window and using normal emacs navigation keys to move around and get the options spoken - clunky, but usable. Others solutions are structured such that when you move to a new option, it is spoken and you can just move up/down or in/out of selections to hear them spoken. The key point here is that in some situations, you may need to allow the user to switch windows and then switch back (i.e. switch to the window displaying the choices, move around to listen to them, switch back to the minibuffer and enter the choice or provide key bindings which will allow the 'choices' buffer to be scrolled up/down and have the contents spoken without leaving the minibuffer etc. The key point is that for blind and VI users, the ability to 'scan' the choices is more limited. Often you will need to go down one selection tree, come back up and go down a different branch. You cannot just glance at the screen and get an overview which helps to give context. As an example, the org export 'menu' is not good for most blind/VI users. The choices quickly exceed the number you can fit on a 25.80 screen and it is difficult to review choices. One reason I like it when modes stick to core or built-in modes/packages to provide UI elements is that typically, they will already have emacspeak support. When a mode does something fundamentally different, it requires someone to implement the advice to make it work with Emacspeak. Most 'popular' approaches have already got support i.e. helm, ivy, company, transient mode, vertico, embark, ido, etc. Some modes are easier to support than others. It can be difficult for someone unfamiliar with accessibility requirements to know how to ensure these are met and met adequately. Unfortunately, there is no simple answer. However, when ti comes to emacs, one approach which might help is to see if you can make your implementation echo choices to the message buffer and/or echo area when the user moves between options or requests a review of available options. While not perfect, in general, if you can do this then it won't be too difficult to add Emacspeak support.