* Re: Some feature requests/questions
2022-04-19 15:49 Some feature requests/questions Philip Kaludercic
2022-04-19 16:34 ` Eric S Fraga
@ 2022-04-27 0:52 ` Tim Cross
1 sibling, 0 replies; 3+ messages in thread
From: Tim Cross @ 2022-04-27 0:52 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-orgmode
Philip Kaludercic <philipk@posteo.net> writes:
> Hi,
>
> I was wondering if someone could help me out to solve these annoyances I
> have been having with Org:
>
> 1. Most things I would like to clock are related to Emacs, but I often
> forget to check my agenda first, clock in, then clock out. Is there
> some way I can automatically manage clocking when I enter a
> directory/kill the last buffer?
Emacs has various hooks which are run when you enter/leave/kill buffers
or start a mode etc. You could perhaps use them. However, this sort of
automation may not be as useful as you think. You probably jump around
into different buffers more than you realise and often, you will change
buffers even when working on the same task. I also think how you clock
your time is as important as just clocking time. It can be good to
really think about why you want to clock time. What is the real goal. Do
you really want to clock how long you spent in buffer X or is your aim
to clock how long you spent working on task Y, which may have included
multiple buffers, reading books, web pages, blogs, emails, phone
conversations, etc. Even more critical is thinking about how you will
use the data. If you clock at too fine grained a level, you will end up
with hundreds, maybe thousands of clock entries. How will you use that
data and what will that fine grained logging tell you which you didn't
get at a higher more abstract logging level?
>
> 2. Capturing is configured by describing what keys should do via
> `org-capture-templates'. Is there some way to use bookmark-like
> strings and completing-read?
>
> 3. Related to the previous point, is there a way to configure capture
> templates /in/ org files? That would make it easier to dynamically
> add notes, without having to do so centrally, in my configuration
> file.
>
Can you expand on this a bit. What you describe makes me wonder if your
perhaps defining capture templates which are too specific and maybe not
taking full advantage of capture template functionality.
Typically, your capture templates are defined at a high enough
abstraction level that you only need a very small number which are
defined centrally and rarely need to be modified. This small number of
templates work across projects, tasks etc. Sometimes, the way to enhance
templates is not with the template definition itself, but rather with
the use of other facilities, such as snippets, abbrev tables, macros,
etc.
I'm not a big fan of scattering org configuration information across
multiple locations. Org is an evolving system with new functionality
being added all the time. While a lot of effort is put into preserving
backwards compatibility, it is often necessary for users to tweak their
own configuration to maintain existing behaviour or turn on some new
feature. When configurations are scattered across multiple files, this
becomes harder to maintain.
Having said that, the general answer to your question is "Yes, what you
want could be done - this is emacs! However, at this point, there is no
'out of the box' functionality which would do what you want just by
setting a variable or loading an additional file. Basically, answer is
"Yes, but some assembly required".
> 4. Limiting until when events may repeat, without having to duplicate
> timestamps manually (or via `org-clone-subtree-with-time-shift').
> Better yet being able to do so for an entire subtree/file, and have
> the property inherit itself.
This one is a little more complicated. Working with date/time data is
extremely complicated, particularly as many of the issues are somewhat
subtle and easily overlooked until they come up to bite you. For the
more complex scheduling requirements, some users like to rely on the
capabilities of the Emacs diary sexps, which are supported by org, to a
point. Again, I think most of the building blocks are there, but some
assembly is required.
>
> All of these issues I have encountered by trying to use Org for the last
> few years at University, managing courses, notes, assignment due dates,
> appointments, etc. The friction that these issues cause often have me
> become sloppy after a while, which defeats the entire purpose.
>
One of the great benefits of org mode is how well it can be configured
to suit your workflow. This is a fundamental difference between other
solutions which tyhpically require you to modify your workflow to fit
with its view of how things should be done. However, this can also be a
weakness. Sometimes, the way we develop a process 'naturally' is not
always the best or most efficient. We may need to also adjust our
workflows to enable more efficient exploitation of the tools at hand.
I'm reminded of the old joke about NASA spending millions on developing
a pen which would work in zero gravity while the Russians just decided
to use a pencil. It would be a good idea to spend some time examining
the frictions you encounter and thinking about alternative ways to
eliminate them which does not depend on new fucntionality or writing new
code. Look at how others use org and think about how you can adapt their
ideas to meet your requirements.
> I have little experience with the Org codebase, but would be interested
> in helping to implement these features, in so far they don't just exist
> and I haven't found out about them.
It is not always easy to say whether a feature exists or not within org
because in many cases, adding some feature can be almost trivial with
just a few lines of elisp. There are also many add-on packages out there
which extend and enhance org mode which I am not familiar with.
I don't think any of your requested features are already there just
waiting to be enabled, but org mode is sufficiently large and complex
and my understanding of it is sufficiently limited that I could be
overlooking or unaware of something. My suggestions would be
- Analyse your org workflow pain points/friction and consider all the
options, including modifying your workflow. Check out various blogs
and posts from others on how they use various org features to broaden
your outlook. However, also remember there is no automation for self
discipline. Regardless of what you develop, you will need to apply the
discipline to use the system - all you can do is make that a bit
easier to do.
- Select an option which you think can meet your needs, even if it isn't
perfect. It just has to reduce the pain/friction.
- Rinse and repeat until you have it down as far as you can get with
just standard org and existing org add-on packages.
- At this point, you should be in a better position with less
friction/pain. Use the system for a few weeks and then reassess.
- By the time you get here, you should have boiled things down to a
small number of concrete issues you still need to resolve. Pick the
one which will likely provide the most benefit but which you think
would be achievable given current resources (time, skill level etc).
- Have a go at implementing a solution. Get a basic version working and
then bring it back here for comment/suggestions. Note that it is
better to come back early rather than late. Rough proof of concept is
better than completed polished work as it will be easier to
incorporate suggestions and feedback. Don't become discouraged when
someone points out that what you have done could have been done easier
with the use of some package or a slight modification to your
approach. This is the process and one reason to come back early with
your code.
The most important advice I can provide is "Don't over-engineer your
solution". I think this is by far the most common mistake people make
with org (it certainly was mine). Org is so powerful and so many of the
features soeem so wonderful we have a tendency to develop this all
singing and dancing org setup which does absolutely everything and can
handle any situation. In reality, what we end up with is a configuraiton
which is almost impossible to maintain and a complexity in our workflow
which makes using it burdensome. Keep it simple, review it frequently
and be prepared to throw out ideas, even those you think are good, if
they don't actually make your life easier. Be pragmatic and ruthless.
There is no point in collecting large amounts of capture data, lots of
time clocking records, thousands of todo items if none of it is ever
used or it doesn't make things better. Bottom line, if org isn't making
things better, either it is the wrong tool or you are using it
incorrectly. More often than not, it is the latter.
^ permalink raw reply [flat|nested] 3+ messages in thread