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 iDpDE2k6VF/bcQAA0tVLHw (envelope-from ) for ; Sun, 06 Sep 2020 01:24:57 +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 CIZED2k6VF9+AwAA1q6Kng (envelope-from ) for ; Sun, 06 Sep 2020 01:24:57 +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 A8266940215 for ; Sun, 6 Sep 2020 01:24:56 +0000 (UTC) Received: from localhost ([::1]:41740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kEjQM-0002kJ-VZ for larch@yhetil.org; Sat, 05 Sep 2020 21:24:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kEjPw-0002kC-PP for emacs-orgmode@gnu.org; Sat, 05 Sep 2020 21:24:28 -0400 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]:53995) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kEjPu-0006Zr-9t for emacs-orgmode@gnu.org; Sat, 05 Sep 2020 21:24:28 -0400 Received: by mail-pj1-x102f.google.com with SMTP id t7so1785299pjd.3 for ; Sat, 05 Sep 2020 18:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=a2qrHAOV4UnnYE7IfF9vWFC7QFL+rpmX2eW74XozQnY=; b=NgG51KP3Dom23RBWkKioURIVA+lOKlm54gCl4psIPldlKnay6byzIB3ZCVvOodcrGu DsHMcKDG4EIxzgLQDPbdGEG13NYuxMwZybv47cAHALqvsbjDgQjskyZoLk5Yh5En5lYe HiyCdhp7J0bxD/rzQv1NNdMbV1WWX19aich9UdSZZ1Mjkv3kwN5/oSY85leprbYpD9rL QOif23eKVs9AkwC6Fvy66bnSl8awGU3GFMRhYfyIRcEeeOuvX2x//HXNN4QDCzuPI98A XgExoDbtjsuTVUCMyHE3w2DFUHZs9+wPyW3CH7BcdymER9U/Mn5vW+qcDk/qpH/YDiIL clfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=a2qrHAOV4UnnYE7IfF9vWFC7QFL+rpmX2eW74XozQnY=; b=rxq5oIOlKuJ9tAmcQpJAFZPx6OLIAThB2DesVgMcR+SFHByeqMmd2jUO18DQZJA/P0 ZZK/7gXovwDwg6xnT+Ek3isdHJet+nvcwLXPsO/mQdztM2Fe1Ns9myXxO+WeF9Cj3DAv O24IwxiUGyhsbY4+kerWx3WXYB7/zASP07G44ufMpBud+zE0GZwD2BZplk6e5BTK0KvR cohiHfcNyA53l1i72pMJQQDDxseGXppo1s2nF0zXA3ewJH0oKve3FFJyTqCxYWACd3JI 39KIV0Y4EhF+sEo1y+pjXLeWQxARjY8jWh1XXGCY341dIoElo7hzo7yS5tz4nkJIRLxk zP/w== X-Gm-Message-State: AOAM531iNSJXAty3F1jYgUcTS4WnQjdGCXl08+1U/A/MgF7rnDQTGxpy eztAnjHLNZTwtkp844AVGs4= X-Google-Smtp-Source: ABdhPJzSk3BRiW5UJqiLtlKuvcQ58xcA7ZuFwsQjLhUyDDPUp5tn4YbxzHkkI60TdC+TElniiOtJsQ== X-Received: by 2002:a17:90b:793:: with SMTP id l19mr5441032pjz.154.1599355464313; Sat, 05 Sep 2020 18:24:24 -0700 (PDT) Received: from localhost ([167.88.61.176]) by smtp.gmail.com with ESMTPSA id z22sm13475639pjq.2.2020.09.05.18.24.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Sep 2020 18:24:23 -0700 (PDT) From: Ihor Radchenko To: Allen Li Subject: Re: [feature request] A new cookie type [!] showing the last note taken In-Reply-To: References: <87zh6eymxs.fsf@localhost> Date: Sun, 06 Sep 2020 09:23:24 +0800 Message-ID: <87pn6zzoj7.fsf@localhost> 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::102f; envelope-from=yantar92@gmail.com; helo=mail-pj1-x102f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, 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: Org Mode List Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=NgG51KP3; 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-Spam-Score: -1.21 X-TUID: L3RodPpXT0SO > Everyone has their own workflows, but I think the way you are approaching > this problem is "wrong".=20 I think I need to elaborate on the use-cases more then. I am well aware about the concept of NEXT actions, GTD, projects, and using categories to bring task context in agenda. However, the problem I am trying to solve is more subtle. Sometimes, subdividing a task into NEXT sub-tasks is simply overkill leading to redundancy. Consider the following example of reading a book, when the task of reading is also part of bigger project: * PROJECT Combine GTD approach with Zettelkasten in org-mode :PROPERTIES: :CATEGORY: ZettelOrg :END: Zettelkasten method looks promising to combine many pieces of information from various research papers together. However, most of papers I read are initially captured as TODO - within framework of GTD. The original GTD approach recommends separating reference materials and the todo-lists. I need to explore the reasons why it is so in more details and decide if I need to separate paper notes from their "read" tasks and how to manage the separation if I decide to do it. ** Literature review *** NEXT re-read Getting Things Done by David Allen [[attachment:GTD.pdf]] ---------------------------- That's indeed a fairly big task - reading the whole book. Splitting the task sounds reasonable: *** NEXT re-read Getting Things Done by David Allen [[attachment:GTD.pdf]] **** NEXT Read Chapter 1 **** TODO Read Chapter 2 **** TODO Read Chapter 3 <...> ---------------------------- There is a problem with this approach though - individual tasks will appear without context in agenda: * today NEXT Read Chapter 1 As you mentioned, we can bring some context to the task simply by showing category: * today ZettelOrg: NEXT Read Chapter 1 You can see the problem - we already have high-level category for the project. Of course, we can define separate category just for the "re-read" task. But then, we will lose the information about higher-level project. If you look at the project description I put in the example, you can see that the higher-level context is, in fact, important - I do not intend to read the GTD book in generic way, but I intend to explore the possible combination of Zettelkasten and GTD. This context is general for the whole project and will apply to other books/articles that may appear in the project "to-read" list. There is also another approach to bring context to the individual "Read Chapter" tasks - we can mention the book title in all of them: *** NEXT re-read Getting Things Done by David Allen [[attachment:GTD.pdf]] **** NEXT Read Chapter 1. Getting Things Done by David Allen **** TODO Read Chapter 2. Getting Things Done by David Allen **** TODO Read Chapter 3. Getting Things Done by David Allen <...> This works fine, but it is redundant - we have to carry over the first headline to every sub-task. So, I suggest to add a short note to the main task instead: *** NEXT chapter 1 | re-read Getting Things Done by David Allen [[attachment:GTD.pdf]] This is much shorter and does not require creating a bunch of similar tasks. I just need to look at the main task in the morning and decide what I am going to do with it that day (like read first chapter). One can argue that the fact that I want to read a chapter of the book is so trivial that there is no need to bother writing it down. However, it actually helps tremendously. Look at the following two tasks: * today NEXT re-read Getting Things Done by David Allen * today NEXT chapter 1 | re-read Getting Things Done by David Allen According to my experience using GTD + agenda, I tend to feel a little depressed by looking at the first task - "OMG, I need to read the whole book! Better go ahead and clock-in an easier task - I can finish it quickly." Thinking that I can just read a single chapter is not something coming to my mind immediately - I need extra effort to realise it. And things become worse when we have a task, which is less trivial than reading a book (but also requires simple repetitive [but less obvious] actions).=20 Finally, note that I have an attachment link to the book in the task description:=20 *** NEXT re-read Getting Things Done by David Allen [[attachment:GTD.pdf]] This is handy, because I can open this link directly from agenda view via C-c C-o. If I had to create individual tasks for each chapter, I would need to carry over the link as well - another bit of redundancy. > Under the GTD methodology, there is the concept > of a project (some higher goal to be achieved) and next actions (the > concrete tasks to do next to achieve the project). You would only track > the next action in your regular toto list. In Org mode, this would look > like: > > * PROJECT make babel support org file links in header args (:file or :dir) > ** TODO Finish the text prop org-mode > > My anecdotal impression is that many people using Org do this (see > https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a > "last note taken embedded in headline" feature. As a practical matter, I > would find it inconvenient to have both the "last note take"/"next action" > and the overall project headline appear in the agenta view because it mak= es > the text too wide. If I need to associate the next action with the overa= ll > project, I take advantage of the CATEGORY property: > > * PROJECT make babel support org file links in header args (:file or :dir) > :PROPERTIES: > :CATEGORY: BabelLinks > :END: > ** TODO Finish the text prop org-mode > > Which would show in the agenda as: > > BabelLinks: TODO Finish the text prop org-mode I hope that the above example gave enough context on why splitting a task into sub-tasks is not always a good idea, even if you follow GTD. However, what I described does not strictly require the functionality I am requesting in this thread - we can as well directly modify the headline. Another situation when showing task-local context can be handy is when the task is blocked by something (I am talking about concept of WAIT tasks in GTD). In my example below, HOLD refers to task that I plan to do as soon as it is not blocked by something else - equivalent of WAIT tasks in GTD: ** HOLD Finish the text prop org-mode | make babel support org file links In this example, note "Finish the text prop org-mode" refers to another project, which I would like to focus on before starting the task. Working on that org file links is "on hold" for now. Seeing why the task is "on hold" is extremely useful when I do my weekly review (as recommended by GTD). I can look at it and decide if the reason the task is "on hold" is still valid or I can go ahead and mark it NEXT. One may argue that my example can be covered by task dependencies (via org-edna). However, that is too restrictive in general case. Even though initial reason why I put a task "on hold" is other higher-priority task, I may, for example, be on vacation another week and thus have a time to work on both tasks simultaneously instead of a need to focus on one thing only. So, seeing the reason of putting "on hold" during weekly review is important for me. --------------- I hope the above examples explain why I suggested to implement the new cookie type - it can be used in both the described situations. > I have only been partially paying attention to this discussion thread, but > this sounds like both a feature with limited appeal and significant > complexity to implement, so I would suggest implementing it yourself for > your own use case, and then bringing it to the mailing list to share. On= ce > you have a dozen people using it, it will likely have developed into a > mature enough form to include in Org mode. I actually have working code showing the last note in agenda view. As I described, I believe that such functionality can be useful. However, my own implementation is limited to agenda (because I mostly use agenda). If one prefers to browse org buffers directly, they will miss the feature. Headline cookies should be more universal and also allow to show the last note selectively, only in the headlines containing the cookie. The complexity only comes from the fact that we don't have formal definition of "note". > As a practical matter, I > would find it inconvenient to have both the "last note take"/"next action" > and the overall project headline appear in the agenta view because it mak= es > the text too wide. That's one of the reasons I propose to implement it as a cookie type. You do not have to put [!] in your headline if do not want to. Best, Ihor Allen Li writes: > On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko wrote: > >> >> Over the years of using Org I often have a need to add a short note >> about how to proceed with some task: >> >> ***** REVIEW check again, subscribe | sindresorhus/awesome: =F0=9F=98=8E= Awesome >> lists about all kinds of interesting topics :BOOKMARK: >> :PROPERTIES: >> :CREATED: [2020-03-15 Sun 18:59] >> :Source: https://github.com/sindresorhus/awesome >> :END: >> :LOGBOOK: >> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =3D> 1:28 >> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =3D> 0:15 >> - Refiled on [2020-03-16 Mon 23:59] >> :END: >> >> In the above example, the short note is "check again, subscribe". >> The note is not fixed, but changes as I progress with completing the >> task. >> > > Everyone has their own workflows, but I think the way you are approaching > this problem is "wrong". Under the GTD methodology, there is the concept > of a project (some higher goal to be achieved) and next actions (the > concrete tasks to do next to achieve the project). You would only track > the next action in your regular toto list. In Org mode, this would look > like: > > * PROJECT make babel support org file links in header args (:file or :dir) > ** TODO Finish the text prop org-mode > > My anecdotal impression is that many people using Org do this (see > https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a > "last note taken embedded in headline" feature. As a practical matter, I > would find it inconvenient to have both the "last note take"/"next action" > and the overall project headline appear in the agenta view because it mak= es > the text too wide. If I need to associate the next action with the overa= ll > project, I take advantage of the CATEGORY property: > > * PROJECT make babel support org file links in header args (:file or :dir) > :PROPERTIES: > :CATEGORY: BabelLinks > :END: > ** TODO Finish the text prop org-mode > > Which would show in the agenda as: > > BabelLinks: TODO Finish the text prop org-mode > > I have only been partially paying attention to this discussion thread, but > this sounds like both a feature with limited appeal and significant > complexity to implement, so I would suggest implementing it yourself for > your own use case, and then bringing it to the mailing list to share. On= ce > you have a dozen people using it, it will likely have developed into a > mature enough form to include in Org mode. > > Just my 2 cents. > > >> This is even more useful for delegated or HOLD tasks where I often need >> to add a short note why the task is delegated or put on hold: >> >> ** HOLD Finish the text prop org-mode | make babel support org file links >> in header args (:file or :dir) >> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri] >> CuNbARBshearstrength]] :HOLD: >> :PROPERTIES: >> :CREATED: [2020-07-20 Mon 16:53] >> :SHOWFROMDATE: 2020-08-15 >> :END: >> :LOGBOOK: >> - State "HOLD" from "NEXT" [2020-08-10 Mon 15:16] \\ >> Finish the text prop org-mode >> - Refiled on [2020-07-20 Mon 17:15] >> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =3D> 0:01 >> :END: >> >> Seeing this note directly in the headline without a need to dig into the >> task body / LOGBOOK drawer is really handy. >> >> In this last example, I had to duplicate the note taken using built-in >> note mechanism into headline, which was inconvenient. It would be handy >> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to >> the headline to show the last note taken for this task. Then, I could >> easily see the reason why the task is blocked or what I am supposed to >> do with the task right in agenda view or in the folded headline. >> Something like the following >> >> ** HOLD [!] make babel support org... :HOLD: >> :LOGBOOK: >> - State "HOLD" from "NEXT" [2020-08-10 Mon 15:16] \\ >> Finish the text prop org-mode >> - Refiled on [2020-07-20 Mon 17:15] >> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =3D> 0:01 >> :END: >> >> The cookie would be replaced by the last note text, according to >> user-defined format (say, "[%s] |"): >> >> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOL= D: >> :LOGBOOK: >> - State "HOLD" from "NEXT" [2020-08-10 Mon 15:16] \\ >> Finish the text prop org-mode >> - Refiled on [2020-07-20 Mon 17:15] >> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =3D> 0:01 >> :END: >> >> What do you think? >> >> Best, >> Ihor >> >>