From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id cCvMFbMsXWcM8AAAe85BDQ:P1 (envelope-from ) for ; Sat, 14 Dec 2024 06:58:59 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id cCvMFbMsXWcM8AAAe85BDQ (envelope-from ) for ; Sat, 14 Dec 2024 07:58:59 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=B6cJqV3I; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734159539; a=rsa-sha256; cv=none; b=e82T5hR+hdUKZQ3bFSRzPLbW2CRIpwYSZGeEZA2whqFyt1OQGInxtxoItL+exUlrZ5yz/L p3F6Q91rOv4WtmPtr6tBl6sdS5Q1QjMCrf+WVUKgSjn9NddypnWFOMXJ+p8yoG/zPoeLfP X+wtlg6khcq98CajNMsB1sQ5gRm1Ubg+65y6RfYrR22bvJF+1vCVe7T37uC/Fd1hv4LSVw yFnFlF7sXeIYACq+HHhMnXEfDtoNUBBl3aJmRqBehQFKaQHVODfHateJfq3vXjbF/oeJrK G4EuirNYk/0AhW43yGqd2JpFLcHonNQOj7L3JPeVFbCZT3DmsPdnPLqIiWbf1Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=B6cJqV3I; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734159539; 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=SHJBP0xn4na1P84Ymc4zmkx9F3YELsb5t/0jRgDHx4w=; b=RNTbL5TcnpVncIeemiN6qgmZg43hcsxcJjtCDlSjn8KhXA/mUArOTQULSa2cneqy6FPweY oCfcOEXDcTtnI0ShYlPVVymTVxWa2ePr3z8nVK+VlhX7UvWRBDjYdAWpje05LJu6K8PuqS Z+wiRjqHc462j4Bv3aWbbch+Ygc4UkVZ+vKB64Bh+ksXaAvHQrvMGzSuHmFTu7UJyjBmMs VAUMvKsr6HFUB4FYqnZbkmmYQZufTIU/Ym/WrTtEtgXLq/jShfnbwSR5piOTuoadqhYY6p ZUvLrnQL9MdcTIHbiyNVD2bIot1s9k6WGWVdQbdf8j0xKQgH1v8C5uLmT4E2uA== 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 26790822F9 for ; Sat, 14 Dec 2024 07:58:59 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMM6Q-0007ni-Lh; Sat, 14 Dec 2024 01:58:14 -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 1tMGm6-0007Dg-NH; Fri, 13 Dec 2024 20:16:55 -0500 Received: from mail-qv1-xf2e.google.com ([2607:f8b0:4864:20::f2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tMGlw-0000Sd-IF; Fri, 13 Dec 2024 20:16:53 -0500 Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-6d8adbda583so28595176d6.0; Fri, 13 Dec 2024 17:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734139002; x=1734743802; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=SHJBP0xn4na1P84Ymc4zmkx9F3YELsb5t/0jRgDHx4w=; b=B6cJqV3Ilhf+cFbakfGToaCOzU7xBONkQbWjSi4DyxyPEmrAJVjZdsIbYnd4Lst3Nk 3euSXLzFgKmU2bBuaDAIb7XMSGTCvFKv7zgVTsW3ncgCAqKxQP0ZMx42vT1rwLwgW0BD z99ZwR6bZ4kpHIMoDKEQ2Zpsd2Gil9ocCjjSydVdig/BpNa1DwkZ7FTk17YJ6qyxqtcE P62RoulpF8vsHdatNHX4K6OqI52FtfEvbIrYAaMLO5Z+kkSuXrAdOKHieBrhJ4YScdg1 nxCBCZ6lf+k2+Mu9/ofdoJqUeLs1nGz8f6VzoEKW9MDHro5Ap2rp+SHWYBsxvKNMt0xZ s5ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734139002; x=1734743802; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SHJBP0xn4na1P84Ymc4zmkx9F3YELsb5t/0jRgDHx4w=; b=G52sz8sILcErebuecG92MDjV2r3dl65MgJf8uZ2gOnkk5PpP33tWMd3dNo7lgLdXwQ SGqQ6hLPPiDCltXgVu87v669F8oqAhc0LCmCkZZdrfc26yAfafnV97pVTfZHDokoHl2v Zq7gwV7hRXDdlCPBF1Kya6UcHXWCxbPUgHe04cEh1hTpReU9hCcRt2fdnXKsV8UJEcwN gThTXXkDQUyAOlQgNnXe+0E9Pg7dH2ED+pQQJJ9V3c6p79LJdaykUMNo7k4ciEBqBZNU +z3aoDh3yM7mOz8PwxV18pM7sPHgGz+Z5VMbfyyoE+yOyEkSusmxd846R+czI1IChGJi xKuQ== X-Forwarded-Encrypted: i=1; AJvYcCUYai3NddolYaETCnvvP/gdo+3RtB59Mr4/eU5Kofb5VgznhyvzKJuyBHIJfyRkdwKTYYKJ520gY21RfQ==@gnu.org X-Gm-Message-State: AOJu0Yxg07alswYgrUfVJWRDPUKEsHh4f43VHH2lc0ElGnHSIpm1DkV4 WyK2IHsXnllAunV8i8yYzWsAIegnytfO/nVosL/KucUrKDM6SwRq X-Gm-Gg: ASbGncv2heqNhA/f/w3MF8PYmK0cTVaB4/F6E2q7myl5jvHRaIKdVBuvWsN3rxU0cx6 L6XqbKMOQ0DRxzAU6dDcQ/O1kHh9XTadnikGVNWt879+YxdhpSX6DXMFj7Wyj50JjuBQgChTvr9 Peu1kFTSacw6ZvrvcIQw6cgjAwNd++/AGt/fVPfLjHuqsFiq+M1m9Vp2G/EfmcxHeeCGm4O7wdg 4wQq1Y/txjuXaeKsj0ANLt09thhXxUhSpXoGivMs+iDEpZ0e7/C44wMeZaq3Vc63Eo= X-Google-Smtp-Source: AGHT+IGux4pTeFf/ETxaZb4MviSsRA6JJo0WdSsxY7JMS/88yLlLaUeFv2r9stkOfGqgQbEbqX0zdg== X-Received: by 2002:ad4:5baa:0:b0:6d4:2029:ead1 with SMTP id 6a1803df08f44-6dc8caa9eedmr68044766d6.29.1734139000725; Fri, 13 Dec 2024 17:16:40 -0800 (PST) Received: from localhost ([2600:2b00:8e32:4200:7f1f:1dd0:692a:ca60]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dccd22f6f4sm3174096d6.21.2024.12.13.17.16.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Dec 2024 17:16:40 -0800 (PST) From: Panayotis Manganaris To: Ihor Radchenko , =?utf-8?Q?Tor-bj=C3=B6rn?= Claesson , emacs-devel@gnu.org Cc: emacs-orgmode@gnu.org, Philip Kaludercic , Omar =?utf-8?Q?Antol=C3=ADn?= Camarena , Jonas Bernoulli , Juri Linkov , karthikchikmagalur@gmail.com, Visuwesh , charles.choi@yummymelon.com, Justin Burkett Subject: Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) In-Reply-To: <87msgzh1dh.fsf@localhost> References: <8734m28l9a.fsf@gmail.com> <871pzte929.fsf@localhost> <87v7x548ri.fsf@gmail.com> <87y120daue.fsf@localhost> <874j4m9ep6.fsf@gmail.com> <87h68gfqj1.fsf@localhost> <87pln3f3cc.fsf@localhost> <87jzd9ojj0.fsf@localhost> <87cyj0ajm9.fsf@gmail.com> <87zfm4s50x.fsf@localhost> <87wmh8s358.fsf@localhost> <87y11nwp9z.fsf@gmail.com> <87v7wd9a2h.fsf@localhost> <878qt7fbki.fsf@gmail.com> <87o71jwdxz.fsf@localhost> <87wmg6edr0.fsf@gmail.com> <87msgzh1dh.fsf@localhost> Date: Fri, 13 Dec 2024 20:16:34 -0500 Message-ID: <87v7vn12tp.fsf@ASCALON.mail-host-address-is-not-set> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::f2e; envelope-from=panos.manganaris@gmail.com; helo=mail-qv1-xf2e.google.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 14 Dec 2024 01:58:06 -0500 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -5.40 X-Spam-Score: -5.40 X-Migadu-Queue-Id: 26790822F9 X-Migadu-Scanner: mx12.migadu.com X-TUID: ABIiWD6ZPPIk Hello. I'm very much an elisp amateur, but one of my main motives for learning has been to make use of emacs' many beautiful UI systems. Therefore, I'll provide my comments from a designer perspective and avoid implementation detail. Ihor Radchenko writes: > TL;DR: We are in the process of designing a more unified selection > interface for Org mode Thanks to Tor-bj=C3=B6rn, Jonas, Ihor, and everyone else for this work. I've learned much by following this thread. > a number of people raised concerns that transient may sometimes be an > overkill I agree with others that transient is overkill for most of the menus in org-mode. A counter argument, going by the patches exchanged here, might be that transient menus are a clean and scalable approach. I've not tried the in-dev transient follow processor, but I imagine it is similar to the old org-ref (John Kitchin) hydra menu. I used org-ref for years, and enjoyed how its menu united many features, including - a system analogous to org-cite follow processors for navigating to source= s/notes - a system akin to reftex-mode for org - a system for downloading new references and making new bibliography entri= es With this level of complexity, a transient menu seems like the modern weapon of choice for a similar feature set. Only, wait, I stopped using org-ref. Long story short, I concluded that treating org-mode like a nexus for these intertwined features was, at least, encouraging my bad habit of treating org-mode as an "everything app." I have since delegated the task of populating my personal library to a dedicated reference manager. I started using latex-mode and reftex to write papers, thus gaining more typesetting control and making version management much easier. I still use org to take notes, but now enjoy a much more stable and focused configuration. I tell this story as an (anecdotal) case study for how a powerful menu can be less productive in the long run. Org-ref's hydra menu is not to blame for my bad decisions but, at least in-part, I used it (and even extended it) because a greater man put it there. Scalable design is an invitation to scale. Perhaps the wise know better. Anyway, the simple tasks of navigating from a citation link to a copy of the original document, its URL, or an associated note is achievable with a completing-read (helm, counsel, vertico, etc.) interface. Transient is overkill. > This UI flow can be implemented using context menus [...] embark I like org's context menus, but I like embark better. I do think it would be very generous of org to delegate its own contextual actions to embark if so configured. I'll elaborate: As is, I like to run org-babel code block functions through embark, I only wish there were more of them to run. I find this to be far superior in every way to binding equivalent key chords for the mode. Also, for me, embark-bindings and embark-prefix-help-command have completely replaced which-key for discovering key bindings on-the-fly. > I am wondering if we can work out some universal API to plug the > described action->menu->selection model into the UI that user prefers. I support this idea in principle. > 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ..= .) ...) > PROPS is a plist defining extra properties like key-binding, display > string, maybe something else to be used in the future. I would focus on associating just enough metadata with functions to enable using them with embark. I really have no idea what the best way to do this is. This seems to be the biggest missing piece. Maybe in the short term we just crowd-source some embark configuration on WORG. Menus should of course be useful without embark. If the goal here is to deprecate many of org's ad-hoc interfaces, I think the natural default replacement for most is completing-read. I may be completely wrong. > 2. Menu interface to use (transient, context-menu, embark, which-key) It seems like Tor-bj=C3=B6rn and Ihor have already laid the groundwork for using transient in this way. So, I'll just say bravo. Regardless of my opinion on transient overuse, it looks like great work. On the other hand, e.g. if the org export dispatch menu isn't transient, it should be. Seems obvious to me. > 3. Layout settings for the specific interfaces. For example, transient > layout definition. It is important to avoid making more org-mode-specific UI abstractions. Whatever the solution, it is important that the UI implementations tapped to take over help share the maintenance burden. In this way, I reckon most interface customization can be done in hooks. > WDYT? Ideally org-mode uses established APIs rather than making another. Thanks for reading, and thanks for the chance to contribute.