all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: daniela-spit@gmx.it
To: Jean Louis <bugs@gnu.support>
Cc: tomas@tuxteam.de, 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 06:51:38 +0100	[thread overview]
Message-ID: <trinity-74670328-cc54-4bef-9948-cda161bcf3f6-1607838698255@3c-app-mailcom-bs11> (raw)
In-Reply-To: <X9WkalZJw5A3ogvx@protected.rcdrun.com>



> Sent: Sunday, December 13, 2020 at 6:19 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: daniela-spit@gmx.it
> Cc: tomas@tuxteam.de, emacs-orgmode@gnu.org, "Ihor Radchenko" <yantar92@gmail.com>
> Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
>
> * daniela-spit@gmx.it <daniela-spit@gmx.it> [2020-12-12 05:41]:
> > > And I think it is possible for anybody regardless of programming skill
> > > level to make one's own system of management of tasks within less than
> > > a week that will get more aligned to personal individualized way of
> > > handling tasks, then trying to accommodate personal needs to software
> > > that may have gone one completly wrong direction.
> >
> > If I said that I would be barraged by accusations of rudeness! :)
>
> The key is in steganography:
> https://en.wikipedia.org/wiki/Steganography

:)

> Org mode is popular within subset of population using it where each
> other encourage to use it more regardless of how much tedious efforts
> it needs itself just to function how users would like it. Additionally
> majority of users use functions of Org mode which they would not need
> would they be simple be organized. A person well organized does not
> look throug agenda as that means lack of organization. Agenda helps
> those which are not organized. Just look at any friend or person who
> organizes life without computer and compare to people using Org
> mode. Software should replace slow methods with papers and make
> planning faster and non-repetitive. Any software shall help human to
> speed up actions.
>
> In general Org mode is excellent for personal TODO lists. That is what
> is offered in the menu, that is what is advertised. Problem is that
> there is no warning for users that personal TODO lists are not meant
> for anything but that. There is no collaboration, putting TODO items
> eveywhere IS procrastination. Using org-agenda to find procrastination
> is another procrastination. Trying to glue everything together is
> absence of good planning and not planning.

Carsten would disagree with that evaluation.  It is also for organising
professional life - with plain text.  Still, if you are disorganized,
you can use it.  Or perhaps if one is lazy - like myself, many things
I do nat have an interest in but have to oversee at least some parts of
them.

