#44935 > Sent: Sunday, November 29, 2020 at 2:36 AM > From: "Tim Cross" <theophil...@gmail.com> > To: emacs-orgmode@gnu.org > Subject: Re: Adding Org Files to org-agenda-files > > > daniela-s...@gmx.it writes: > > >> Sent: Sunday, November 29, 2020 at 12:18 AM > >> From: "Jeremie Juste" <jeremieju...@gmail.com> > >> To: daniela-s...@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-s...@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 > >
