3 ms·

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 h

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.

bcrosby95 7y ago
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.
- na85 7y ago
  Wow, how big is your dev log file?
WhatIsDukkha 7y ago
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 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.
- ribtoks 7y ago
  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.
  - merlincorey 7y ago
    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 https://orgmode.org/manual/tangle.html [1] https://orgmode.org/manual/Evaluating-code-blocks.html https://orgmode.org/manual/Evaluating-code-blocks.html
Jeff_Brown 7y ago
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.
- ribtoks 7y ago
  The point of todo comments is that they are written across all your codebase and the system collects them and visualizes without manual intervention.
  - Jeff_Brown 7y ago
    Oh. That does sound pretty nice.

bcrosby95 7y ago

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.

na85 7y ago
Wow, how big is your dev log file?

WhatIsDukkha 7y ago

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 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.

ribtoks 7y ago
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.
- merlincorey 7y ago
  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 https://orgmode.org/manual/tangle.html [1] https://orgmode.org/manual/Evaluating-code-blocks.html https://orgmode.org/manual/Evaluating-code-blocks.html

Jeff_Brown 7y ago

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.

ribtoks 7y ago
The point of todo comments is that they are written across all your codebase and the system collects them and visualizes without manual intervention.
- Jeff_Brown 7y ago
  Oh. That does sound pretty nice.