From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 28/fDMqtaGLdMwAAbAwnHQ (envelope-from ) for ; Wed, 27 Apr 2022 04:43:22 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4GHuC8qtaGKVMQAA9RJhRA (envelope-from ) for ; Wed, 27 Apr 2022 04:43:22 +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 8CBF33FCA6 for ; Wed, 27 Apr 2022 04:43:21 +0200 (CEST) Received: from localhost ([::1]:58672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1njXeB-0002lK-Sf for larch@yhetil.org; Tue, 26 Apr 2022 22:43:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njXdj-0002kd-T6 for emacs-orgmode@gnu.org; Tue, 26 Apr 2022 22:42:51 -0400 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]:39709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1njXdh-0007t7-NN for emacs-orgmode@gnu.org; Tue, 26 Apr 2022 22:42:51 -0400 Received: by mail-pf1-x42c.google.com with SMTP id y38so433816pfa.6 for ; Tue, 26 Apr 2022 19:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=dmu+MhWf6ld4Xb3ye9KarVJXp+XmzWjIjEBFj0ZeKOs=; b=kZzcStgloY9y2TldgNC0fDyc0nZP02POaz9ak5P4H3bQ9rEsThZKGrDBqYko8BtyR8 8gTzO+NR+iXLg+b4Y//GUhhJUuMwxWZ/rDxpDeKn4G8UUiNfjcF4YjSD5L9OnNI3U9lD gg3DbeIzHnEyi3wArGhC9FxejsChY9CJ7KUgG7zb1pviGEdy0T7K5R7uWy0H6u2VcpNG lpx9nrTU48M9cwx+K/IzaKCsFazAUGEX7GuOQhJrSQoSrV7Y2vzLAUlfhtcp4cqdpgtz lupZBdMEJZXYZfTkn1/F8BVnTLmcokjzqK1zQOm0tUCM8piZ7QuzuGiLxiGPSieSl6cq JB1A== 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:cc:subject:date :in-reply-to:message-id:mime-version; bh=dmu+MhWf6ld4Xb3ye9KarVJXp+XmzWjIjEBFj0ZeKOs=; b=IzFZbGFUU4FbxZQYFbB4Rwa49GtWXLtxuFt1jxu1mI3cZ7NKQKno/Zv1VvhBEudN0A jTGSfHuxsjYXmhq59PUSFfGzF5eIKChU7cz25kDKpSdknSdqKktV6qGZ8ksN1bF5F4Qu EPjPIpwdi8jLXg6sFlH3pYATMOkywLVCU6w3xJsln5QQc0RLCP2/sdPjCIMBHfUFkSeY 5rH7HjyAl9EknaE0FRWRb0dLLUUDV014brTMAWf6VORjH3ElgljD8QHyLP+4gsfE4NmN 8QGV87ow3tAr+4jiqwqhGFfqKiZIKX4yBTi7tbPK2Vj+W6GdAajPvlkqjq8xcmu6Yn2V Ycsw== X-Gm-Message-State: AOAM530Klz08wxmw5QS4qfEqaDJKgUCA8jfS8ggungO2mOMbSGwT7jYr miJgXmsMIeNp68WKJLKLKyorXJQl6mw= X-Google-Smtp-Source: ABdhPJzMj/MefTxU+OF0SJNK1rp2vJxldM7GCWGqxP0kl+ufuGFbyQ/8K6ZLaWFgSCj+k1gGlDCpcg== X-Received: by 2002:a63:2bc4:0:b0:3ab:1d76:64db with SMTP id r187-20020a632bc4000000b003ab1d7664dbmr13483596pgr.508.1651027367335; Tue, 26 Apr 2022 19:42:47 -0700 (PDT) Received: from dingbat (220-235-29-41.dyn.iinet.net.au. [220.235.29.41]) by smtp.gmail.com with ESMTPSA id p10-20020a62b80a000000b0050d6ef96407sm892969pfe.95.2022.04.26.19.42.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Apr 2022 19:42:46 -0700 (PDT) References: <87a6chm5tz.fsf@posteo.net> User-agent: mu4e 1.7.13; emacs 28.1.50 From: Tim Cross To: Philip Kaludercic Subject: Re: Some feature requests/questions Date: Wed, 27 Apr 2022 10:52:09 +1000 In-reply-to: <87a6chm5tz.fsf@posteo.net> Message-ID: <875ymvqmam.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::42c; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42c.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: , 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-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=1651027401; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=dmu+MhWf6ld4Xb3ye9KarVJXp+XmzWjIjEBFj0ZeKOs=; b=nMctvAQW1Z14LvH9Fdp/7x0Ff3Jk3cJ6u+zG84SpndjPuh5X5fy2seCITRgPhgdXl+WOvU APfxg3KcpNshbTg6M1NnuY8MarWaSJrzYCRY+KKUHCEMCcJZYSE3FvoDyjXLeZK1Xe10zC ds2hABRFkgADS1mCTydtsgX1jq+KWxC7nQxeN60Z9ilWWmT0KaA9YDY36bUg6W4iXiftOv P1JWMcYY6FeBiZavyqYyy/bKmD8grP3XzpuqhJERtDIqa7ZBatqeUFSPGcFN8HMFSko6PM xOSXQqMYwhqFp9THyYsd2iEIefFrLTJQZJeDvli+/+LDNBNQEQ7cNII3ybIkKA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651027401; a=rsa-sha256; cv=none; b=Hlub1G6NyJBphRIYTK0uGa/nZz3gWBLHJGPmYI/kwhPlPdOR3N0gyd+chkRpLBZq69yJBd 6hGcLn+DxAKCMhDQPgNOSQYWlCCLgEYLdtbHuJqF2nXr533xIiZnjacfV8jaXyPInlmHxr 1fccA9dljAurqCLKYz3Ri+d7t2U7frZofKOdYTs5HrIqrA9+YT8UGOS6AaVUUt76lCv3+7 HR0hu8zsnwCjKHGbGDx28p3Grig8Iggc1Re7VJm1LcS4lOUjgBf+hS3rvfLizXAKS/SRa1 KrXPsBlARX9VxXoio5YnOMBbdUBsyRimpIIDRfUv/ZotTjrPlfz/GGXTYPaiiQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kZzcStgl; 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.00 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kZzcStgl; 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: 8CBF33FCA6 X-Spam-Score: -4.00 X-Migadu-Scanner: scn1.migadu.com X-TUID: LGdLAoAlWJdV Philip Kaludercic writes: > Hi, > > I was wondering if someone could help me out to solve these annoyances I > have been having with Org: > > 1. Most things I would like to clock are related to Emacs, but I often > forget to check my agenda first, clock in, then clock out. Is there > some way I can automatically manage clocking when I enter a > directory/kill the last buffer? Emacs has various hooks which are run when you enter/leave/kill buffers or start a mode etc. You could perhaps use them. However, this sort of automation may not be as useful as you think. You probably jump around into different buffers more than you realise and often, you will change buffers even when working on the same task. I also think how you clock your time is as important as just clocking time. It can be good to really think about why you want to clock time. What is the real goal. Do you really want to clock how long you spent in buffer X or is your aim to clock how long you spent working on task Y, which may have included multiple buffers, reading books, web pages, blogs, emails, phone conversations, etc. Even more critical is thinking about how you will use the data. If you clock at too fine grained a level, you will end up with hundreds, maybe thousands of clock entries. How will you use that data and what will that fine grained logging tell you which you didn't get at a higher more abstract logging level? > > 2. Capturing is configured by describing what keys should do via > `org-capture-templates'. Is there some way to use bookmark-like > strings and completing-read? > > 3. Related to the previous point, is there a way to configure capture > templates /in/ org files? That would make it easier to dynamically > add notes, without having to do so centrally, in my configuration > file. > Can you expand on this a bit. What you describe makes me wonder if your perhaps defining capture templates which are too specific and maybe not taking full advantage of capture template functionality. Typically, your capture templates are defined at a high enough abstraction level that you only need a very small number which are defined centrally and rarely need to be modified. This small number of templates work across projects, tasks etc. Sometimes, the way to enhance templates is not with the template definition itself, but rather with the use of other facilities, such as snippets, abbrev tables, macros, etc. I'm not a big fan of scattering org configuration information across multiple locations. Org is an evolving system with new functionality being added all the time. While a lot of effort is put into preserving backwards compatibility, it is often necessary for users to tweak their own configuration to maintain existing behaviour or turn on some new feature. When configurations are scattered across multiple files, this becomes harder to maintain. Having said that, the general answer to your question is "Yes, what you want could be done - this is emacs! However, at this point, there is no 'out of the box' functionality which would do what you want just by setting a variable or loading an additional file. Basically, answer is "Yes, but some assembly required". > 4. Limiting until when events may repeat, without having to duplicate > timestamps manually (or via `org-clone-subtree-with-time-shift'). > Better yet being able to do so for an entire subtree/file, and have > the property inherit itself. This one is a little more complicated. Working with date/time data is extremely complicated, particularly as many of the issues are somewhat subtle and easily overlooked until they come up to bite you. For the more complex scheduling requirements, some users like to rely on the capabilities of the Emacs diary sexps, which are supported by org, to a point. Again, I think most of the building blocks are there, but some assembly is required. > > All of these issues I have encountered by trying to use Org for the last > few years at University, managing courses, notes, assignment due dates, > appointments, etc. The friction that these issues cause often have me > become sloppy after a while, which defeats the entire purpose. > One of the great benefits of org mode is how well it can be configured to suit your workflow. This is a fundamental difference between other solutions which tyhpically require you to modify your workflow to fit with its view of how things should be done. However, this can also be a weakness. Sometimes, the way we develop a process 'naturally' is not always the best or most efficient. We may need to also adjust our workflows to enable more efficient exploitation of the tools at hand. I'm reminded of the old joke about NASA spending millions on developing a pen which would work in zero gravity while the Russians just decided to use a pencil. It would be a good idea to spend some time examining the frictions you encounter and thinking about alternative ways to eliminate them which does not depend on new fucntionality or writing new code. Look at how others use org and think about how you can adapt their ideas to meet your requirements. > I have little experience with the Org codebase, but would be interested > in helping to implement these features, in so far they don't just exist > and I haven't found out about them. It is not always easy to say whether a feature exists or not within org because in many cases, adding some feature can be almost trivial with just a few lines of elisp. There are also many add-on packages out there which extend and enhance org mode which I am not familiar with. I don't think any of your requested features are already there just waiting to be enabled, but org mode is sufficiently large and complex and my understanding of it is sufficiently limited that I could be overlooking or unaware of something. My suggestions would be - Analyse your org workflow pain points/friction and consider all the options, including modifying your workflow. Check out various blogs and posts from others on how they use various org features to broaden your outlook. However, also remember there is no automation for self discipline. Regardless of what you develop, you will need to apply the discipline to use the system - all you can do is make that a bit easier to do. - Select an option which you think can meet your needs, even if it isn't perfect. It just has to reduce the pain/friction. - Rinse and repeat until you have it down as far as you can get with just standard org and existing org add-on packages. - At this point, you should be in a better position with less friction/pain. Use the system for a few weeks and then reassess. - By the time you get here, you should have boiled things down to a small number of concrete issues you still need to resolve. Pick the one which will likely provide the most benefit but which you think would be achievable given current resources (time, skill level etc). - Have a go at implementing a solution. Get a basic version working and then bring it back here for comment/suggestions. Note that it is better to come back early rather than late. Rough proof of concept is better than completed polished work as it will be easier to incorporate suggestions and feedback. Don't become discouraged when someone points out that what you have done could have been done easier with the use of some package or a slight modification to your approach. This is the process and one reason to come back early with your code. The most important advice I can provide is "Don't over-engineer your solution". I think this is by far the most common mistake people make with org (it certainly was mine). Org is so powerful and so many of the features soeem so wonderful we have a tendency to develop this all singing and dancing org setup which does absolutely everything and can handle any situation. In reality, what we end up with is a configuraiton which is almost impossible to maintain and a complexity in our workflow which makes using it burdensome. Keep it simple, review it frequently and be prepared to throw out ideas, even those you think are good, if they don't actually make your life easier. Be pragmatic and ruthless. There is no point in collecting large amounts of capture data, lots of time clocking records, thousands of todo items if none of it is ever used or it doesn't make things better. Bottom line, if org isn't making things better, either it is the wrong tool or you are using it incorrectly. More often than not, it is the latter.