Posts tagged orgmode

I believe that org-mode will drive you mad if you try to use more than the bare minimum of features necessary for what you need to do.

Here’s how I’m using it to track workouts.

I have a workout.org file, which is in org-agenda-list

Workout.org has a local status header:

#+TODO TODO STARTED | DONE

The STARTED status is just handy to have, even if I don’t use it much.

workout.org contains the following structure:

Datetree
Schedule
Regimen
Stats

I have the template

("w" "Log Workout" entry (file+datetree+prompt
     "~/org/workout.org") "* %? %U" :empty-lines 1)

in my org.el which lets me create a new entry in the datetree. This entry is only to log details of the workout: weights, level of perceived effort, etc. The workout tasks are outside the datetree, in the schedule node. The schedule node contains subheaders of repeating scheduled todos:

** TODO Daily: 300 KB swings
DEADLINE: <2017-06-15 Thu +1d>
** TODO Monday: Squat/row
DEADLINE: <2017-06-19 Mon +1w>

etc. I can clock in, mark done to clock out, and then log the details in the datetree. Keeping the todo separate from the details seems like a good idea, as I don’t have to go hunting around: every workout todo is in a single spot. Each workout task has a link to a description in the regimen node: giant set blah, use these accessory movements blah, etc.

Note that these tasks are deadlines, not scheduled. org-mode considers a scheduled task to be when the task is to be started. A deadline task will appear as DEADLINE on the designated day, and org-agenda will show the number of days til a deadline.

The regimen node just contains such as giant set templates, notes on progressive increments, etc. Eventually I may use org-babel to add a such as a 531 calculator and template generator.

Stats contains my bodyweight, BF%, not in a datetree but just time stamped.

This is the simplest setup that does what I want. I could get fancier: adding tags, tweaking a report function that’ll show a plot of weights used for a specific lift over time, setting org-habit properties, writing a function to slurp the data right out of my phone’s FitNotes .csv into the appropriate places, etc.

None of that’s really necessary. FitNotes tracks and graphs specific movements and muscle groups and weights much more nicely than I would do myself. Org-habit, while useful for some things, doesn’t really make sense in this context. And directly integrating FitNotes data seems redundant. What workout.org does allow that fitnotes doesn’t, is the ability to track and schedule things in plaintext, portably.

The one justifiable increase in complexity is the abovementioned desire to incorporate a workout calculator and generator directly into the file via org-babel. For instance, being able to generate a datetree pre-filled with 531 workouts for a specified number of mesocycles. However, I’m not doing 531 although I am inspired by it. If I do switch over, I’ll probably get around to it.

That’s workout.org. It uses barely any of org-mode’s features, does what I need it to do, and can be endlessly refined into one of those org setups where the user seems to be attempting to use every feature of org-mode to weave an elaborate robot web around their lives.

The prime rule in emacs is to start from scratch. The absolute worst thing you can do is plop someone else’s stuff into your setup and expect it to work for you. In org-mode especially, this is vital. Every one of those absurdly-polished gems of org mode configurations you see, where the blogger seems to have automated themselves away, is the result of years of tweaks and personal itch-scratches built up over time in the way that only lisp allows. Few will want to show you how they did things the lazy way, only the final result guaranteed to utterly annoy anyone who plops it into their config and tries to use it. In org mode especially, that lazy way that doesn’t show off any of the really nifty features is probably good enough for 80% of the time, and can easily be used as a guide by a newbie. If they’re foolish enough to steal it for themselves, at least it’ll be simple enough they will be able to understand it and find out how to tweak it. Either way, it’s much more useful than showing the fully chromed-out inscrutable code that the config inevitably becomes as emacs is tweaked into conforming to them.

I tweaked my language-of-the day script. There is now a major language of the day (racket, elixir, haskell) and a minor language of the day (cl, chicken, clojure, erlang, ocaml). Each day gets a major language and a minor language; the major gets more emphasis.

How much more can vary depending on mood, but this way not only does something get done in each language each day, but the three I am most interested in get more emphasis each day.

It seems like a nice setup. I’ll have to play around with it more to see where the annoyances are. The other day, for instance, was a haskell day but I got damned little accomplished due to trying to get stack to work properly.

