I am using Emacs Orgmode 9.1.3 to track habit and I saw a very useful habit template below. However I was not sure what the forward slash / meant in the date.
* NEXT HABIT
[2017-12-07 Thu 10:26]
SCHEDULED: <2017-12-07 Thu .+1d/3d>
:PROPERTIES:
:STYLE: habit
:REPEAT_TO_STATE: NEXT
:END:
I read through the org documentation but there is no mention of the forward slash in setting a repeated task.
There is a reference to some sort of reminder like this:
DEADLINE: <2005-10-01 Sat +1m -3d>.
which will provide a reminder three days in advance of a task due date.
Does anyone know what the forward slash does?
You looked in the wrong section of the documentation: this notation applies to habits where you find:
The TODO may also have minimum and maximum ranges specified by using the syntax ‘.+2d/3d’, which says that you want to do the task at least every three days, but at most every two days.
I use repeating tasks in the org-mode agenda for, for example, a daily checklist of things that need to be done. But if I go on vacation, for example, then all the dates are out of date, in which case I have to either mark them each done over and over in the agenda view, or else manually edit the dates in the actual .org file. Is there a "catch up" function that I just don't know about?
Well, if you use the ++1d or .+1d repeater, you'll just have to ack them once. While, by default, with the +1d repeater, you'll see them all 15x times...
I am trying to have the "Birthday" and "Name" properties of an Org-mode entry added to the agenda automatically:
* John
:PROPERTIES:
:Name: John
:Birthday: (5 4 1900)
:END:
I found a way to add an entry at the correct anniversary date in the agenda by inserting the following line right after the properties:
%%(apply 'diary-anniversary (read (org-entry-get nil "Birthday"))) John
However, using this code, I still have to enter the name manually. Is there a way to have the value of the "Name" property added to the diary text automatically for all entries?
EDIT 1: the example did not work before, now added parantheses around the value of the birthday property
Maybe https://julien.danjou.info/projects/emacs-packages#org-contacts is the solution to your problem. org-contacts is a address book for org-mode.
It is probably better to ask this at the Org mailing list, they are very active, and Carsten Dominik (the creator of org-mode) usually answers posts on this list almost immediately (BTW, this is the main list email.
Perhaps you a taking a path which requires you to write some lisp to get what you want. The org-mode manual gives an example of something similar, but I'm guessing you wanted a simpler format, when it describes the calendar/agenda integration http://www.gnu.org/software/emacs/manual/html_node/org/Weekly_002fdaily-agenda.html
* Birthdays and similar stuff
#+CATEGORY: Holiday
%%(org-calendar-holiday) ; special function for holiday names
#+CATEGORY: Ann
%%(diary-anniversary 14 5 1956) Arthur Dent is %d years old
%%(diary-anniversary 2 10 1869) Mahatma Gandhi would be %d years old
I would think you have other options if you want a custom setup: either a new type of export or dynamic blocks might be used. This may highlight the different use-case of agenda over the diary. The agenda seems more geared towards day to day tasks.
I've been using org-mode for a little while, I've kept it really simple for now, with only two files :
one to act as an inbox, with remember-mode
another where I stick just about anything that's been processed from the inbox
This is great for managing somewhat 'actionable' items, but I keep adding things of a more general nature, that I won't be needing on a day-to-day basis (how-tos, reading notes etc), so it's getting slow and hard to manage.
The material I'm concerning myself with doesn't fit the /projects/tasks/sub-tasks paradigms, they are more like little knowledge nuggets on selected topics, which are inherently more complex to classify and manage.
I've been wondering what kind of structure could be used to handle that kind of information (classification and retrieval), and if there are maybe other modes that could help with the job ?
I guess there is no pre-made answer to this question, since everyone may have different needs.
Noufal gave good conceptual tips that I'll keep in mind, but overall, the accepted answer provided more pragmatic views on this, the linked resource was a GREAT read.
I think this excellent document on how to use org-mode to it's fullest potential will be very helpful to you: "Org Mode: Organize Your Life In Plain Text". It is lengthy reading, but trust me, completely worth the effort.
UPDATE:
You can use the remember-mode section mentioned in the document for your use-case. (I use it for the same use-case) Remember-mode is extremely handy to make quick notes. I use it when I have to store random observations or information that won't go anywhere else. I use the following templates for remember:
(setq org-default-notes-file (concat org-directory "/remember-notes.org"))
(setq org-remember-templates
`(("Todo" ?t "* TODO %?\n %i\n" ,(concat org-directory "/remember-notes.org") bottom)
("Misc" ?m "* %?\n %i\n" ,(concat org-directory "/Notes.org") "Misc")
("iNfo" ?n "* %?\n %i\n" ,(concat org-directory "/Notes.org") "Information")
("Idea" ?i "* %?\n %i\n" ,(concat org-directory "/Notes.org") "Ideas")
("Journal" ?j "* %T %?\n\n %i\n" ,(concat org-directory "/journal.org") bottom)
("Blog" ?b "* %T %? :BLOG:\n\n %i\n" ,(concat org-directory "/journal.org") bottom)
))
As you can see, misc notes and other information goes in the notes.org file under the headings Misc and Information. If the note I'm making doesn't fall in any of the categories defined above, it gets filed in the default file (remember-notes.org) and I can always refile it to another location at a convenient time. This makes my note-taking, jotting down random ideas, and such things extremely simple, without taking away the focus from the job I'm currently doing.
[org-mode] is great for managing somewhat 'actionable' items, but I keep adding things of a more general nature, that I won't be needing on a day-to-day basis (how-tos, reading notes etc), so it's getting slow and hard to manage.
I'm a follower of David Allen and his Getting Things Done methodology. I'm using Emacs for three of the lists he recommends:
Next Actions
Project Resources
The Someday/Maybe list
The material I'm concerning myself with doesn't fit the /projects/tasks/sub-tasks paradigms, they are more like little knowledge nuggets on selected topics, which are inherently more complex to classify and manage.
I've been wondering what kind of structure could be used to handle that kind of information (classification and retrieval), and if there are maybe other modes that could help with the job ?
For this kind of information I've migrated away from emacs. Instead I keep a directory ~/etc/howto, and in that directory I put files that contain "little knowledge nuggets on selected topics", where the key criterion is that the information has long-term value.
I could search this directory with Emacs, but my Emacs Lisp is not so hot, so I wrote a howto shell script instead (some error checking omitted for clarity):
case $# in
1) ;;
*) echo "Usage: $0 <topic>" 1>&2; exit 2 ;;
esac
topic="$1"
# Note the ordering: first exact matches, then beginning matches, then any matches
set xxx `find $HOME/etc/howto/. -name "$topic" -not -type d -print` \
`find $HOME/etc/howto/. -name "${topic}?*" -not -type d -not -name '*~' -print` \
`find $HOME/etc/howto/. -name "?*$topic*" -not -type d -not -name '*~' -print`
shift
case $# in
0) echo "No file found matching *$topic*" 1>&2 ; exit 1 ;;
*) for i
do
less "$i"
done
;;
esac
Examples include:
howto football brings up three nuggets, in this order:
Instructions to give to my wife on how to record a football game on the computer
Instructions for me as exactly what to take and how to dress when I have tickets to a football game
Instructions for transcoding a football game so it can be transmitted over the net and viewed away from home
howto filesystem brings up instructions on how to copy a filesystem
howto batteries brings up a list of recommended rechargeable batteries
One reason I don't use Emacs is that my real script is a little more complicated than what you see above: it also handles PDF and djvu files, so for example howto razor brings up a djvu document of the manual which came with my electric razor.
I have over 500 items in the main directory or in subdirectories, and even at this scale the system works quite well for me. I hope you may find it helpful too.
I personally keep a list of project directories with somewhat similar structure. Each has a tasklist.org, a tracking subdirectory (where I do project estimates and time tracking and always maintain a diary which is the main thing for the project - it will have links to other files for the project), a docs subdirectory which usually consist of stuff I'm going to publish (docs for the project, proposals etc.). I get my agenda-files to the tasklist.org in each of the subdirectories so that my agenda works fine.
I think the organisation of the data would change a little in your case (perhaps topics like "functional programming" etc.). I'm sceptical of how much a hierarchical structure would help since that would confine you into one way of looking at things (tags vs. folders again). Here are some things that come to mind.
Keep a 'master' org file that has links to all the 'interesting' top level pieces of the other content (similar to the diary I mentioned above).
Tag all your material properly (you'll settle on a set of useful tags after a while) and then use the Tag search feature to search through the files quickly. This assumes that all the files are in your agenda-files though.
Finally, if your data is too exotic to put into a structure, you can consider using a full text indexer (like xapian) and integrate that into your Emacs. There was some discussion of this over here.
Update : 26/Nov/2019
I recently came across the hyperbole package which claims to be a information organiser. I haven't used it but I'm quite tempted to and will update this when I do.
I have tried several ways to manage a knowledge base in the past. I have a bunch of "knowledge nuggets" (btw, thanks, I like that term a lot) on all sorts of diverse topics ranging from how to set up apache tomcat ssl cert, to checklists for doing a monthly family budget, to keeping a list of weights and reps completed on workouts.
I've tried keeping these in a wordpress blog, on a personal wiki, using pen and paper, etc.
In the end, emacs and org-mode is the clear winner for me. I love to have the ability to start simple, and build more complex functionality as I need it. I've used a lot of the tips described by Sacha Chua.
In my case, I always end up with a bunch of notes (more formal and organized) mixed in with action items (less formal). In general I maintain one master "action item" list and then create a separate file for notes on each topic. So far, grep has worked well for me to quickly find the file containing notes. I'll often create a emacs bookmark C-x r m to quickly navigate to notes files as well.
Simple Blogs, CMS, and wikis (like Drupal and Wordpress) are good at classification and retrieval. Maybe you could export org files to html and publish them to a blog, cms or wiki? It might not be too difficult to hook into the blog/wiki/cms tagging capability.
At work, we use a wiki (actually, several - a global wiki plus a wiki per project) for this. It's ideal for non-hierarchical data, but can also be used for hierarchical data. It's formattable, hypertextual, linkable-to, searchable, shareable but also ownable, it maintains history, and other good stuff.
Personally, i used to also use a wiki for this. But these days, i generally just forget things instead. Far easier.
You can speed up org-mode by keeping your notes in a separate file (or one for each broad topic) which is not included in the usual list of agenda files. Customise org-agenda-files to see the list.
Use org-remember to enter notes quickly without interrupting your flow. Either tag them at the time, or save them somewhere to be refiled later. You can use a tag in the remember template (customise org-remember-templates) to mark notes for refiling, and use a custom agenda search (org-agenda-custom-commands) to list them.
Tag each note with relevant topics, and use the agenda view's search facilities to find them. You can define a custom search which knows to look in the right files, or you can visit the file and restrict the agenda search to just that file.
I keep a file of notes, and your question has just inspired me to go back and start tagging them all. Works a treat!
I hold tips in .rst (reStructuredText) files in single directory. Each file have own topic.
For search I use M-x occur, or M-x lgrep, or M-x ack.
Web hosted example: http://tips.defun.work/frame.html and it is easy to turn that pages into blog like solution.
Original sources with build script: http://hg.defun.work/tips/
Main advantage of reStructuredText format:
TOC support.
include syntax.
Ability to build JavaScript based full text offline search index in HTML site with TOC, index, reference by Sphinx!!
Remember Markdown suck at extensibility, RST have regular syntax for marking data by your tokens and include any plain text format as inline into your document. Thinks about graphs with dot, prog lang syntax highlighting, etc.
The material I'm concerning myself with doesn't fit the /projects/tasks/sub-tasks paradigms, they are more like little knowledge nuggets on selected topics, which are inherently more complex to classify and manage.
Use bookmarks and Bookmark+. You can create bookmarks for sets of files and directories, in addition to individual files, and you can tag bookmarks or files, a la delicious, for organization and search purposes.
I seem to get into an annual debate about the use of the $Log$ keyword. My point of view is this:
$Log$ is white hot death.
All it does is jam marginally relevant spam into your source files. Any information that anyone thinks they might be able to get from a $Log$ is more readily available from (and is likely to be more accurate in) your version control system.
So, here's the question: how would you explain to an "old school" coder (who thinks that $Log$ is the way to manage source code changes) that we have better tools now?
The CVSNT remarks on $Log$ are a good start but they're just not pointed enough. To date, the closest that I've come to a one-liner that I've managed to come up with is "$Log$ is a wish. You're hoping that what gets spammed into your file has any relation to what really happened to this file."
PS for clarity: when I say "old school," I mean old in attitude, not old in years. My first programming paycheck (and a remarkably modest one it was, too) was sometime in 1986 and I never thought $Log$ was a good idea.
I think the Subversion FAQ also has a good explanation.
$Log$ is a total horror the moment you start merging changes
between branches. You're practically guaranteed to get conflicts there,
which -- because of the nature of this keyword -- simply cannot be
resolved automatically.
In addition to what the others have said, try putting a comment (/* ... */) into a commit message :->.
The amount of useful bits in a source file slowly decreases as changes are made to it with that $Log$ statement in it. We had it in some files that came from CVS and number of lines of $Log$ statements was on the order of 10x longer than the executable code in file actually was. And it had a few groups of duplicates caused by bad merging from some branches.
You may consider (emphasis on may) embedding immutable meta-data in your file.
(See the debate between me and an "older schooler" : Embedded Version Numbers - Good or Evil?).
Even though I have always considered that practice as evil (mixing meta-data information into data), introducing "merge hell", one could argue that it could work, with the right merge manager, for immutable meta-data with a fixed format, like:
$Revision$ $Revision: 9.13 $
$Date$ $Date: 2009/03/06 06:52:26 $
$RCSfile$ $RCSfile: stderr.c,v $
But mutable meta-data like logs ? With unknown format or content ? That is bound to fail.