> While reading how people write to mailing list trying to solve
> problems they would never solve in the real world with paper I am
> getting more and more surprised.
>
> What Org mode needs is at least few Wiki pages where various methods
> of planning are presented as that could be useful to help people
> minimize their procrastination.
>
> My experience comes from writing plans since more than 25 years. I was
> always writing it on paper. Actions are chronologically and logically
> ordered. Main objectives are always well defined for which purpose
> subordinate actions have to be conducted. If main objectives are
> fullfiled those subordinate actions become redundant or superfluous.
>
> From Org info file:
>
> > 5 TODO Items
> > ************
>
> > Org mode does not maintain TODO lists as separate documents(1).
> > Instead, TODO items are an integral part of the notes file, because TODO
> > items usually come up while taking notes!
>
> For personal planning this may be fine for many, but I consider it bad
> habbit. If there is an action item then put any information necessary
> for that action within the action item. Print it along if
> necessary. Handle your thinker notes first once and completely and
> include what is necessary in action items.
>
> - person will not read the notes written back in time over and over
>   again.
>
> - if notes are not necessary for the action, why put them in front of
>   oneself to be read
>
> - horrible situations will take place if those notes which are not
>   necessary are put in front of collaborator who is now expected to
>   read action item and fulfill the action
>
> > because TODO items usually come up while taking notes!
>
> My action items have been written in project documents executed by
> multiple groups of people in multiple countries on distances of 5000+
> kilometers away including by people who have never seen me face to
> face. I have never put "notes" together with action items.
>
> Whoever wrote that "TODO items usually comes up while taking notes"
> was referring to oneself and imposes this habit which I never had onto
> others.
>
> In other words the manual imposes specific method of planning without
> comparison to other methods of planning. Then users learn that is
> right thing to do, ah, let me put everything together.
>
> Since 2016 almost all project planning was written by Org mode as I
> find it useful to get LaTeX/PDF output. It is then printed, carried
> physically by people on the ground and signed with initialy physically
> by hand as DONE with the date and time. There known objectives and
> those are targets to be fulfilled.
>
> Any notes arriving back from collaborators are not placed into project
> planning. If such would enhance project planning they could become
> part of planning for the next project.
>
> But generally the feedback notes do not relate to project planning
> itself, they relate to people, organizations, findings on ground, they
> are part of the report. It is not necessary to re-write the report
> back into any Org file as the plan is separate from reports and
> executions. Conclusions which come later could result in some new
> plan. But initial plan is not to be mixed with new information, it is
> rather kept intact and maybe improved for next time execution.
>
> > With Org mode, simply mark any entry in a tree as being a TODO
> > item.  In this way, information is not duplicated, and the entire
> > context from which the TODO item emerged is always present.
>
> That is the method I speak about. It is method of lack of planning but
> making "any entry in a tree as being a TODO item". That may be good
> for personal planning if those TODO lists are not many. As soon as
> lists become even little complex it will become opposite of what one
> intended to have. Instead of organized lists one get disorganized
> lists. TODO is everywhere.
>
> > Of course, this technique for managing TODO items scatters them
> > throughout your notes file.  Org mode compensates for this by
> > providing methods to give you an overview of all the things that you
> > have to do.
>
> The Org manual does admit that the offered method is not a method at
> all. It speaks of habits of some disorganized authors who simply did
> not knew better. That TODO items are scattered it is not even
> considered bad habbit. That it prevents any kind of collaboration is
> not considered a bug. That it will ask for millions of compensations
> to get the overview of all things one has to do is presented as
> something common or normal. It is common only to procrastinators.
>
> My projects in Org mode were not written with TODO tags mostly because
> the projects are often duplicated or enhanced for various groups and
> persons and are NOT personaly. Duplicated projects would give me
> duplicate results if I would be using Org agenda. Which I do not
> use. I was looking at it from viewpoint to see what it does, but I
> never used. Why should I if I have not scattered my lists of actions
> around?
>
> If I have assigned some actions to me personally yesterday, I will
> know next day what is to be done. If there are many there will be list
> of things. Because list of things is anyway action item there will be
> no need to place large "TODO" tag there. Everything is TODO. When
> completed check it out. In collaborative execution of projects it has
> to be signed by initials and checked out with date and time. We want
> things done, and not spend time on computer to satisfy bad design of
> software that is not meant to be project planning software. Why should
> I be switching TODO items on computer back and forth when completed?
> Sounds redundant to me personally. If item is action it is in the list
> of actions, there is no need to mark it TODO. I may mark it completed
> and never turn it back again as TODO.
>
> Maybe every Org user could improve their execution of tasks in life by
> actually printing the tasks, by actually using PDF export and using
> papers.
>
> Prepare the list for printing. Your thinking will be different if you
> need to print it. Your list will have more sense. Especially try to
> prepare the list for other people to understand it. You will minimize
> the number of scattered intertwined notes around the action items this
> way. Print your list. Execute what is in the list. Compare the time
> you spend by using papers. You want your things done, you don't want
> marking properties, tags all the time. Get it done. Mark whole project
> as DONE in your computer file, archive or discard it.
>
> Then later in some other project try to do it with the Org mode alone
> on computer and without printing. Then see how much time you spend in
> making "decorations" in your Org file like tags, properties,
> etc. Review how many times you changed your schedule, deadline,
> etc. In other words observe your own procrastination.
>
> Compare the time you spend by using Org mode directly with the time
> you spend by using papers.

I often include org commands in source code which I can then parse.
For instance, I can use it to determine the cyclomatic complexity of
code, and help in admin tasks.

> Jean
>
>
>
>
>


  reply	other threads:[~2020-12-13  5:52 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 [this message]
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
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=trinity-74670328-cc54-4bef-9948-cda161bcf3f6-1607838698255@3c-app-mailcom-bs11 \
    --to=daniela-spit@gmx.it \
    --cc=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=tomas@tuxteam.de \
    --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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.