[HN Gopher] A plain-text file format for todos and check lists
___________________________________________________________________
A plain-text file format for todos and check lists
Author : quyleanh
Score : 73 points
Date : 2022-08-22 15:24 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pydry wrote:
| Why use this over orgmode?
| habnds wrote:
| do you use orgmode outside of emacs? I tried a port to vscode
| once and it was not usable.
| flakeoil wrote:
| I like EasyOrg as you do not need to use Emacs. It also has a
| useful agenda.
|
| [1] https://www.easyorgmode.com
| alexott wrote:
| I use beorg on iOS, and orgzly on android
| pydry wrote:
| I never use it with emacs. Only other text editors and
| orgzly.
|
| It's a fine standard.
| dxhdr wrote:
| > do you use orgmode outside of emacs?
|
| Outside... of emacs? You leave emacs?
| jjice wrote:
| I like this a bunch. I've used `-` to represent at task that
| isn't done and `+` to represent a task that is done, optionally
| with a time estimate in front of them. I might switch over to
| this since it's just a bit more descriptive and defined.
| ledgerdev wrote:
| I do exactly the same, and also use a tilda for tasks in
| progress, and 2 periods for those that are blocked. Sometimes
| simpler is better.
| pessimizer wrote:
| No way to create subitems i.e. when the subitems are completed,
| the parent item is completed? The main thing I need out of a task
| manager is for it to allow me to decompose and refine tasks, and
| to keep track of that stuff as it gets complicated. If the data
| format doesn't even allow for subtasks, that seems impossible
| without abusing tags.
|
| edit: I now see that it's the top issue on your bugtracker.
| jotaen wrote:
| For reference, this is the discussion around subitems /
| nesting: https://github.com/jotaen/xit/discussions/2
|
| As mentioned in that ticket, I'm still reluctant to add this to
| the [x]it! file specification. On the one hand it seems like an
| obvious and useful feature, but on the other hand it's
| unfortunately pretty difficult to implement in tooling. For
| example, I tried to add experimental support for nested
| subitems in the Sublime Text plugin, but I eventually had to
| give up, just because the syntax highlighting engine is so
| limited in regards to recursion. It's the same - or much worse
| - for other editors.
|
| At the end of the day, I feel that it doesn't help to add such
| a feature to the file format, if tools then cannot deal with it
| properly. Right now, the spec is so simple that it can be
| implemented in maybe a day or so. I see a great deal of value
| in keeping the hurdle for tool creators small. But it's a
| pretty tricky balancing act in the end.
| 0xbadcafebee wrote:
| I'd suggest creating a new version of the spec that requires
| more advanced parsing and let people add spec version to the
| top or bottom of the file via a comment. (adding comments
| would be really useful too)
| pessimizer wrote:
| > There can be conflicting state, for example: what happens
| if the parent item is checked, but the children are still
| open? Or the other way around? If all children are checked,
| shouldn't that "automatically" resolve the parent? What if
| the parent has a closer due date than the children? And so
| on. While decision could be made for any of these corner
| cases, it might still feel strange in practice.
|
| To me, the convention to go with seems easy.
|
| 1) If the parent is explicitly checked, leave the children as
| they are, and ask the user through tooling if they want to
| check each unchecked subtask, delete it, or move it up a
| level.
|
| 2) If all of the children are checked, the parent stays
| unchecked, but tooling should ask the user if the parent is
| complete, or if another subtask should be added.
|
| 3) If the parent has a closer due date than the children,
| don't do anything unless you feel like warning the user i.e.
| hold the subtasks to their due dates, and hold the parent
| task to its due date.
|
| The issue about descriptions I see as a non-issue: dictate
| that descriptions marry to the task above them. It would be
| nicer to be freer with mixing descriptions and tasks, but
| you'd have to introduce more tokens.
|
| One thing in the thread that I don't find necessary is
| marking partial completion.
|
| I don't have any experience with Sublime, but this seems like
| a very basic tree.
|
| When reading the subtasks, all you have to hold is the stack
| of the checkbox states and due dates of higher task levels
| for tooling to answer any of the above questions. A tool
| could seek backwards in order to check a parent if the
| children were checked, the user was warned, and the user said
| they wanted the parent checked. But if instead you really
| only wanted to read a line at a time, you could add a dummy
| item called "[ ] Complete parent task" at the end of the
| subtask list in order to keep an unchecked parent with
| checked children consistent.
|
| The problem for me is that a tree is what I have trouble
| organizing. If it's just a linear list of things, I'm not
| sure how useful it could be for me other than by setting
| alarms that I could set directly. There is never a time when
| one of my tasks isn't to break down another task into simpler
| steps; all but the simplest tasks I have really have "break
| this down" that as the default first subtask.
|
| So one workflow datapoint for useful with subtasks, useless
| without subtasks.
| spc476 wrote:
| I came up with this format 10 years ago to document running
| our regression test. It was a complicated process (for
| reasons) and I had four major sections---one outlining items
| to do once, such as: [ ] Check you can log
| into Jenkins [ ] Check you have an account on lab1
| [ ] SSH into account on lab1 [ ] "mkdir bin"
| [ ] "mkdir conf" [ ] "mkdir var" [ ]
| In shell configuration file, export following
| [ ] export FOOBAR=... [ ] export
| PATH=$PATH:$FOOBAR/bin:$FOOBAR/install [ ]
| export LD_LIBRARY_PATH=$FOOBAR/lib64b:$LD_LIBRARY_PATH
| [ ] Ensure you can run "sudo -u root foo" [ ]
| Ensure you can run "sudo -u nobody bar" [ ] Check you
| have an account on lab 2 [ ] SSH into account on lab2
| [ ] ...
|
| A second section outlining the steps needed to prepare to run
| the regression test. The third section was actually running
| the regression test, and the final section about shutting
| down the regression test. This list was then checked into our
| repository and any new hires were given this check list to do
| (and update it for any steps not clear or not specified---
| such updates happened a few times).
|
| When I came up with this system, I didn't know about ORG
| mode. Nor did I expect anyone to use a tool other than a text
| editor with this. Heck, a person could print this out and use
| a pen to mark items off the list.
| jxi wrote:
| falcolas wrote:
| For a standalone CLI, I still prefer
| https://github.com/todotxt/todo.txt-cli - probably because there
| are Android and iOS clients for it, and it's based around a bash
| script.
|
| For vim, I just use vim-wiki, which is a superset of this
| functionality.
|
| Of course, looking through this thread, there's lots of different
| options. Which is cool.
| bachmeier wrote:
| Discussion from a few months ago:
| https://news.ycombinator.com/item?id=30879327
| foobarbecue wrote:
| Taskwarrior uses a pain text format and is excellent. It's my
| daily driver todo list. https://taskwarrior.org
| shagie wrote:
| An online site that does task warrior sync - https://inthe.am
| NonNefarious wrote:
| 0xbadcafebee wrote:
| I like it. Few issues: - doesn't describe
| handling spaces or other characters before the checkbox -
| doesn't support UTF-8 checkbox emoji - doesn't support
| nested lists - specifies a specific space character when a
| character class would be better - not clear what "item must
| not contain blank lines" means - description indentation
| limit of four space characters is a problem for nested items
| - description supporting blank lines (properly indented) would be
| useful for longer descriptions - date should support an ISO
| or other standard date format - timezone is necessary for
| events happening in specific timezones or across timezones
| tommyage wrote:
| > - doesn't support UTF-8 checkbox emoji
|
| That's a good thing. Its also unicode, not utf-8. Your plugin
| can display it with a unicode character. Having a simple ASCII
| char set helps portability _a lot_. No benefit in supporting
| unicode code points.
|
| > - doesn't support nested lists
|
| If you can tick all items within a nested list, why bother
| writing it with dedicated TODO items? Additionally, you can
| just create more files for elaboration. Your file system is at
| your dispense. Additionally, that can be implemented in your
| plugin of choice. Goes with your first point in hand.
|
| > - specifies a specific space character when a character class
| would be better
|
| ASCII has no official character class. If your are refering to
| tabs; I don't think this is bad or good. Maybe you can follow
| uo on the use case..
|
| > - not clear what "item must not contain blank lines" means
|
| Probably that a blank line is used as a separator
|
| > - description indentation limit of four space characters is a
| problem for nested items
|
| I don't see why. The fixed amout of four characters obviously
| lines up to the start of the text from an item. This helps
| readability a lot. And is a simple standard for identation
| rules.
|
| > - description supporting blank lines (properly indented)
| would be useful for longer descriptions
|
| I disagree. A TODO list should be simple to grasp. Details and
| elaborations can be put in a dedicated directoy and refered to.
| Also, it is a _very bad_ idea to work with invisible lines.
| Users are dump and quick to judge.
|
| > - date should support an ISO or other standard date format
|
| This is the most portable standard, but extended for human
| editing..
|
| > - timezone is necessary for events happening in specific
| timezones or across timezones
|
| I tend to agree. But the person hosting the list should
| probably be the one defining the time zone. But I haven't read
| anythinf about time zones in the primer. Nothing stops one to
| simply append it to a time. No need for the standard to define
| such.
|
| I think it is well put and the first one which checks all the
| boxes for me. Congratz to the author.
|
| I don't see why such a comment is #1.
| rubenv wrote:
| Sticking to ASCII in this day and age is nice and fun if
| English is your mother tongue, but it's a big middle finger
| to the rest of the world. Please don't.
| jotaen wrote:
| Per specification, [x]it! files must be UTF-8 encoded. (See
| https://github.com/jotaen/xit/blob/main/Specification.md#fi
| l...)
|
| You can use Unicode characters in item descriptions, so you
| can write these texts in Japanese, Finnish, or Greek. Only
| the "syntactical elements" (like checkboxes, priority, due
| dates) are made up from ASCII characters, to ensure that
| they are easy to type.
| sowbug wrote:
| Perhaps the spec could allow an implementation to support
| a _run-time_ option to recognize alternate characters for
| syntactic elements. This would have the downside that one
| person 's data might not be shareable with another
| person's [x]it installation. But that's not necessarily a
| bug, especially to people who don't plan to share their
| todo lists.
|
| This run-time-option-only approach would be much better
| than the "be liberal in what you accept and strict in
| what you emit" philosophy that tends to cause
| fragmentation on lots of different levels.
| tommyage wrote:
| You are right, I didn't wanted to imply that these lists
| can only be used by speakers fluent in english. I wanted to
| imply that grammars of languages are best represented in
| ASCII.
|
| There are languages written from right to left or top to
| bottom. No standard I know of are supporting such
| flexibility in syntax. And it shouldnt be necessary - if
| the <user text> items within the grammar support unicode
| but the keywords are ASCII only it can MORE easily adapted
| than supporting unicode....
| jotaen wrote:
| Thanks for sharing your notes. Nesting of items is not
| supported, although the idea has come up. It's on hold right
| now - that's mostly due to practical reasons, because it's
| relatively hard to implement in tooling.
|
| Allow me to clarify a few details regarding the spec:
|
| - There can't be any character before the checkbox. (An item
| "MUST start at the beginning of a line with a checkbox.")
|
| - A blank line is defined as "a line that is either empty, or
| that exclusively consists of blank characters", and a blank
| character is defined as "a character from the Unicode Space
| Separator category (Zs)". So the description text of an item
| (that can span multiple lines) cannot contain a line that's all
| blank. Reason is that a blank or empty line separates item
| groups from each other, so allowing it to appear within
| descriptions could create visual ambiguity. (Even though it
| wouldn't be ambiguous from a purely formal standpoint.)
|
| - The format for dates is a subset of ISO-8601, except for the
| slashed variant (2020/12/31) that's there for convenience, and
| the notation for quarters (2022-Q1).
| 0xbadcafebee wrote:
| It would be simpler to just use the ISO date format.
| Otherwise people have to implement their own date parser for
| your stricter format, which adds code (and therefore bugs)
| and increases probability that people will incorrectly
| implement the spec.
|
| Why wouldn't you allow space before the checkbox? If somebody
| accidentally has a space because it's not obvious in their
| editor (esp. if items can be separated by two newlines) what
| happens? Undefined behavior? Your format looks a lot like
| Markdown so I wouldn't have assumed this was a spec
| requirement unless I looked closely (most people don't look
| at specs closely)
| jotaen wrote:
| > It would be simpler to just use the ISO date format.
|
| [x]it! is supposed to be edited (editable) by hand, and
| from an end-user perspective, I personally find ISO-8601 in
| its entirety relatively complex to grasp. The currently
| supported date formats aim to be a tradeoff between
| "flexible enough" but "not too complex yet".
|
| > Why wouldn't you allow space before the checkbox?
|
| To enforce a tidy layout of the file. Whitespace before the
| checkbox (i.e. on the same line) is undefined behaviour.
| The idea is that editor plugins help users with compliance
| of the rules. For example, I think that all available
| [x]it! editor plugins would highlight it if there was
| illegal whitespace in front of a checkbox.
| ozim wrote:
| I am just getting more and more convinced that any personal todo
| list is useless.
|
| Most useless part is priorities on personal list. If something
| like utility invoice is to be paid - just do it.
|
| If it is something like "read Anna Karenina" it is not getting
| any priority ever it is just something I would like to do in my
| life.
|
| So stuff that really needs to be done I will deal with without
| any todo list I will just remember it or deal with it right away.
|
| Stuff that does not need to be done will not get done - and that
| is perfectly fine.
|
| Different thing is if it is company "todo" list and I need to
| keep customer requests, well JIRA does the job.
|
| In the end don't listen to me because there are many much more
| successful people than me, I am simply happy with what I achieved
| so far, maybe I would achieve more with todo lists but somehow I
| fail to see how these would help me in living my life.
| hiq wrote:
| > So stuff that really needs to be done I will deal with
| without any todo list I will just remember it
|
| Well you're lucky then, because I frequently have to remind
| people of important things they (still) have to do and seem to
| have forgotten. Having such a list is a way to avoid the
| stressful situation of being late with things you can't
| postpone or which you benefit greatly from doing sooner rather
| than later.
| pilina wrote:
| > So stuff that really needs to be done I will deal with
| without any todo list _I will just remember_ it or deal with it
| right away.
|
| Just remember. That's exactly the thing I (for example) am not
| capable of. I keep forgetting everything. Every time I have
| some spare time, I am checking my todo first if there's
| something I need/want/can do.
| ozim wrote:
| Thanks for your point of view.
|
| It is also why I am writing comments on the internet, to see
| what are other people life experiences.
| habnds wrote:
| something to consider is that certain todo's require the right
| location or context, for example if I'm at the office and it
| occurs to me to pay the utility bill, that would go on a "home"
| todo list.
|
| Additionally, some todo's have different timeframes than
| others. I try to think of things as short term/immediate,
| medium term/this week, and long term/nextweek-before I die.
|
| I'll occasionally pick things of the long term list and cut
| them down into an action I could do immediate or this week, for
| example, get Anna karenina from the library.
| egypturnash wrote:
| My experience is that physical to-do lists are great for
| sitting down, surveying what needs doing, and deciding what
| you're going to do today. Including decisions like "I did not
| read any of Anna Karenina yesterday but I still want to do this
| so I am putting it on today's list, and while I am thinking
| about this I took 5s to take it off the shelf and put it by the
| comfy reading chair". And things like "laundry is gonna eat 2h
| of my day today but I need some clean clothes ffs". And "I have
| six important work projects and only 3h of actual productive
| time between meetings, I am going to work on projects X and Z
| today unless someone comes and screams about the other
| projects".
|
| Digital to-do lists are where tasks go to die.
|
| I just keep on coming back to a nice notebook, a nice pen, and
| my variant of the Pomodoro method.
| jen729w wrote:
| > Digital to-do lists are where tasks go to die.
|
| I also am becoming convinced of this.
|
| The issue is that you can keep adding to them. And if you're
| the digital hoarder type - hello, my friend Alex! - you can
| never delete the old crap. So now you have this utterly
| unachievable list of things that seemed like a good idea at
| the time. And which have lost context due _to_ time, so now
| you barely even remember what you meant.
|
| I introduced Alex to Things.app's feature whereby you can
| mark a task as 'Cancelled'. So it takes it off the list, but
| you're not pretending that you did it. I hope that helps him.
|
| Me, I use slips of paper and a pencil. On my desk the slips
| closest to me are those that I'm doing, or should do, now.
| When there's too much paper, it's obvious. Throwing away (by
| sticking it on the spike) a piece of paper feels good. It's
| just a piece of paper.
| kstrauser wrote:
| I don't even try to follow by-the-book GTD anymore, but a
| lot of its principles speak strongly to me. In particular,
| the regular review cycle is critical. It feels great to
| have a process in place that explicitly grants me
| permission to delete/cancel the things I don't want or need
| to do anymore. As a result, I know that my todo list has
| only things on it that I actually care about.
| olau wrote:
| I used to do that too on paper, but at some point I ended up
| opening a text file in Emacs and do exactly what I would do
| on paper, just in Emacs. It's only a small chunk of text, so
| I don't use org-mode or anything like that.
|
| But yeah, not accumulating stuff requires a conscious
| decision and the will to stick to it. The same goes for
| paper, though. I have a coworker that at some point had a
| stack of paper over 20 cm high.
| jxi wrote:
| Normal human brain can't remember that much. It also helps to
| write down everything that needs to get done first, so that you
| can prioritize between them.
| ozim wrote:
| Maybe I am just on the boring side of life and I don't really
| have that much to do.
|
| My biggest problem earlier was that I thought I should have a
| todo list to achieve things in life. As it turns out it just
| does not matter, my connections, my starting point in life
| was much more defining to what I can achieve today than any
| form of organization of my self I would implement.
|
| Of course unless I would be totally undisciplined and
| disorganized, but it turns out that I was disciplined and
| organized enough to reach good life and adding todo list is
| not something that would help me.
| [deleted]
| hiq wrote:
| > But aren't you writing down a bunch of stuff that,
| really, honestly, you're probably not going to do?
|
| That's a separate problem, and a good reason to have
| periodic reviews. If you have big items that stay on your
| list for weeks you should consider removing them or make
| them more actionable than they currently are.
| mola wrote:
| For me it's useful to rid my mind from nagging thoughts. I
| might be working on something while suddenly thinking about
| something else to be done. If I'm not writing it, I'll lose
| focus. Writing it in a Todo list calms my mind and let me get
| back to whatever it is later, without worrying I'll forget
| about it. My mind wonders quite a bit, so this is very
| beneficial for me.
| dvfjsdhgfv wrote:
| I have a completely different approach. My personal TODOs are
| of different type: they are necessary, non-immediate, with
| varying emotional load (pleasant-unpleasant). I manage them
| using a combination of calendar and at-based reminders. These
| include things like teeth cleaning, cancelling a subscription,
| calling my parents for their anniversary and so on. I simply
| wouldn't be able to remember all these things without
| reminders, there are just too many of them.
| masukomi wrote:
| > So stuff that really needs to be done I will deal with
| without any todo list I will just remember it or deal with it
| right away.
|
| hopefully obvious note that that simply isn't an option for
| anyone with ADHD.
| kstrauser wrote:
| My problem is that I'll never remember to do those things on my
| own. I have repeating items for things that _seem_ obvious but
| that life experience has demonstrated that I just can 't track
| on my own. I _wish_ I could remember to order flowers for my
| wife in time for them to be delivered before our anniversary,
| but I won 't. A todo app for me is a lifesaver: instead of
| being all stressed out that I'm forgetting something important,
| I can get all that stuff out of my head and concentrate on
| other things.
| sixstringtheory wrote:
| Isn't a repeating calendar event with an alert a better tool
| for this? But then you have to remember to check your
| calendar or to do the thing that alert you just
| snoozed/ignored was reminding you to do. Don't forget to
| check your todo list from time to time...
|
| I have the same problem as you, of remembering things I need
| to do. But I've not found todo lists to actually help, in
| fact I find if I take too much time to maintain the list, I
| have less time to spend doing the things I'm supposed to do.
|
| Kind of like remembering phone numbers. I don't know anyone's
| phone number anymore, because I don't have to, because I have
| a place that I can store them all. The difference is that the
| phone dials it for me when I tap it; my todo list doesn't
| carry out the tasks I write on it, but it does help me to
| forget them faster!
|
| It's some mixture of https://xkcd.com/1906/,
| https://xkcd.com/927/ and https://xkcd.com/1319/
| kstrauser wrote:
| Some of those repeats are more flexible, like "water my
| plant 10 days after I last watered it". It's not going to
| fall over and die if I miss a day or 2. That also lets me
| treat my calendar as sacred: if I have an appointment
| there, I _have_ to be at that place and time. My dentist
| won 't amused if I'm a day late.
|
| I hate recommending specific apps, but after using
| OmniFocus for years, I started using Things a few months
| ago and it's been heavenly. It's not as powerful as OF, but
| has all the features I actually _need_ and not much else. I
| 'm not tempted to waste time making my workflow absolutely
| perfect and optimal instead of just, you know, _doing_
| things.
| brewdad wrote:
| I find a TODO list useful for those things that need to be
| done today as well as others sometime in the next two
| weeks. For whatever reason, it _can 't_ be done today but
| it does need to happen. Putting a reminder on my calendar
| sometimes works for me and sometimes doesn't depending on
| what other supporting actions or information or whatever go
| along with it. If the calendar reminder pops up and I'm not
| "ready" to work on that it can get lost. On my TODO list, I
| see a constant reminder that the due date is coming and I
| can ensure that I find the time to complete it. I'm not
| always the best at looking well ahead on my calendar.
|
| That's how my mind works, YMMV.
| eurasiantiger wrote:
| But are you then actually remembering her?
| kstrauser wrote:
| Yes, of course.
| oezi wrote:
| I am almost using this format for my markdown todo app written in
| Ruby:
|
| https://github.com/coezbek/rodo
|
| Differences:
|
| I use unicode symbols such as [?] or for paused or priority
| items.
|
| I use dash for obsolete/canceled items. I find this more in line
| with bullet journal which inspired the development of Rodo.
|
| I do use markdown bullet lists because I like to indent and order
| stuff.
|
| Rodo is organized primarily around showing the todos of a day
| (mostly today) and provides the tools to postpone or carry-over
| todays to another day.
| jotaen wrote:
| rodo looks quite cool! It's interesting to see how common the
| syntax is with these formats, so there seem to be "natural"
| patterns.
|
| [x]it! doesn't try to be opinionated about what you use it for.
| So you could use it for your daily todos, but you could also
| use it for writing a packing list, or maintaining a wish list
| with potential shopping items. It's intended to be a generic
| file format, and more specific use-cases could be supported
| through (independent) tooling.
| miralize wrote:
| TaskTXT (https://tasktxt.com/) looks to be a really interesting
| product in this space
|
| The creator made a few videos on the motivation & implementation
| of it. He goes into such great detail in crafting subtle almost
| unnoticable animations in the app.
|
| - https://www.youtube.com/watch?v=kZdBgVZn5NI -
| https://www.youtube.com/watch?v=JjKxpks13Zw
| eurasiantiger wrote:
| This is great. I just wonder whether it could be a superset of
| Markdown.
| jotaen wrote:
| Creator here. [x]it! was deliberately designed as a strict data
| format that stands on its own, as I think this makes it easier
| to create tooling and work with the data programmatically.
| However, I think use-cases and preferences are as different as
| the people who use them, so [x]it! doesn't aim to be the one-
| size-fits-all approach.
|
| For reference, there was also some discussion about this topic
| going on here https://github.com/jotaen/xit/discussions/10.
| NoboruWataya wrote:
| I like the simplicity of it. Sorry if I've missed it but are
| there already good tools built around this?
| jotaen wrote:
| There currently are a bunch of editor plugins and one CLI tool.
| You find a collection of tools (all third-party) linked from
| the project website: https://xit.jotaen.net
| kstrauser wrote:
| How does this compare with TaskPaper, like
| https://guide.taskpaper.com/getting-started/? TaskPaper is
| sophisticated enough that OmniFocus can use it as a serialization
| format.
| jotaen wrote:
| I've never used TaskPaper, but the capabilities of the data
| format look somewhat similar.
|
| I think the difference is primarily a philosophical one: [x]it!
| is a file format with a formal specification that's open
| source.[1] There is no "canonical" tool for it, the idea is
| rather that tools can be created separately. That should give
| users the freedom to work with their data independent of
| specific tools.
|
| [1] https://github.com/jotaen/xit/blob/main/Specification.md
| kstrauser wrote:
| That's fair. I could've sworn that TaskPaper was an actual
| spec, but when looking just now I couldn't find it.
| jotaen wrote:
| The maintainer wrote something about this here:
| https://support.hogbaysoftware.com/t/where-is-taskpapers-
| fil...
| kstrauser wrote:
| I saw that, and neither of those repos have been updated
| in the last 6 years. (Maybe they're still up to date? I
| have no idea.)
| valbaca wrote:
| Obsidian has this built-in. [ ] turns into a checkbox and
| supports sub-tasks/lists
| bobbyd2323 wrote:
| I just use a big text file where I keep all notes and todos (do
| use a [] as well), separate dates in a structured way with most
| recent date at top. Typically edit it in emacs. It just keeps
| getting bigger and bigger, but it's nice to have a single text
| file that I can search.
| bitwrangler wrote:
| 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 is
| delayed/deferred, waiting until later time Z Task is
| sleeping, waiting for some dependency
|
| I also tend to code year/month after the symbol like 2022/08 (not
| shown in the listed examples)
|
| By keeping a single char in the first line, I can easily grep and
| sort tasks to make sense of things. I know it's very crude, but
| it works well for my purposes. I welcome any suggestions or
| improvements
|
| (edit: formatting)
___________________________________________________________________
(page generated 2022-08-22 23:01 UTC)