To: Tim Cross <firstname.lastname@example.org>
Subject: Re: Adding Org Files to org-agenda-files
Date: Sun, 29 Nov 2020 03:54:20 +0100 [thread overview]
Message-ID: <trinity-c5fb8f53-923b-40cc-8eed-c1144be404d5-1606618460250@3c-app-mailcom-bs11> (raw)
> Sent: Sunday, November 29, 2020 at 2:36 AM
> From: "Tim Cross" <email@example.com>
> To: firstname.lastname@example.org
> Subject: Re: Adding Org Files to org-agenda-files
> email@example.com writes:
> >> Sent: Sunday, November 29, 2020 at 12:18 AM
> >> From: "Jeremie Juste" <firstname.lastname@example.org>
> >> To: email@example.com
> >> Cc: "Org-Mode mailing list" <firstname.lastname@example.org>
> >> Subject: Re: Adding Org Files to org-agenda-files
> >> || On Saturday, 28 Nov 2020 at 22:45, email@example.com wrote:
> >> >
> >> > Many thanks for helping me. I would not have got to this stage without
> >> > your helpful commands and checks.
> >> You are welcome ;-)
> >> >
> >> > Getting used to a problem to the extent of depending on it is not a good system.
> >> > Emacs should follow what the user demands by default, with perhaps the option
> >> > for the user to change that behaviour. But it is the user that should demand
> >> > it. In situations when Emacs gets to do something so drastic, it should inform
> >> > the user what is happening and put that information in a log file.
> >> What you see as a problem some see as a solution. For instance, it depends how many
> >> org-files you want to add to the agenda. Some users including me have 2
> >> or three files in org-agenda-files so I never interact with this
> >> variable directly.
> > I have many and they change quite frequently, depending on project.
> > So often torture emacs hard. Have sent a bug-report about it. Keen
> > for a change to go through.
> What was the bug tracking number? I'd be interested in seeing what you
> are wanting or what exactly you feel is a bug.
> From following the thread and adding a lot of assumptions/guess work, I
> think there are quite a few options to satisfy your requirements. Some
> of them are fairly easy, some may need some basic elisp and some may
> require a shift in user perspective. The choice depends a lot on what
> the user is comfortable with.
> This list is often really good at providing assistance. However, often
> it is better to also outline what your actual high-level goal is rather
> than as how to do a specific step in what you believe is the answer to
> achieving your goal. Org mode is a powerful and feature rich system
> which can take a bit of time to really understand. Sometimes, what you
> believe is the solution to your problem can turn out to be something
> which already exists, but in a slightly different form, so is not
> recognised, or maybe is a bad idea or perhaps can be achieved easily by
> slightly modifying the requirements in a way that does not impact on the
> final goal.
> As an example, you asked how to send a capture buffer to two files. It
> would be good to understand why you want to do this because on the face
> of it, there are some really good reasons NOT to do this. For example,
> this will create two copies of the same data. If, for whatever reason,
> you later need to update this information, you will have two places you
> need to remember to update. If you only update one, at some point in the
> future, you will be in a situation where you have two bits of
> information about the same thing which are different and won't know
> which is correct. Understanding why you want to do this will give list
> members the opportunity to point out alternative solutions which may
> meet your requirements, but avoid the possible problems with your
> current approach.
> It is a similar story with respect to the management of org agenda
> files. There are many different approaches to this and understanding
> your requirements rather than just helping you to fix the problem can
> From reading the thread and seeing the problems you had with executing
> commands etc, I'm assuming you are relatively new to both Emacs and
> org-mode. That is great and welcome! One of the big challenges for those
> new to org mode is learning how to best use it for your needs.
> Unfortunately, because it is such a flexible system and because everyone
> has different needs and priorities, it is impossible for org to set
> defaults which will satisfy everyone. It tries hard to find a middle
> ground, but cannot be expected to always get it right. There is also a
> need for the user to be willing to adjust their perspective to work with
> org and not against it. This is largely true of Emacs generally. Those
> who are most successful with adopting Emacs and org mode tend to also be
> those who are willing to see new possibilities and perspectives.
Thought it was a simple thing but it wasn't. Emacs was overwriting my variable.
I am new to Org Capture, Org Agenda, Calendar, and Diary. Have used Emacs
for work but never configured it myself.
> Jeremy has mentioned he only has a few agenda files. I'm the polar
> opposite - I have lots of agenda files and lots of org files which are
> not members of the agenda file list. It took me a while to find the best
> balance for my requirements and while how I manage things may not fit
> with your requirements, I'm hoping outlining them and how I got to my
> solution may give you some ideas.
> Initially, I put pretty much everything into the agenda file list. This
> worked fairly well until the size of these files began to get very
> large. The biggest problem I had was my agendas were just getting too
> large and complicated/distracting.
I have constructed four different Capture Templates and four Org Agendas
and then I can fire up the ones I want as I am working.
> I then moved to a workflow where the agenda files really only contained
> tasks and notes, references, pretty much everything else was put into
> other org files not part of the agenda file list. I didn't like that
> workflow. It complicated refiling and I lost the ability to keep all
> related things together in a meaningful way.
Have made capture and agenda by project, and then some functions
that group some of them together. Not so sure how good it is going
to until I have used for proper work.
> I then came up with a workflow which worked a lot better where I had a
> function (very simple one) which would change the list of agenda files
> based originally on what project I was working on and then later a more
> general type of work I was doing (at the time, I had 4 different 'roles'
> - main job, consulting work, volunteer work and home). This worked well
> for reducing the number/size of data which needed to be scanned when I
> called up the agenda. However, I still found there was too much or too
> many items in the agenda.
> At this point, I started using tags to provide a way to generate smaller
> agendas based on some specific criteria, such as the project I was
> working on. This really began to help and I soon came up with some
> standard agenda searches and views which really worked for me. My basic
> workflow was functioning well.
> From this point, it was about refinement. For example, realised there
> are some tasks, such as scheduled tasks, which you always want to show
> up in the normal agenda, regardless of which work 'mode' (work,
> consulting, volunteer, home) I was in.
> I now have a setup I'm very happy with. The final solution actually
> comprises components from all my workflow iterations, but typically in a
> much simpler and stripped down version. I still have the ability to
> modify the agenda file list via a function 'on the fly', but only use it
> sparingly (where I have a work situation where it needs to be kept
> completely separate from everything else).
Good to hear some others have tried a more complicated setup than
> What I did discover during this process was that 90% or more of what I
> needed already existed, I just didn't recognise it or understand it
> enough to recognise it. Nearly all my customisation is now built using
> org facilities, which is great because it makes things very stable. I
> rarely get issues with org or emacs version upgrades.
> What I learned from this process can best be summarised as -
> 1. When asking for help/guidance, outline the high level goal, not just
> the details of a problem you are having in implementing your solution.
> 2. Initially, avoid customisation when possible. Work with the system in
> default configuration for a while, even if some of it seems frustrating.
> There are often subtle reasons things are configured in certain ways by
> default which only become evident after using them for a while. Lots of
> people have used and contributed to org over the years and how it works
> has been refined to benefit from that experience.
Org is quite ok. But setting emacs takes much more time.
> 3. If you think you need to change/adjust the list of files in the
> agenda frequently, your probably wrong or are doing things in a
> sub-optimal way. Consider how you can achieve your goal without changing
> the agenda file list.
> 4. The first areas you will likely want to customise are capture
> templates and agenda views. If your not familiar with elisp, you are
> best off using the customise system to do this.
That was my task, get the capture and agenda working.
> Tim Cross
next prev parent reply other threads:[~2020-11-29 2:54 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-28 15:39 Adding Org Files to org-agenda-files daniela-spit
2020-11-28 16:51 ` Jeremie Juste
2020-11-28 16:54 ` daniela-spit
2020-11-28 17:01 ` daniela-spit
2020-11-28 17:41 ` Jeremie Juste
2020-11-28 18:12 ` daniela-spit
2020-11-28 18:30 ` daniela-spit
2020-11-28 18:43 ` daniela-spit
2020-11-28 19:01 ` Jeremie Juste
2020-11-28 19:16 ` daniela-spit
2020-11-28 19:26 ` Detlef Steuer
2020-11-28 19:44 ` daniela-spit
2020-11-28 19:55 ` Jeremie Juste
2020-11-28 20:06 ` daniela-spit
2020-11-28 20:11 ` daniela-spit
2020-11-28 20:27 ` Jeremie Juste
2020-11-28 20:40 ` daniela-spit
2020-11-28 21:32 ` Jeremie Juste
2020-11-28 21:45 ` daniela-spit
2020-11-28 23:18 ` Jeremie Juste
2020-11-28 23:29 ` daniela-spit
2020-11-29 1:36 ` Tim Cross
2020-11-29 2:54 ` daniela-spit [this message]
2020-11-29 3:51 ` Tim Cross
2020-11-29 4:05 ` daniela-spit
2020-11-29 5:23 ` Tim Cross
2020-11-29 9:30 ` Jean Louis
2020-11-29 6:50 ` Jean Louis
2020-11-29 6:41 ` Jean Louis
2020-11-29 12:28 ` Ihor Radchenko
2020-11-29 13:00 ` Tim Cross
2020-11-29 17:11 ` Jean Louis
2020-11-29 17:05 ` Jean Louis
2020-12-01 2:24 ` Ihor Radchenko
2020-12-01 8:59 ` Jean Louis
2020-12-13 15:36 ` Ihor Radchenko
2020-12-13 16:27 ` steve-humphreys
2020-12-25 2:17 ` Ihor Radchenko
2020-12-13 20:21 ` Jean Louis
2020-12-13 20:59 ` Tim Cross
2020-12-13 21:59 ` pietru
2020-12-13 23:28 ` Jean Louis
2020-11-29 4:46 ` Jean Louis
2020-11-29 14:46 ` daniela-spit
2020-11-29 17:01 ` Tim Cross
2020-11-29 17:38 ` daniela-spit
2020-11-29 20:55 ` Jeremie Juste
2020-11-30 0:21 ` Tim Cross
2020-11-28 23:36 ` daniela-spit
2020-11-29 5:51 ` Jean Louis
2020-11-28 20:28 ` daniela-spit
2020-11-28 18:50 ` daniela-spit
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).