From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4IsRBQuM1l+pUQAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 21:47:55 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 6OLAAAuM1l92NgAAbx9fmQ (envelope-from ) for ; Sun, 13 Dec 2020 21:47:55 +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 6C5E09403A7 for ; Sun, 13 Dec 2020 21:47:54 +0000 (UTC) Received: from localhost ([::1]:56530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koZDd-0000Ac-CL for larch@yhetil.org; Sun, 13 Dec 2020 16:47:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koZ4I-0001GJ-Ob for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 16:38:16 -0500 Received: from mout.gmx.net ([212.227.15.15]:42235) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koZ4C-0003n0-L1 for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 16:38:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1607895451; bh=d6V12S/jMcQU2h+4lRTkyaA9QglbkinBtOLCoiWSipc=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=CywnuaVMw7qVPNnqdpoaaA0O8Y9QrC4fhsuZ60vYhAOSsQeb9LwpBHOA7CihqhmxW Zh7XGVnknmbT/gHqBLDnVgjbx6PyHZJkDl9sATYngKVsS4nilRbu+oCAoRRbP1VMVh g0qjwwQLo+7M6uon7fF8J4GMBG2xMkrr+/XoBcb0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [213.165.168.94] ([213.165.168.94]) by web-mail.gmx.net (3c-app-mailcom-bs09.server.lan [172.19.170.177]) (via HTTP); Sun, 13 Dec 2020 22:37:31 +0100 MIME-Version: 1.0 Message-ID: From: pietru@caramail.com To: Tim Cross Subject: Re: Org Capture Menu cannot be fully viewed Content-Type: text/plain; charset=UTF-8 Date: Sun, 13 Dec 2020 22:37:31 +0100 Importance: normal Sensitivity: Normal In-Reply-To: <87wnxlig9m.fsf@gmail.com> References: <87y2i2ttl7.fsf@gmail.com> <87wnxlig9m.fsf@gmail.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:+7b73plNSUyA3wkZvyPPVq0E9aGcnj5LNoQl5PvQ+hjxjaMF0mvXd5UVRnnWsPCqCmBzq 1uF6ItNIRq7aOW1Z6kj8zVdN6sHsAuJ9V99DjPtd0Xp4E+/xc2cVGZXzjukKKuS2U1sOSveuyLm5 yGe9uzyVw/vF/Ow+TkcEFruO59i/syys7y5YW/8fQXkBMRkd22jV/uFcFAG3AXWJUjs16hpnZ3NO nRBMErwe3ZhnESouOvoH0negLt4bZShjShvbMRrH+KIaiEYe+CX5+6gYZSa2IVb7h/EWqY/y5qZo Rc= X-UI-Out-Filterresults: notjunk:1;V03:K0:ApiHk5I8D5Q=:qQUuXgWatnbJXO013FVOTI HvdyO1gtjwj3zMcIXSgwAsVc9+4SL2EypRB4VmRXKF9+A9sy99weSPsGUbyXBoJd8j0AAkAxq dWQq/VHayr+hwjYqw5kFm+F1Erno05LhqB+sQpc5+GipORehRBijVxc9MI+OaAASFt+CJGHWT UwJoVqtJYcSi+lI2jRyfr/0H0L9Ysa7SXnedDnSsPCjmnlghjdW/JGn/cseiCk4x0yVJoqQX8 QSmDrCA6aBLMHIRhcNdTD+R7k6LbMO0DNM1I6bZAvXPH3jr2IlYXQ4tsnXtO/6sdLIb0ExG3Q UfYQ0s7Cr0zrQBj8o7gbLdqOc4wBbb9UNld25hQWEpO4Ghz/6ehIASV8Tf6icY22QGzeFubym +flN4RSXDAtj/B5LSec1LYNQGEdx3Rer17RU/WwRl+LHZxk54r16+Bxmp1oxf1YDFh7dSqViZ YMoJ+kNebCbPAcl0McvrT0Sr+IAG+DlDYZT4itX7o9SMkdERdqYDYeWXpdVj8rhgVJ1ybXg70 OjxtPDqMcohBN3V4yvezt7emhZYOgknx5gAlLyuYK2Di4sERIuzmEMZWciOabMf82BPQnGtYK DJhnytHD8bbLI= Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=212.227.15.15; envelope-from=pietru@caramail.com; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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, Jean Louis Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -0.70 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmx.net header.s=badeba3b8450 header.b=CywnuaVM; dmarc=fail reason="SPF not aligned (relaxed)" header.from=caramail.com (policy=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: 6C5E09403A7 X-Spam-Score: -0.70 X-Migadu-Scanner: scn1.migadu.com X-TUID: FLTgovqjapWz > Sent: Sunday, December 13, 2020 at 9:06 PM > From: "Tim Cross" > To: "Jean Louis" > Cc: emacs-orgmode@gnu.org > Subject: Re: Org Capture Menu cannot be fully viewed > > > 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 F= ield 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 s= ort > >> 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. My commentary has been to 1. Allow more entries by making the menu buffer similar to a normal buffe= r 2. Possibility to insert pre-defined text in the destination org file, th= at could be too verbose for people to write. Example: Side scan sonar frequency 3. As most sites would have already had work completed, go through all fi= elds and inserting then as nil can be time consuming. For instance, come u= p with a way to pre-select the ones you want displayed without having to cons= truct a new template. I feel you could be overthinking the whole setup. The ideas in org-capture and org mode are relatively straightforward. They simply got to a stage t= hat if they can be beefed up to allow for actual job duties in high paced envi= ronments where people do not have much time to think and organise as in an office. Yet the most important information gets best documented in the field, as f= ar as the work does. Lots of things can get messed up due to environmental con= ditions, another reason as to why pace varies a lot, and quite difficult to predict= how they get to manage their particular case. > >> realise this is challenging because of the huge wealth of completion > >> frameworks available in Emacs, but perhaps adding support for somethi= ng > >> 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 > >