From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id /txQIk5+1l8WdQAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 20:49:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id UA2UHU5+1l/jMQAA1q6Kng (envelope-from ) for ; Sun, 13 Dec 2020 20:49:18 +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 F10CD940437 for ; Sun, 13 Dec 2020 20:49:17 +0000 (UTC) Received: from localhost ([::1]:41404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koYIu-0002va-Pn for larch@yhetil.org; Sun, 13 Dec 2020 15:49:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koYIQ-0002vR-5o for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 15:48:46 -0500 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]:55743) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koYIO-0006hM-9y for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 15:48:45 -0500 Received: by mail-pj1-x102c.google.com with SMTP id lb18so5100238pjb.5 for ; Sun, 13 Dec 2020 12:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=obLcofU5FBtVEdNO/fcuyUDHnJEZPX/gOReuX1PQAFI=; b=CtVX0VzKX5wlZdiK3WNatUXdpk46JCLp92M3wTKVyhlLxCst94M6BNk/hRsq8ZSxmR fsvhHLD4qJFRzhauQdtS88EoVHo50ps2TPsif+CvPV4lLl0ZVrNx4tBhE0JRhAVXXtCj Tk4M8FZg3NuD1hu61Xc7QRe6DQaESN3v3ctvR0pkEfQIpQZt/9qzpWFtPvXyafmPsm9t 8SELmH5e3VctCY9+2awIwzZaHXzDKH9apb9mqmUqKqh14ovYswPqX+6K82xy1lXpK64E Ud0iHMKSykfDD5YTKOehklh6bVV2GBi5BhFZULzHO/nIJFDU/GZuFVzui2zZ3rYVAiuD s0fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=obLcofU5FBtVEdNO/fcuyUDHnJEZPX/gOReuX1PQAFI=; b=Vr8H1WWckrw9HuNbfpr6ZGJkoGe/Lk/K9Hkbenmb5LZO3yuw3fP0S0KlpGC37FmBpO 1XrdB6q7ZcSri/XNCMD6PCPqaVvW7X+2Tk0Nl/k+gpJG1T7AFaXSTNrA07gGFnaCK01C 6ZalZ68fKC/zPam92APjqNnBolms8bebL/6imzh6IamaXkLCSGqcS2H6BBQ2WM88tQSi Ez7NuMY4U+hspRwCpoP1jDrtIrvdh/R4LftGNt8Fm+GHHD6MsbV1H1eJgVvtlBvFdvuq XUZxqOtJ0qzShNyQMleA+x5o7Nbtu4UKApDgbBvA9O/bFPbZUcra4KLG5/sRBtixOyud GL9w== X-Gm-Message-State: AOAM532HwP3fpaoy02yNodDkDf1CYJMZcEypXJnX8Ecrpa9/9OdtBUwa MRWc/k6EfrKlAihqTHPsKM0Bri8bqwifVg== X-Google-Smtp-Source: ABdhPJwWv1bECSqoiW3XkLsJyTzZO6qVSvsJaf9xMXB2ty//UyKt23U7mnYuLV5VTVnKa9JSB7ElCQ== X-Received: by 2002:a17:90b:1b05:: with SMTP id nu5mr22036259pjb.101.1607892522572; Sun, 13 Dec 2020 12:48:42 -0800 (PST) Received: from tim-desktop (106-69-107-167.dyn.iinet.net.au. [106.69.107.167]) by smtp.gmail.com with ESMTPSA id u15sm16864103pju.7.2020.12.13.12.48.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Dec 2020 12:48:41 -0800 (PST) References: <87y2i2ttl7.fsf@gmail.com> User-agent: mu4e 1.5.7; emacs 27.1.50 From: Tim Cross To: Jean Louis Subject: Re: Org Capture Menu cannot be fully viewed Date: Mon, 14 Dec 2020 07:06:38 +1100 In-reply-to: Message-ID: <87wnxlig9m.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102c; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102c.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 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: 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.50 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=CtVX0VzK; dmarc=pass (policy=none) header.from=gmail.com; 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: F10CD940437 X-Spam-Score: -1.50 X-Migadu-Scanner: scn1.migadu.com X-TUID: CIDaVrCvptwx Jean Louis writes: > * Tim Cross [2020-12-13 03:54]: >> >> pietru@caramail.com writes: >> >> > Dear All, >> > >> > When making a relatively long Org Capture Menu for Archaeological Field Management, >> > the relevant capture window cannot be scrolled down. This becomes particularly >> > problematic with small field laptops. >> > >> >> I'm assuming you mean the window which pops up where you select the >> capture template to use. >> >> Just wondering if perhaps what we really need to do is provide some sort >> of support for using Emacs completion facilities to select >> templates? > > That is very right. I have 1140+ "Sets" which are equivalent to > capture templates. Imagine if I would be "defining it" by using Emacs > custom, forget it, I would rather break my computer down and switch to > paper. I have no clue as to why your dragging Emacs custom into this discussion. The issue being discussed here is making it easier to select from a larger list of capture templates, not defining custom templates. Your ability to drag a thread off topic is quite incredible and somewhat frustrating. >> realise this is challenging because of the huge wealth of completion >> frameworks available in Emacs, but perhaps adding support for something >> like fido-mode would be beneficial. > > Ah, no. Completions shall be available by standard. Emacs's standard > completion is just fine and any comletion package can extend it. That > is how it works. > I have not programmed any completion functionality in elisp, but as a user I certainly have had to configure it and it doesn't seem as easy to me as you imply. Would ge good to hear concrete suggestion on how Emacs completion could be used for capture template selection for users who use icomplete, ido or fido in a way where the user is not required to configure anything i.e. works out of the box just like the current capture selection window works. > Would org-capture functions be programmed in more functional style I > would already make the function. Maybe somebody else finds time to do > it. > > Or somebody can help me and tell how to use function, which function, > to file into specific Org file from org-templates, then I will make > function for completing-read as it is trivial. I am missing only > that. > Again, not what this thread was about. I also find this confusing as you write as though you are very informed and knowledgeable about Org capture and why it is not very good and yet don't seem to be aware of the most basic aspects of what is already available. For example, the target entry for a template can be a function that takes no arguments and returns the path to the location where you want the template to store its contents. Is that not what your after? >> I see a very similar problem with the export menu, but that is a >> more complex situation. > > Since quite some time I am using Org mode as display mode, not editing > mode. The compiled related information about person is displayed as > Org mode on the fly. I can have persons' images, SMS sent, notes, > tasks, transactions, emails received, including statistics all in one > Org file as display that is read-only. > Again, don't see the relevance to this thread. Also don't see anything terribly noteworthy here - with the exception of SMS and statistics, which is not relevant to my use case, I have pretty much the same, but in my case it is all editable and available and synced across all my devices (including tablet). I also have no dependencies on anything else, like external database, so if Emacs is not available, I can edit/update just using any text editor. > Similar derived mode could be used to display export menu and capture > menu. Instead they block user's interface, cursor cannot move to other > buffers, one has to interrupt those screens to do something > else. Incredibly user unfriendly. I disagree and thing your over stating the problem. For many people, the existing export screen works fine and provides a good interface. It doesn't work well for me because I have a lot of additional export targets and because I have to use a much larger than normal font. While your solution may work better for edge cases such as in my situation, it sounds like it would be less convenient for many other users as it would require a lot more keystrokes. It currently takes me 3 keystrokes to export to any of the available export target options in my system. I only need the export window for export targets I seldom use and don't remember exactly which keystrokes to enter. > Same for Capture menu, just same. Make the Org file, define keys on > the fly or simply hyperlinks and let users capture where they wish > without limit. > There currently is no restriction on where you can capture to. If you have complex requirements, you need to define a function which returns the path to where you want to store the data. That function can be as comp[ex or as simple as you want. -- Tim Cross