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

Calendar.txt

terokarvinen.com

Post reply on HN
Print view View original

11–20 of 143 posts

Re: Calendar.txt

#11

Post by aqueueaqueue »

smikhanov wrote: post #3

Sorry to be a Luddite, but isn’t this completely useless? - one line per event, so good luck finding multi-day events like “Grandma is visiting”; - rigid metadata (dates, week numbers, weekdays) stored right next to the editable data (events), so copy-pasting errors are inevitable; - the most important feature of the real calendar software (reminders) is thrown out; - grepping is really not how most people interact w…

The format is probably ok for non-edit logging like journalling or recording something like weight loss.

Re: Calendar.txt

#14

Post by oneeyedpigeon »

lblume wrote: post #5

> Unix philosophy. It's one day, one line. The Unix philosophy is often recited as "do one thing, and do it well". This does one thing, but doesn't do it well at all.

Without any explanation, this comment isn't particularly productive. Can you explain how it doesn't do it well?

Re: Calendar.txt

#15

Post by oneeyedpigeon »

smikhanov wrote: post #3

Sorry to be a Luddite, but isn’t this completely useless? - one line per event, so good luck finding multi-day events like “Grandma is visiting”; - rigid metadata (dates, week numbers, weekdays) stored right next to the editable data (events), so copy-pasting errors are inevitable; - the most important feature of the real calendar software (reminders) is thrown out; - grepping is really not how most people interact w…

> one line per event, so good luck finding multi-day events like “Grandma is visiting”

The format allows for variable granularity and ranges. If Grandma were visiting for a week, it would be fine:

  2021-02-20 w07
Right now, the range (start-end) can only be hours, but changing that could fulfil your requirement, e.g.

  2012-02-20 w07 Mon-Fri Grandma is visiting
> grepping is really not how most people interact with a calendar.

I don't think the creator ever suggested for one minute that this is a calendar for "most people"! Most people don't use Linux, macOS, or a command line.

> sorting by date must be done manually, my god.

  | sort
is not much of a hardship. At least it's possible, unlike a typical GUI app that doesn't support sort.

Re: Calendar.txt

#16

Post by oneeyedpigeon »

ndegruchy wrote: post #2

I like this. It's a lot like Emacs `diary` system. Though, you can group multiple events under one day heading. I will say that I like how `grep`-able this is. As long as you know the rules, it's pretty easy to parse. You could probably whip up an alarm system in bash and cron/systemd and let it alert you like all those big-box programs do.

Exactly. Some people are looking at the format and thinking "well, this doesn't do much" but they're missing the point: it's a plain text format that plays very well with other common tools such that 'doing more' is trivial.

Re: Calendar.txt

#17

Post by kapep »

oneeyedpigeon wrote: post #14
lblume wrote: post #5

> Unix philosophy. It's one day, one line. The Unix philosophy is often recited as "do one thing, and do it well". This does one thing, but doesn't do it well at all.

Without any explanation, this comment isn't particularly productive. Can you explain how it doesn't do it well?

I would say it doesn't do anything. It may has well defined what should be done - but doing it well and correctly is burdened upon the user.

Re: Calendar.txt

#18

Post by pydry »

orgzly revived with org mode

It's like this, but better. I actually get notifications from my calendar text file. I can set some of them as alarms.

Re: Calendar.txt

#19

Post by tero »

Brajeshwar wrote: post #12

A very similar idea and philosophy - http://todotxt.org

I can recommend todo.txt, as I've been using it for years. Todo.txt was one of the inspirations to create calendar.txt.

It also works nicely together with calendar.txt for me. I can 'grep' trough both to see all todos and events related to a project or a +tag.

Re: Calendar.txt

#20

Post by tero »

oneeyedpigeon wrote: post #15
smikhanov wrote: post #3

Sorry to be a Luddite, but isn’t this completely useless? - one line per event, so good luck finding multi-day events like “Grandma is visiting”; - rigid metadata (dates, week numbers, weekdays) stored right next to the editable data (events), so copy-pasting errors are inevitable; - the most important feature of the real calendar software (reminders) is thrown out; - grepping is really not how most people interact w…

> one line per event, so good luck finding multi-day events like “Grandma is visiting” The format allows for variable granularity and ranges. If Grandma were visiting for a week, it would be fine: 2021-02-20 w07 Right now, the range (start-end) can only be hours, but changing that could fulfil your requirement, e.g. 2012-02-20 w07 Mon-Fri Grandma is visiting > grepping is really not how most people interact with a ca…

You're quite right, oneeyedpigeon. The main audience of calendar.txt are people who always have terminal open, and who are using grep, sort and similar all the time anyway.

I use +plustags for multiday and recurring events. So for each line +grandma is visiting, I would add the tag +grandma.

I take similar approach with my courses, +tt for pentesting (from the word in Finnish). I found that for me, creating and validating recurring and multiday events was easier for me. Of course, your mileage may vary.

Smikhanov, you found copy pasting challenging. For me, copy pasting from some dedicated calendar software was a challenge. Copy-pasting with calendar .txt makes it easier for me to keep date, week number, weekday and the event together. And your comment on paper planners was on the spot, I wanted to catch some of their benefits, transparency and reliability with calendar.txt.

Post reply on HN