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

41–50 of 143 posts

Re: Calendar.txt

#41

Post by tero »

roland35 wrote: post #39

One thing I really would like in a calendar app is some sort of "change log", and this gets somewhat close to that, assuming you track the file in git. For example, I recently scheduled a dentist appointment 6 months from now. Unless I scroll through the calendar, or specifically search for it, there is no easy way to find that I added that event.

As you guessed, roland35, I do track my calendar.txt in git.

One main benefit from git is also to work as an insurance against (user) errors, and make the whole process much more transparent. When I have used calendars with automatic synchronization, I would have enjoyed a "change log" to make sure that my timezones and meetings are not mistakenly modified by software.

For your dentist example, I would probably just use 'grep' or find in my text editor. After all, six months of days is very little text.

Re: Calendar.txt

#43

Post by dewey »

Plain text is fine as a backing format...but not as an interface for something more complicated than text or lists.

Editing this on mobile sounds very annoying.

Re: Calendar.txt

#45

Post by zero_shift »

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 am also sceptical.

It's conflating a format for recording calendars with a syntax the user needs to write.

That syntax looks quite brittle and not very intuitive. One day = one line would get unwieldy fast. It doesn't localise well and there's no obvious way to implement recurring events beyond daily actions. (From what I can see at least?)

You could build a client on top of that but then, you lose the benefit.

It's a neat idea and it's good to see someone share a simple concept that works for them. But I don't see it working for most people.

Re: Calendar.txt

#46

Post by qudat »

emacsen wrote: post #6

As a file format, this is just fine, but I feel like there's some conflation between a file format and software meant to interact with that format. I use plain text accounting for my business, and it's lovely to be able to enter bookkeeping data with a plain text editor and keep it all under version control, but the next step is using a program such as hledger or beancount to work with that data. I'd love to work wit…

I’ve used this tool before for caldav: https://github.com/pimutils/khal

Re: Calendar.txt

#47

Post by 6510 »

Jotalea wrote: post #44
Jotalea wrote: post #42

This is an idea so basic, yet so good, that it should be general knowledge already.

I will try to include it in my custom OS from scratch. Should be simple, right?

Fix the bug where it starts in 2021

Re: Calendar.txt

#49

Post by einpoklum »

bArray wrote: post #29

My format used to be as follows: * [ ] YYYY-MM-DD * [ ] 1800: Dinner with parents * [x] Walk the dog * [ ] YYYY-MM-DD * [ ] 0900: Interview new recruit * [ ] Prepare interview questions * [ ] Upload result to HR system This worked really well for me and was easily searchable. One benefit would be that it is easily trackable in Git. These days I have a little A6 lined notebook and manually list tasks there. Each page…

This format is terrible for working with line-based tools; you need to go an unknown number of lines back to get the date or the time.

Although, TBH, the OP's suggestion of one-line-per-day puts too many items on the same ling. I would have gone with one line per event. Yes, there's more repetition, but you need no out-of-line context, you have to do a lot less parsing, and you can look at a fixed number of _columns_ and get the beginning of the description of each event, which is nicer for manual searching.

Re: Calendar.txt

#50

Post by 6510 »

tero wrote: post #19
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.

ill tell you a funny, in January I gave my old boss (who passionately hates technology) my text file and told him he only forgot to pay two days in the (hectic) year. (I make one txt per year) It listed what work was done and with who.

His response was WOAH, I've always wanted this! He then send the whole thing to the printer and put it on the wall in his office. Then he added arrows to the days he forgot to pay using a ballpoint pen. He talked a bit about periods in the year and used his finger as a pointing device.

Post reply on HN