Hacker News Reader

Comment by ribtoks | Hacker News Reader

Sure, but whenever you feel like you have an idea, you have to open your TODO list in org mode and update it. Also when you finish your intermediate goal, you have to again go to your file and mark item as done. In my case when you remove the comment right in the file you're working on, the task gets closed. Simple automation.

View on HN

It's pretty trivial to keep an open "project.org" buffer open for whatever project I'm working on. This is pretty natural in emacs but sometimes vim users aren't as confident with tabs or buffers.

There is also https://github.com/alphapapa/outshine

Which gives you "full" orgmode in comment sections of your normal source code (haven't actually tried it myself).

Overall I think you are on the right track with your goals but, yes, orgmode does a great job of solving them already with a bunch of additional features too.

First of all, the buffer will be too small for all tasks created on a branch and you don't want to have this buffer big, unless you have 2 monitors and have Emacs frame with this buffer opened for a half of it.

Also this process is not automatic - you have to navigate to the buffer and close the task when it's done. Also from the that buffer it's impossible to sync outside (GitLab/GitHub) or share your tasks with a team, what is possible with Kanboard if it's running on DigitalOcean/Heroku or simply synchronizes with GitHub.

If one really wanted to do it all in emacs' org-mode but also have it be automated and sycned with the code, I believe the solution would resemble something along the following lines:

Literate Programming in the Knuth sense with org-mode file using tangle[0] blocks holding the source code which can be used to generate and build the project, and a combination of regular emacs lisp code and some org-mode evaluated emacs lisp[1] to do whatever automation is needed.

Now the TODOs can be in the org file, which contains the source, and may also have a reference (automated) to the TODO, which when closed with the regular org-mode command (and is generally only two key chords) will remove the comment as well as update your agenda, calendar, kanban, etc.

[0] https://orgmode.org/manual/tangle.html

[1] https://orgmode.org/manual/Evaluating-code-blocks.html

It doesn't need to be a specific TODO file.

I have a dev log in org mode. Any thoughts about what I'm working on go there. Including TODOs. It's always open, so there is no open/save/close process.

Of course, I have to update it. But it's just one more file that gets updated. It's not onerous.

Plus, I'm not destroying documentation about my development process. I have used this method since I started developing professionally 15 years ago. I can go back over a decade and look into why I did certain things for a piece of code and how I decided to break the work apart.

Wow, how big is your dev log file?

If all my open problems could be localized in a single place in the codebase, I might indeed keep all my todo items as comments. But sometimes they span a lot of the code.

The organizing principle of the todo document is problems. The organizing principle of the code is something else -- control, data. Perhaps ideally they would align, but in my experience they don't.

The point of todo comments is that they are written across all your codebase and the system collects them and visualizes without manual intervention.

Oh. That does sound pretty nice.

Reply on news.ycombinator.com