(Later: At this point I started using C-c C-! to tag entries with a date. This now turns into a more sporadic discovery of features and changes to how I use org. By this point I was comfortably using org as a replacement for planner. So here's the rest of 2009.)
[2009-03-30 Mon 10:12] Use of remind
I took a quick look at org2remind. It seems to just move the scheduled and deadline tasks into the remind file with the proper format. It does not appear to get the other calendar items.
This is not what I am after. I want something closer to the agenda view. Remind's interesting scheduling flex would have been nice, but it's not worth the problems.
[2009-04-21 Tue 09:55] Experiment with recipes
I tried making up a test recipe. Two possible approaches for ingredients:
- I can use a Properties drawer. This has some search advantages because I can limit searches to properties. By default the drawer will be closed. I have to open it manually. There is a minor disadvantage that an ingredient could only occur once.
- I can use a table. This is easy to edit, nicely visible. There is not a search restricted to tables that I noticed.
- I could use a table, and then a property that lists the ingredients. That would be more data entry, but get both the property search advantage and the nice table. I could even use tags for this rather than invent a property. Just tag each recipe with ingredients. I had originally thought to tag with main dish, dessert, etc.
All look pretty easy. It's just time and energy doing data entry. A later step is to try to integrate the links with the Firefox scrapbook. Make a file of recipes and let it be synchronized as part of org.
[2009-04-29 Wed 08:40] Org (outline) search
I just noticed that the org mode incremental search selectively opens and closes outline view as appropriate. It's probably been doing this all along without my noticing. I must have been doing searches, although I may have done a bulk outline open first just to see things.
[2009-04-29 Wed 08:46] Recipes
I put in a few recipes. Right now the process is mostly manual. I've got them in a scrapbook. As I finish, I move a recipe from one folder to another. So far it's easier to retype than to use cut and paste. This could change for more complex instructions.
Next thing to consider is how to organize the linkages back to the originals. I could continue to use a scrapbook form. Or I could just use the HTML pages with a file link. The scrapbook form has more opaque file names. Pages are tagged by date and time. It also has the metadata contents, although I've found it to be a little quirky. The HTML export form uses readable names and has no metadata.
[2009-05-28 Thu 09:28] Search stuff
I finally set up a TAGS file. Now I have a choice:
- use M-x grep to search for a pattern, and remember to limit it to searching *.org. This gives the list of all occurrences.
- use tags-search to incrementally search through the files in the order that they occur in the TAGS file.
The etags program makes semi-random guesses when used on org files. I then edited that TAGS file to just list the filenames and have no tags.
[2009-06-08 Mon 09:17] Categorization
I'm finding it hard to get categorization right at first. Also, tagging continues to be tricky. I don't have a good mental categorization of work yet.
[2009-06-08 Mon 09:19] More Recipes
I'm getting recipes slowly converted over. The manual process of conversion adapts well to the highly variable format of recipes. I've not dealt with setting up a proper storage area for the HTML form. It needs to be somewhere reasonably stable that I can refer to. I think it should be HTML format. The surrounding file structure and naming makes HTML export format more sensible than scrapbook format.
[2009-07-20 Mon 07:58] Parallel editing
I've found that I'm not worrying as much about maintaining proper synchronization. I'll let the org files get more substantially out of sync. Repairing the collisions is not that hard.
The typical situation I find is this:
- I do a "push" or "commit" and git reports a conflict that cannot be resolved automatically.
- I use "pull" or "git gui" plus commit to get a simple local conflict collision.
- The conflicts are marked in the conflicting files. I just edit as necessary to fix. The biggest early problem was realizing that this cannot be done in org-mode. I need to switch the buffer manually to text-mode. The fixes are generally just a matter of deleting or moving lines. I rarely edit the exact same text. It is usually a matter of deciding which lines to keep.
- "commit" and distribute the fixed up version.
Sometimes the changes look complex. In those cases I'll branch, work on the branch, and merge it back in. Most of the time it makes more sense to just treat each different computer as if it were a different branch, but without the actual branch tagging.
[2009-08-16 Sun 14:57] Emacs 23.1 on Mac
Seems to work just fine. One keyboard glitch noted so far is with the mapping of the ALT key. The Carbon port of Emacs 22 remapped this to the Apple-Clover key, which made it much more consistent with other Apple applications. I actually prefer the new mode of mapping ALT to ALT, since I switch back and forth between Linux, Mac, and Windows regularly. Cross OS consistency helps me more than within MacOS consistency.