Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A plain-text file format for todos and check lists

github.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: A plain-text file format for todos and check lists

#101

Post by dumpsterlid »

kidsil wrote: post #93

Why not Orgmode? I've been using it on multiple devices without any problems. I still occasionally edit it as text (when I'm on a machine without Emacs/Orgzly).

Honestly people wanting to make a hobby project from scratch and then brag about it in a blog post to make themselves look like a more savy programmer/techie (hey, not blaming people, when it is done well it is way better than a resume with bullet points) is primarily the reason they dont use org mode. It is like wondering why people go through massive amounts of efforts to bake stuff from scratch when there is a super market and bakery down the street, except it is also like I said a resume.

If you want a plain text organizational, compositional and scheduling tool that you can use for the rest of your life and know that 30 years down the line it will be actively supported, developed and you will be able to tweak anything you want.... emacs/org mode is by far and away the best choice. It isn't even remotely close, we are talking about the difference between a planet and a tiny asteroid when you compare org mode to other plain textish organizational, compositional and scheduling tools.

For as long as humanity doesn't collapse and probably even after it does org mode and emacs will be used (there is going to be some nerd somewhere using org mode and ledger cli to meticulously track how many smoked rats and cockroach kebobs they have left to eat before they have to leave their bunker), there is just such an intense critical mass of utility under an open source license.

About the only bad thing with org mode at this point is it has such a vast nexus of interconnected capability it is difficult to even describe what exactly it is anymore lol. Like how would you even adequately describe org mode in a single sentence? It would have to be a Thomas Pynchon style sentence lol.

Re: A plain-text file format for todos and check lists

#102

Post by dumpsterlid »

dumpsterlid wrote: post #101
kidsil wrote: post #93

Why not Orgmode? I've been using it on multiple devices without any problems. I still occasionally edit it as text (when I'm on a machine without Emacs/Orgzly).

Honestly people wanting to make a hobby project from scratch and then brag about it in a blog post to make themselves look like a more savy programmer/techie (hey, not blaming people, when it is done well it is way better than a resume with bullet points) is primarily the reason they dont use org mode. It is like wondering why people go through massive amounts of efforts to bake stuff from scratch when there is a sup…

I used "lol" twice in very close proximity, I am sorry.

Re: A plain-text file format for todos and check lists

#104

Post by Stan42 »

freebit50 wrote: post #67

I came up a personal solution to Kanban's in a text file years ago. It's pretty simple in concept and easy to type. Here it is: - means not started. * is in progress. + is complete.

I see Kanban, I upvote ! Thanks for moving the challenge forward. May I share with you one of our articles that talks about it, hope it helps :) https://zenkit.com/en/blog/kanban-explained-what-youve-alway...

Re: A plain-text file format for todos and check lists

#105

Post by tpoacher »

I use a mostly identical system, except instead of lines in a textfile, I use files in a folder, where the status is denoted by the extention.

If you also assign specific icons per extension, which you can do e.g in Total commander, you have a nice icon-coded todo list.

Using files instead of lines has several advantages. E.g. you can add notes in an item. Copy paste/link across projects etc. Search items vs in-text. Use dotfiles or ignore-patterns to hide/unhide items, associate certain tasks with specific apps (e.g. calendar) ... etc etc.

Have been using this for more than a decade, works great.

Re: A plain-text file format for todos and check lists

#106

Post by gofreddygo »

gofreddygo wrote: post #73
bitwrangler wrote: post #65

I like that specification. I've used something similar for many years. I code my task list into a text file using a single character to show status: . This is a pending/idle task item, and normal priority _ Task is pending/idle, and low priority (the "someday" tasks) ! This is a pending/idle task item, and high priority (fix today/soon) * Currently working on this item # Task was completed X Task was cancelled > Task…

> grep and sort tasks to make sense of things This. grep + sort + awk = unbelievable single person task management effectiveness. And it was right under my nose all the while. I've dumbed my version even further, I just use numbers. every line starting with 1 is highest Priority and so on. another important piece i needed was a pointer to where i last left off. I just use double underscores "__". next time just open…

Side note: for weekly personal todos and tasks, I have not found a better way than a whiteboard or a piece of paper stuck on the wall.

Paper on the wall is better in many ways (e.g. easy to rip off when guests are coming over, folds into the pocket to take it with you for shopping, scan it, etc)

I use plain text files for longer term tasks and todos. One file per project.

Re: A plain-text file format for todos and check lists

#109

Post by ralferoo »

freebit50 wrote: post #67

I came up a personal solution to Kanban's in a text file years ago. It's pretty simple in concept and easy to type. Here it is: - means not started. * is in progress. + is complete.

I shifted from text-files for todo lists to using an adapted Bullet Journal 3 or 4 years back. Some times I neglect it for a few weeks at a time, but I've found it really useful on the times when I have used it extensively. In many ways, the todo section has similarities to Kanban.

But anyway, one convention I picked up from there is:

      - for a comment - something to remind yourself of the context or information to remember
      . for a task you want to do
 date . for a task that needs to be done on/by a certain date
      / for a task that is started
      X for a completed task
      > for a task that moved to a later page
It's a great system especially as transition from one state to another is just the addition of a line so very easy to do with pen and paper. Also, the act of transferring uncompleted tasks to a new page every week/month depending on preference makes it a great time to assess if things on the todo list are still worth doing as well as giving you a gentle reminder to get on and do them if they are.

Re: A plain-text file format for todos and check lists

#110

Post by rmavis »

jotaen wrote: post #89
rmavis wrote: post #81

Earlier quoted context omitted.

It's mostly the lack of nesting that convinced me not to use xit and to make my own format: http://richardmavis.info/does-the-world-really-need-another-... And I'm curious about nesting being "pretty difficult to implement in tooling"---how do you mean? At least with emacs I found it no more difficult than counting whitespace characters: https://git.sr.ht/~rfm/tdtd-mode/tree/master/item/readme.md

I’ve tried to implement the item nesting in the [x]it! Sublime Text plugin. The problem there was that I didn’t manage to implement strict rules for subitems. If you consider the following example: [x] Example item [ ] Subitem [ ] Another Sub-Sub Item Continuation of the first item’s description Some problems I encountered: - The “Another Sub-Sub Item” should not be allowed, because it skips one level (from the first…

Oh, interesting. When you put it that way---"Example item" and "Continuation ..." being the same semantic unit---I see the problem. And why nesting is easier to implement when the semantics are based on lines.

I think it's also interesting the way you say "The “Another Sub-Sub Item” should not be allowed". Seems to me the format and tooling should do what the user wants and expects, or at least try to. Why not allow it if the user wants it that way?

Post reply on HN