From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id gMb7A3hW1l9CJgAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 17:59:20 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id UAFfO3dW1l+xVQAAB5/wlQ (envelope-from ) for ; Sun, 13 Dec 2020 17:59:19 +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 ED1B79402C8 for ; Sun, 13 Dec 2020 17:59:16 +0000 (UTC) Received: from localhost ([::1]:53768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koVeN-0007hC-65 for larch@yhetil.org; Sun, 13 Dec 2020 12:59:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVdK-0007N7-NX for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 12:58:10 -0500 Received: from mout.gmx.net ([212.227.17.21]:35581) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVdI-0005kk-4S for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 12:58:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1607882255; bh=1KCUdO4sx749zhmgHEJNaKhGnWBkMJEFLBCVecTc8qw=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=c+Wt5F0t2SXnx+o4fsf3pJDd6qPUl+ULtFDLjAo3h/Xxg9Ym+Qn2Q+f7Sgv+eEaW1 3do7M+hU6oPZkF0yTTZJ/dZCrLwHurL1aGhPfY0uSGC2lLG0wY58Z4nEwCnRLNXgUl ibaNz/jMtr4kpTXo3znqfV9QtS4I1OcxxktvlAyo= 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 18:57:34 +0100 MIME-Version: 1.0 Message-ID: From: Christopher Dimech To: Jean Louis Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options Content-Type: text/plain; charset=UTF-8 Date: Sun, 13 Dec 2020 18:57:34 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: <7330ab95c71d5d41d7fa6faffeaf300f@isnotmyreal.name> <20201211082501.GA18715@tuxteam.de> <871rfwctb2.fsf@localhost> <87y2i23vhr.fsf@localhost> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:jorRrm3ewNH0psP5DlyYuQOrKUNsmmBwDAcXGkKYDVkd+g6NGZ84eJshO3r3DT0OsdG7P QrLgq2F23+49vExyo6hTcBZMvVQLAC1Hxb51dx9+dMFgFBVxgmQzHSNmWTj2l7MMvllk0sphe0HF j9LYCMaGuhzJFYtsqkwdY2MnV41umTXWXG2gF0dUQeTZn8ZbYW55MJCRwv0kW/C6zDTIQX+OXJv0 MwwDBa/cIP2in6Wwi47yfH5BlcgxRSRHVCM5FUCiAB3wZStyfjaMJjp0tzhjI9TBxF9M0wGXRy4S kM= X-UI-Out-Filterresults: notjunk:1;V03:K0:jkG8usg5o9s=:PyGo6GtzNt/QIvXbkEG0hT v5xCMWDSOL99xfOoahhDxsCYOS5ZYRgg4Tt8dOXQojZYWYtuAHpQJQEO8OPxBlEvdRy3hQSaI QiD2NKDubEVGjfjz4j+cwM2OIdyd+Vh6oa1pT0/uIGdmCQXW3mDDseavy9AKiyYyNh5VLIJcI 3NCDNxOvhDS/8ZLPLjAtm21UoWVbDxUSYeqY4CkpXsFFlu038aA3YZ9uoL+lR4TX2FIBycCbo ZkhajbQmdQNw+5WQVgYL9ChzbDg7kLYAnhpvId2LilthOhbVTa3hyJnBWWTMUgdadw0wuu1vE TnNKeLj2YmhEdA//uhH5PAwDsab1E+2E3VCwQgIWolTgQzBUlCDDsA8jJMHjNn9RVf4YqK0nZ RstC/db0W1Jw2lVueG6Kth8pv83XBRHZU1WDw/0P8qt506AHsHUbAREaQBsgTHyINSXiLIfrm QRRKP0NSV7J/1o0NhLfSfZdDo6wgAwD3yPGjdAJ9YKfRKPmPpELF+OcxKfc8mOx+LCfr5ciyT Dokr615dZEJedv9BapT6Ws4MW5eixTvcVbilssQYNWE2UMCDdxF6fJwHis4T1yVODOOtYwzo+ SHcV0zWoP26q4= Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=212.227.17.21; envelope-from=dimech@gmx.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, Ihor Radchenko 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=c+Wt5F0t; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmx.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: ED1B79402C8 X-Spam-Score: -0.70 X-Migadu-Scanner: scn1.migadu.com X-TUID: UU9dBGTMAknw > Sent: Sunday, December 13, 2020 at 6:31 PM > From: "Jean Louis" > To: "Ihor Radchenko" > Cc: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwrit= ing user options > > * Ihor Radchenko [2020-12-13 12:25]: > > Jean Louis writes: > > > > > Org files I have always found useful for project and plan documents > > > preparation, in particular LaTeX and PDF export. As that way I get > > > better readability on screen and good printed document. > > > > > > None of such projects and plans need be marked with TODO as its natu= re > > > is that it is action plan, all items are actionable items. We print = a > > > project and execute it. People report on project steps by email. > > > > I disagree. Or rather it depends on workflow: > > In the process of writing a plan or document there is sometimes an urg= e > > to fix small details instead of finishing the first draft and moving t= o > > more fine-grained edits afterwards. One way around this urge is quickl= y > > inserting an inline todo item and continuing to write (another way is > > writing on paper, but one would need to spend extra time re-typing the > > hand writing later). > > Aha yes, in the context of finishing documents some items cannot be > completed and that is where TODO comes handy to know where to come > back to finish the document, while other items get completed in the > same time. But then again I never need an Org mode for that. I write > in LaTeX and plain TeX too, there are programs, so I always leave > there some tags in comments, usually also TODO. But is not Org mode > dependent. > > Practically, if I write "TODO" on the heading then something is very > wrong with all heading. I write a tag ;; TODO in Lisp code when I need > to improve specific line of code to something else in future. Anybody > can invent any kind of tags or even just note line numbers at begin or > end of file. Should not be Org related in general. > > If my text under heading is large I rather like to bookmark where to > come then to rely on TODO tag on the heading as it will not pinpoint > where exactly I have to continue. > > > If the document text has inline todo items, it could be useful to mark > > the top-level headline todo as well, simply to remind about any ideas > > postponed during the writing. Such headline cannot be switched to done > > if org enforced todo dependencies. > > Do you mean this: > > ** DONE Objective > CLOSED: [2020-12-13 Sun 20:00] > *** TODO [#B] Step to do 1 > *** TODO Step to do 2 > > when org-enforce-todo-dependencies is true I can still say DONE for > Objective above. I have mentioned it today already. Maybe it works on > your side, it does not work here. Do I do something wrong? I am on > development Emacs version and it does not enforce under emacs -Q > > Project planning shall always start backwards from known objective to > be achieved. Subordinate tasks should become superfluous or redundant > as soon as objective have been achieved. > > Scattered tasks without objective also have its objectives, they are > just not sorted well. Good organizing means to put it under right > objective and work by achieving objectives. City administrations do > like that. Military does like that. Boy scouts do like > that. Humanitarian organization. > > > Todo keywords don't have to be included into exported version of the > > document. > > Sure. Sometimes is necessary, sometimes not. > > > >> Unless I am badly mistaken, I think this is only true when > > >> org-enforce-todo-dependencies is non-nil? > > > > > > Variable is nil on my side. > > > > > > - [-] Something > > > - [ ] one > > > - [ ] two > > > - [X] three > > > > > > I cannot mark Something to be done without marking those subordinate > > > items. Changing org-enforce-todo-dependencies does not change > > > anything. User will need to lie to oneself to close those items to > > > become able to close senior item. > > > > I believe it is hard-coded. One may send a feature request to have mor= e > > control over this behaviour. > > It looks like I am only one observing that. And especially me I do not > like depending on Org mode to dictate how to close items. So when > there is somebody else to join in the notion that is where feature is > appropriate. Otherwise I consider Org rather made and designed for > other way thinkers and doers, not for us who think from senior > objectives as priorities where subordinate items should become > redundant and not marked as "done". > > My personal list of for a day has 7 items currently. Not 250. Those > are rather objectives, goals and purposes. Single items under > objectives are well known actions to be done and need not be marked as > TODO, but I can. My focus is on the meaning of what has to be done and > I do not need to look into tags or properties. Your informational > emails gave me to thinking so I have implemented it all. > > > > If I do turn on the mentioned variable `org-enforce-todo-dependencie= s' > > > to TRUE, I can still close the senior objective here. This is good, > > > but variable does not do expected. > > > > > ** DONE Senior objective > > > CLOSED: [2020-12-13 Sun 11:22] > > > I cannot reproduce what you observe. Also, one can forcefully change > > todo state to done even when org-enforce-todo-dependencies is set to > > TRUE. To do it, C-u C-u C-u C-c C-t needs to be used instead of C-c C-= t > > for setting the todo state. > > I can observe in emacs -Q from development version. > > So you say when you try to close senior heading that you cannot close > it? I can when that variable is true or nil, do you think it is bug? > > I can give you access to Emacs over remote ssh and you can try because > if it is bug, it is serious for those other thinkers but me. > > For me, closing the objective would mean not to mark subordinate items > as DONE or COMPLETED, rather not to mark them at all as they are > redundant. Project finished. Money earned. Such items may be > duplicated to other projects but in that particular one they become > redundant. > > > > But I am not asking for solution neither help in solving > > > unsolvable issues around Org related planning as it leads to > > > further complexities. Those issues are really solved on my side as > > > I just use it for documents. > > > Note that you are also risking to complain about things that are > > actually not a problem. Simply because you don't have a need to > > investigate what is possible. > > Yes, some of those needs disappeared when I have seen so many > obstacles. I did not use some features like org-agenda because it was > in front of me what I have to do. Things were not scattered like Org > manual advises and I disadvise. It is different paradigm approach and > so for many needs I need not even investigate what is possible. I am > interested in paradigms, approaches, methods but not in general in > gluing things together which are not meant to be together. > > You have seen discussion about Org capture screen not being able to > hold many templates. Did not I mention similar obtrusion caused by Org > agenda screen? Both screens are not even made in Org mode. I wonder > why. Making a read only derived mode is definitely more readable and > usable interface and I gave few lines as references. Tom Cross > realized that Org reinvents the wheel within Emacs interface as it > included silly (my remark) Org templates where completion function > could be sufficient enough. Maybe Carsten as author should put > attention on what users are speaking here. Fully agree > Or maybe Org mode predates completing-read and derived-mode functions > that for historical reasons it cannot display its own menus in its own > mode. > > It is our group based long brainstorming session that results in new > software. Criticizing is necessary to view what has to be improved. If > separate software come into existence within Emacs or outside it is > also good. If such software offers collaboration and concurrency > access, it is useful. > > I am Org mode user and rather use it in as member or body of > elementary nodes within a larger meta level tree. Just as some > programs use markdown for writing notes I use any mode to write nodes, > not necessarily notes. > > Jean > >