From: Christopher Dimech <dimech@gmx.com>
To: Jean Louis <bugs@gnu.support>
Cc: emacs-orgmode@gnu.org, Ihor Radchenko <yantar92@gmail.com>
Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Date: Sun, 13 Dec 2020 18:57:34 +0100 [thread overview]
Message-ID: <trinity-c80392c0-638a-4c6a-929e-1fe828d60a6e-1607882254914@3c-app-mailcom-bs09> (raw)
In-Reply-To: <X9ZP4SbzfAkhANIa@protected.rcdrun.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.
>
> 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
>
>
next prev parent reply other threads:[~2020-12-13 17:59 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-29 18:52 Emacs inserts hardwired org-agenda-files variable, overwriting user options daniela-spit
2020-11-29 20:07 ` Tom Gillespie
2020-11-29 20:19 ` daniela-spit
2020-11-29 21:01 ` Tom Gillespie
2020-11-29 21:02 ` Kyle Meyer
2020-11-29 22:08 ` daniela-spit
2020-12-11 3:59 ` TRS-80
2020-12-11 4:16 ` daniela-spit
2020-12-11 4:32 ` daniela-spit
2020-12-11 8:25 ` tomas
2020-12-11 13:47 ` daniela-spit
2020-12-11 13:59 ` Detlef Steuer
2020-12-11 14:18 ` daniela-spit
2020-12-11 14:23 ` Christopher Dimech
2020-12-11 14:26 ` Ihor Radchenko
2020-12-11 14:47 ` daniela-spit
2020-12-12 2:35 ` Jean Louis
2020-12-12 2:41 ` daniela-spit
2020-12-13 5:19 ` Jean Louis
2020-12-13 5:51 ` daniela-spit
2020-12-13 13:19 ` Jean Louis
2020-12-13 17:49 ` Christopher Dimech
2020-12-13 20:28 ` Jean Louis
2020-12-13 3:33 ` TRS-80
2020-12-13 8:46 ` Jean Louis
2020-12-13 9:28 ` Ihor Radchenko
2020-12-13 17:31 ` Jean Louis
2020-12-13 17:57 ` Christopher Dimech [this message]
2020-12-13 17:59 ` Christopher Dimech
2020-12-14 12:49 ` Ihor Radchenko
2020-12-14 19:39 ` Jean Louis
2020-12-11 14:43 ` tomas
2020-12-11 14:54 ` daniela-spit
2020-12-11 15:46 ` tomas
2020-12-11 15:58 ` daniela-spit
2020-12-11 6:25 ` Jean Louis
2020-11-29 20:15 ` Jean Louis
2020-11-29 20:46 ` daniela-spit
2020-11-29 20:58 ` Jean Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=trinity-c80392c0-638a-4c6a-929e-1fe828d60a6e-1607882254914@3c-app-mailcom-bs09 \
--to=dimech@gmx.com \
--cc=bugs@gnu.support \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).