The yakshave in question: no matter how I changed $TMPDIR and $STACK_ROOT and such, stack kept trying to download its local ghc into ~/.stack on my internal drive then cartoonishly fail at attempting to stuff it into my limited (I’m on crouton) tmpfs instead of using a tmp folder on an external drive with 2TB of space. Symlinks, according to github issues tracking, apparently work fine after stack setup has done its thing, but that wasn’t the problem I was having. I eventually concluded that it’d require serious yakshaving with executability of external drives and such, and gave up for now. In the end, I got little actual haskell done due to spending so much time trying to get its environment working.

Here’s my global org todo keywords:

(setq org-todo-keywords
	'((sequence "TODO(t)" "STARTED(s)"
		"DEFERRED(p)" "NEXT(n)"
		"YAKSHAVE(y)"
		"|" "DONE(d)" "CANCELLED(c)")))

I have a YAKSHAVE org status that I can apply to tasks. I can C-c c a yakshave note (“figure out how to get stack to actually use $TMPDIR” etc) and keep doing what I was doing. I can clock in and out of it as I work on something, and see how much time was spent actually doing a task versus getting things to work. At some point I’ll log this ratio of task to yakshave by language, over time, etc.

Deferred/Next refer to tasks for a specific language that I’ll pick up again the next time its language-of-the-day rolls around.

What I’m doing is banging out a bunch of todos after language-of-the-day. C-c a t 1 r and I can see all of them. I can start one, C-c C-t it to started, and then make subtasks for it.

;; Enforce dependencies
(setq org-enforce-todo-dependencies t)

This makes a todo depend on sub-tasks. You can’t switch a task to DONE until every TODO in it is done. Yakshaves aren’t subtasks, and thus survive after the task is done as a reminder. Afterwards, I can switch the yakshave to a TODO, clock in, and start messing with it.

While writing this I popped out a yakshave task to see how to convert org source blocks to scribble code blocks. Github pages renders org and md, but I don’t know if I can tell it “this is a markdown file with org syntax you should also follow.” Hm, I wonder if frog can be made to deal with org files. In keeping with my goal of minimizing yakshaving, I decided to just indent the above code snippets into generic markdown blocks and play with it later.

I then made a note to figure out how to display clock minutes as pomodoro units just by dividing them by 25. I don’t really use pomodoro (I prefer to measure effort in cigarettes. A full gentoo stage one install is 1 pack. Getting Frog up and running: 3 cigarettes.) But, seeing things as 25 minute chunks is just more useful than seeing the raw amount of time spent. Doing the same thing later and seeing the effort drop is more impressive when you can see whole pomodoro units drop off rather than “oh it took 20 minutes less on each of these parts.”

I made a shell script that plops out a random programming language from the list of ones I’m playing with. I called it language-of-the-day.

In the morning, I add an entry to orgfile.org that drops the output of that script into today’s node and evals it. I then know what language to focus on that day.

I then C-c c and start adding todos for that language. Do foo, look up bar, try out baz, study source of quux, etc. C-c a t lets me see all these todos, and I can start working on them.

I can divide a todo into separate todo steps, set a time estimate for each, and see how long I expect the task to take. It’s possible to then compare the estimate with the reality, and see how laughable the former is. It’s possible to then look into the subtasks and see which ones were the most inaccurate. I can set a todo note to study whatever was causing that step to take so long.

Today’s language is Racket. I only have 3 todos: some exercism problems, studying the Racket style guide, and writing yasnippet/ultisnip templates specifically for Racket. The latter is gonna take a while, as I don’t feel at all like writing a snippet I will never use. I’d rather write code, note (C-c c n) when a snippet would come in handy, and keep working on it. Later, I can look at those notes and see which snippets would actually come in handy. I can also, without interrupting what I’m doing, make a note about inefficient editing habits. “find a better way to do blah” etc.

This workflow helps keep me from bouncing around too much, playing with trying the same thing in another language or editor or falling down the rabbit hole of yakshaving. I’m focusing on foolang, doing bar and quux, and can tell you exactly how long it took me to figure out how to frobulate the wibble. Afterward I can look the notes, spin them off into separate projects, remind myself that I really wanted to try out x in another language, etc.

It’s not a polished, highly automated set up for 2 reasons: I don’t like magic, and that way lays endless yakshaving. This way has enough rough edges that resisting the urge to yakshave them away is a good form of exposure therapy.