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 YJGUELQnVV9uaAAA0tVLHw (envelope-from ) for ; Sun, 06 Sep 2020 18:17:24 +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 GOd2DLQnVV81YQAAbx9fmQ (envelope-from ) for ; Sun, 06 Sep 2020 18:17:24 +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 D5A92940142 for ; Sun, 6 Sep 2020 18:17:23 +0000 (UTC) Received: from localhost ([::1]:33034 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kEzEA-0001aR-IF for larch@yhetil.org; Sun, 06 Sep 2020 14:17:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kEzDd-0001a4-5h for emacs-orgmode@gnu.org; Sun, 06 Sep 2020 14:16:49 -0400 Received: from ericabrahamsen.net ([52.70.2.18]:45748 helo=mail.ericabrahamsen.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kEzDb-0002dz-5P for emacs-orgmode@gnu.org; Sun, 06 Sep 2020 14:16:48 -0400 Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 2118A103014; Sun, 6 Sep 2020 18:16:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1599416205; bh=1SNVZdAHXuZk72uXjIe1gIyMkv6mHyTBUIQJadg4oo4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Spu8IIoFSC/wib/rKAhfFixqkCkIGOzJ37m3Bjyfs/REbq3JlNK0bzyraWLCeEVSD ZqzADGPp9S8JuCt2MHG0saL8nRDyEgcQqIf5BAW/I2Z+OnlughZ492JBeZOsZpfD2Q Z6xUywU7oT8rVQp7XORsAJLQEdKkSc6XDQvktxEI= From: Eric Abrahamsen To: Ihor Radchenko Subject: Re: [feature request] A new cookie type [!] showing the last note taken References: <87zh6eymxs.fsf@localhost> <87pn6zzoj7.fsf@localhost> Date: Sun, 06 Sep 2020 11:16:43 -0700 In-Reply-To: <87pn6zzoj7.fsf@localhost> (Ihor Radchenko's message of "Sun, 06 Sep 2020 09:23:24 +0800") Message-ID: <87363uu5x0.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/06 13:44:35 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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 , Allen Li Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=ericabrahamsen.net header.s=mail header.b=Spu8IIoF; dmarc=fail reason="SPF not aligned (relaxed)" header.from=ericabrahamsen.net (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-Spam-Score: 0.09 X-TUID: 1EpRYBPAMV4u Ihor Radchenko writes: >> Everyone has their own workflows, but I think the way you are approaching >> this problem is "wrong". > > 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: Chiming in briefly to say that I agree: many of my TODO use-cases simply don't make any sense broken up into sub-tasks. So much of what I do is email-based discussions -- about project proposals, textual edits, contract negotiations -- and as the discussion evolves the TODO bounces back and forth between NEXT and WAIT. This is also the fundamental approach of Gnorb. There's no useful way to break that evolving discussion into subtasks. All I want to know is, what am I WAITing on and how long have I been WAITing, and if the ball's in my court, what am I doing NEXT. I looked into implementing something like what Ihor is suggesting (except using a message-area echo), ran into some of the same difficulties (the semi-real status of notes), and then noticed that on an Agenda item shows the item in another window with its LOGBOOK expanded, meaning you can see the whole evolution of the TODO at a glance. And "o" hides it away again. That took most of the steam out of my plans, and I figured it was good enough. Re the formatting issue, maybe the easiest thing would simply be to say by fiat that only notes in a LOGBOOK drawer were eligible for special parsing. If you're sticking notes in the subtree body, they're just a list. Since no special note-handling facilities currently exist, no one would lose out on anything if we said any future such facilities would require the LOGBOOK. Eric