Re: Adding Org Files to org-agenda-files

[Tim Cross]

daniela-spit@gmx.it writes:

>> Sent: Sunday, November 29, 2020 at 12:18 AM
>> From: "Jeremie Juste" <jeremiejuste@gmail.com>
>> To: daniela-spit@gmx.it
>> Cc: "Org-Mode mailing list" <emacs-orgmode@gnu.org>
>> Subject: Re: Adding Org Files to org-agenda-files
>>
>> || On Saturday, 28 Nov 2020 at 22:45, daniela-spit@gmx.it 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
help.

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

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

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

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.

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.

HTH

Tim
--
Tim Cross