Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Christopher Dimech <dimech@gmx.com>]

> Sent: Sunday, December 13, 2020 at 6:31 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Ihor Radchenko" <yantar92@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
>
> * Ihor Radchenko <yantar92@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.

It becomes important for professional writers in the context of finishing
articles and books.

> 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.
>
> 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
>
>