> Sent: Sunday, December 13, 2020 at 6:31 PM > From: "Jean Louis" <bugs@gnu.support> > To: "Ihor Radchenko" <yanta...@gmail.com> > Cc: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > * Ihor Radchenko <yanta...@gmail.com> [2020-12-13 12:25]: > > Jean Louis <bugs@gnu.support> 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 nature > > > 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 urge > > to fix small details instead of finishing the first draft and moving to > > more fine-grained edits afterwards. One way around this urge is quickly > > 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 more > > 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-dependencies' > > > 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 > >