Re: Adding Org Files to org-agenda-files

[daniela-spit]

 #44935

> Sent: Sunday, November 29, 2020 at 2:36 AM
> From: "Tim Cross" <theophilusx@gmail.com>
> To: emacs-orgmode@gnu.org
> Subject: Re: Adding Org Files to org-agenda-files
>
>
> 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.

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

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

> HTH
>
> Tim
> --
> Tim Cross
>
>