the events are almost completely unstructured, i.e. you can’t add arbitrary content without defining a format on top of it
requires lots of manual maintenance
adding an event spanning multiple days requires adding it to every single day
same for recurring events
events don’t have an id so deleting/modifying a previously added one requires finding all the other instances of the same event over multiple days/weeks/months by guesstimating if something is the same event or not
the week in every line seems of questionable utility
not a standard format so no existing email/calendar software can use it
many new and exciting ways to fuck up your schedule with a single typo that no other calendar software has ever provided
some of these can be addressed with tooling, but then wouldn’t you just rather use something without all the limitations?
Grepability, maybe? With one day per line, searching for an event always gets the date of the event, too. (You could copy the event date for each line, but maybe that has some other problem?)
The calendar UI we have grown familiar with (for example, google calendar) is peak UI. It’s highly intuitive to modify, and highly intuitive to read. We did it, we solved calendars, and they are inherently graphical. We need a data interchange format too of course, but that was also solved long ago.
So, you’re going up against that. At best, this makes it easier to make calendar-wide changes easier with text editor features. The only way I could see myself using this is if it could at minimum show a graphical version of the calendar… but then you will want to edit from the graphical interface… in which case we are back to square one. Typing in a bespoke syntax at least needs amazing intellisense, is that offered? Even with intellisense on desktop, you very likely won’t have that on mobile, so I guess you just memorize the syntax? Probably not that hard, but annoying if you haven’t updated your calendar in a while and forgot some things, and want to add something quick on the go. That right there is the killer feature of a GUI, you can activate the human intuition to problem solve, without forcing them into full slow-think.
Some people MUST live their lives out of emacs or whatever, and more power to them! This is a fun project, just not for me, or most other people I would assume.
calendar UI we have grown familiar with (for example, google calendar) is peak UI.
I disagree. Today’s calendars focus on being a database of events. A better UI would focus on what matters to me right now, and use the “database” for queries. For example, the main screen would be what’s on the agenda for the next few days, and any big events coming up soon. Each event would include the tasks I need to do in preparation, ordered by urgency.
Anyway, claiming anything is peak UI is sus. Unless we’re talking about the terminal.
I can tell we will just disagree, and that’s fine.
For what it’s worth, it’s table stakes for calendar GUIs to have agenda/today/week/month/year view modes that are easy to switch between, which are exactly what you want? To see both today’s events and the big upcoming events, switching between views seems intuitive to me.
Sure my wording of “peak UI” is dumb. I just mean to say it is one of the very few GUIs that nearly always behaves exactly the way my intuition wants it to. Not perfect, what is, but it’s very good.
I would love a graphical gcal-like UI that used this format as a backend so I could use git to sync across devices! But editing it by hand? I’m almost as die-hard of an Emacs user as they come, but no thanks.
Should be able to do this using caldav as the syncer and ical as the data format. We already have the fully featured data format for calendars. You’ll have to find your own UI, but caldav is a somewhat commonly supported thing.
YMMV trying to use git. You’ll certainly be able to get the data into git, but every not-self-hosted calendar provider (fastmail, etc.) is going to want caldav, not git(hub/lab/etc.) Maybe there’s something out there for you though, good luck!
Nice. I have a few folders somewhere called 2024/and 2025/ inside are files 01.md etc. At the start of a new month I open up the right one and type :r !cal and then each day I type <leader> t to insert today’s date before writing something down so it’s very easy for me to organize things under headings like:
# 20250224
todo call that guy
todo compliance training
I open this file by adding a line to my bashrc: alias jn='vim ~/Documents/$(date +"%Y/%m").md' so I don’t have to remember the month or year.
I use these files to take notes which I never look at.
I like the idea, but most of my calendars are subscriptions (university things, holidays, etc), recurring events, and things like that. So I’ve been sticking with CalDAV for the past 15 years or so.
One day per line sucks if you wanna track more than 2 or 3 events per day.
some other obvious ux issues:
some of these can be addressed with tooling, but then wouldn’t you just rather use something without all the limitations?
Tbh, I don’t see why that limit is introduced. I just add extra lines for each new event, and his whole workflow still works perfectly fine
Grepability, maybe? With one day per line, searching for an event always gets the date of the event, too. (You could copy the event date for each line, but maybe that has some other problem?)
A markdown based format with a h2 for each day would be better imho. (h3 for each event)
The calendar UI we have grown familiar with (for example, google calendar) is peak UI. It’s highly intuitive to modify, and highly intuitive to read. We did it, we solved calendars, and they are inherently graphical. We need a data interchange format too of course, but that was also solved long ago.
So, you’re going up against that. At best, this makes it easier to make calendar-wide changes easier with text editor features. The only way I could see myself using this is if it could at minimum show a graphical version of the calendar… but then you will want to edit from the graphical interface… in which case we are back to square one. Typing in a bespoke syntax at least needs amazing intellisense, is that offered? Even with intellisense on desktop, you very likely won’t have that on mobile, so I guess you just memorize the syntax? Probably not that hard, but annoying if you haven’t updated your calendar in a while and forgot some things, and want to add something quick on the go. That right there is the killer feature of a GUI, you can activate the human intuition to problem solve, without forcing them into full slow-think.
Some people MUST live their lives out of emacs or whatever, and more power to them! This is a fun project, just not for me, or most other people I would assume.
I disagree. Today’s calendars focus on being a database of events. A better UI would focus on what matters to me right now, and use the “database” for queries. For example, the main screen would be what’s on the agenda for the next few days, and any big events coming up soon. Each event would include the tasks I need to do in preparation, ordered by urgency.
Anyway, claiming anything is peak UI is sus. Unless we’re talking about the terminal.
I can tell we will just disagree, and that’s fine.
For what it’s worth, it’s table stakes for calendar GUIs to have agenda/today/week/month/year view modes that are easy to switch between, which are exactly what you want? To see both today’s events and the big upcoming events, switching between views seems intuitive to me.
Sure my wording of “peak UI” is dumb. I just mean to say it is one of the very few GUIs that nearly always behaves exactly the way my intuition wants it to. Not perfect, what is, but it’s very good.
I would love a graphical gcal-like UI that used this format as a backend so I could use git to sync across devices! But editing it by hand? I’m almost as die-hard of an Emacs user as they come, but no thanks.
Should be able to do this using caldav as the syncer and ical as the data format. We already have the fully featured data format for calendars. You’ll have to find your own UI, but caldav is a somewhat commonly supported thing.
YMMV trying to use git. You’ll certainly be able to get the data into git, but every not-self-hosted calendar provider (fastmail, etc.) is going to want caldav, not git(hub/lab/etc.) Maybe there’s something out there for you though, good luck!
Nice. I have a few folders somewhere called
2024/and2025/inside are files01.mdetc. At the start of a new month I open up the right one and type:r !caland then each day I type<leader> tto insert today’s date before writing something down so it’s very easy for me to organize things under headings like:I open this file by adding a line to my bashrc:
alias jn='vim ~/Documents/$(date +"%Y/%m").md'so I don’t have to remember the month or year.I use these files to take notes which I never look at.
All notetaking software in a nutshell
I like the idea, but most of my calendars are subscriptions (university things, holidays, etc), recurring events, and things like that. So I’ve been sticking with CalDAV for the past 15 years or so.
I used https://wiki.archlinux.org/title/Remind a long time ago
calcursestores appointments one-per-line, in a plain-text format that looks like this:It’s readable and unambiguously (I think?) parseable, but also has nice tooling. I see this as a “why not both?” situation.