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

[Jean Louis <bugs@gnu.support>]

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

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