From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: Org mode rant Date: Sat, 1 May 2021 14:19:52 +0300 Message-ID: References: <874kfn292f.fsf@disroot.org> <87a6pfh1dj.fsf@zoho.eu> <87sg37giak.fsf@gnu.org> <87k0oilq85.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32338"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.6 (2021-03-06) Cc: help-gnu-emacs@gnu.org To: Bastien Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 01 13:24:12 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lcnjH-0008Jd-Rg for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 01 May 2021 13:24:11 +0200 Original-Received: from localhost ([::1]:46366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcnjG-0007ir-Qe for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 01 May 2021 07:24:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcnix-0007iZ-7O for help-gnu-emacs@gnu.org; Sat, 01 May 2021 07:23:51 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:34679) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcnit-0006dD-Q5; Sat, 01 May 2021 07:23:50 -0400 Original-Received: from localhost ([::ffff:154.231.162.22]) (AUTH: PLAIN securesender, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000046165.00000000608D3A40.0000450F; Sat, 01 May 2021 04:23:43 -0700 Mail-Followup-To: Bastien , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87k0oilq85.fsf@gnu.org> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:129274 Archived-At: * Bastien [2021-05-01 13:10]: > Jean Louis writes: > > >> Write less to-do items and more notes. Notes and "remember" lists are > >> always good. But do not blur the line between what you want to > >> remember and what you need to do3. Your to-do list should be a list of > >> things to do, not to remember. To-do lists should describe what you > >> must do, not what you want to do, which belongs on the "remember" list > >> until you really must do it. > > > > I wish I could understand it. > > My point here is this one: psychologically, I often find it difficult > to resist the temptation of noting something down *before* I know if > it is something I need to do or just something I need to remember to > check at some point, ending up with my to-do list presenting me with > to many things to do, some of them not really belonging here. When you note something in that example, do you put a tag TODO in Org? If so, why not just leave it without TODO... > Now I force myself to really ponder: "Do you really need to do it? > If not, do you want to remember it?" and I do this *before* I write > or capturing. It's interesting to exchange. Constant writing, noting, pondering may definitely lead to moments like described. If I may compare to my workflow I have not found myself thinking beforehand if I need to do something or to remember it (note it), as that decision has already been made, so I am writing something that has to be done or I am writing a note. Like "fetch money from Western Union office" -- it is harder to get into thinking should I just remember it, or should I do it -- as if I just remember it, money will not come in my hands. The distinction on what is ACTION (actionable) and what is NOT ACTION should be very clear in any note taking system. Refining those objects further with their types, classes, properties is great feature in any note taking system. Since I have switched from Org to database meta level outline where each node can be something else like Org, enriched text, image, video, etc. the decision comes first on the type. Do I want to follow up some person's development, like sales process, learning process? I press key for that. Do I want to assign task to somebody? There is special key. Do I want to create new task for me? There is key for that. This type of task in Org is just fine to be described as a heading, especially of there are various tasks related to each other, each actionable without mixture with notes. * Pay ticket to town * Fetch money from Western Union * Purchase bread, come back home If there are however notes around, that is where it becomes mixture that does not give clarity: * Pay ticket to town * Prices of tickets to town * List of Western Union offices * Bread types I like * Fetch money from Western Union * Purchase bread, come back home That is where nicely marked TODO items make a visual distinction: * TODO Pay ticket to town * Prices of tickets to town * List of Western Union offices * Bread types I like * TODO Fetch money from Western Union * TODO Purchase bread, come back home Then we get more confusion with priorities as the list could also look like this: * Prices of tickets to town * TODO [#B] Fetch money from Western Union * TODO [#C] Purchase bread, come back home * List of Western Union offices * Bread types I like * TODO [#A] Pay ticket to town Priorities in Org mode are attributes that may be used in queries, but I guess there is no sorting or ordering function yet. If those nodes are in the database, single key is moving one task up or down in the priorities order. Some things must come before other things. I recommend separating notes and actionable items: * Notes ** Prices of tickets to town ** List of Western Union offices ** Bread types I like * Tasks [0/3] [0%] ** TODO [#A] Pay ticket to town ** TODO [#B] Fetch money from Western Union ** TODO [#C] Purchase bread, come back home where by if tasks are written in the chronological order, priorities should also become redundant as the order itself designates priorities: * Tasks [0/3] [0%] ** TODO Pay ticket to town ** TODO Fetch money from Western Union ** TODO Purchase bread, come back home Another problem we have are relations, we do want to know where are Western Union offices, but the note can be far somewhere even in the other file. That makes things difficult. Then we have option to tag things that are related: * Notes ** Prices of tickets to town :transport: ** List of Western Union offices :western: ** Bread types I like :bread: * Tasks [0/3] [0%] ** TODO Pay ticket to town :transport: ** TODO Fetch money from Western Union :western: ** TODO Purchase bread, come back home :bread: Then one has to use Agenda function to find items by the tag, to find what is related. And if we have few more tags, it becomes really messy: * Notes related to Munich :notes:munich:germany:eu: ** Prices of tickets to town :transport:bus:tram:taxi: ** List of Western Union offices :western:money:family: ** Bread types I like :bread:cakes:birthday: * Tasks [0/3] [0%] :action: ** TODO Pay ticket to town :transport:bus: ** TODO Fetch money from Western Union :western:munich: ** TODO Purchase bread, come back home :bread:mother: And I have not yet mentioned property lists, which may visually disturb the user and make it all tiresome. When working with the database, specific items can simply be related to each other. Press key and see all related items. But nothing need to visually bother user. Number of tags can be unlimited, it is just a string separated with spaces. Tags could be 20 for a single item and as they are in the database, such tags need not be displayed visually on the side to the heading. If person then wants to find all money related items it becomes trivial, without searching for files, pressing R remove from Agenda, etc, what else. Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/