Aw, that's not what I hoped it would be. An actual file-based calendar UI is a neat idea, where you can (for instance) echo into a file to create a calendar event on the command line.
I don't have more than 10 entries per week. Partly because I prefer real work over meetings, so I work at a place that does not have a lot of meetings. And once you don't have many, it's easier to remember other appointments, no need to use a calendar for everything. So even if this had been a useful mapping of calendar entries into a directory tree, I would not have felt an urge to use it.
Could one use the txtai python libe to be told to train on the temporal relationships between events that pass through it as an fastAPI endpoint to a calender... then as the events head to whatever is holding them in the calendar - txtai is training and indexing, first on temporal notes, then on context. so you ould easly as it to give you a
"Show all the social events that happen on wednesdays with a dress code"
(but it learns the nature of certain events, when they occur and social clues around what /who /wheres are typically occuring...
"This venue typically holds events on W F S and the clientelle is typicalaly this, attendance that, rsvps x, cost ~$$"
the most amazing feature of the Google calendar web UI that has since been dropped was a way to schedule events with a human message - "30 meeting with Bob next Tuesday at 10", rather than clicking a bunch of buttons in a UI.
I remember that! I think they have just collapsed to handling what most people try, evidently '[time] description'.
A couple of weeks ago I was surprised and annoyed that adding an event with description "10:30-11:00 Pointless Meeting" no longer scheduled my Pointless Meeting. Tried again very carefully. Wasn't working. Worked again the next day. Did anyone else experience this?
I can't wait for them to feed my description to an LLM to generate the event. "Schedule drinks at 7 at the bar behind the office next Tuesday. Invite my favourite colleagues and their teammates. Make them curious but not suspicious."
Well in a CLI you're not writing full English sentences. You don't say "make a directory called xyz in the current directory," you're saying "mkdir xyz". I'd rather just use a GUI than type out a full natural-language sentence.
With Google Assistant you can still do this, but you need to speak it, with the prefix "Add calendar event..."(well, Google Assistant on the phone also accepts keyboard input). I find it much faster than the button clicking.
Similarly in iOS there's some surprising: "Move my 3pm meeting from today to tomorrow 10am", and a clutch tip: "Hey Siri, Delete All My Alarms", b/c there's no UI to delete and confirm the 100 alarms that accrue of "7:00am, 7:05am, 7:07am, 7:15am, ...etc..." ;-)
Not this exactly, but I used to keep a calendar as a text file, where each day was a single line containing the date, week day and possibly some events.
Something like:
4h sun: 1500 dentist's appointment, 1800 dinner with friends
Where a=jan, b=feb, c=marc, ... l=dec.
The initial file was autogenerated with a 10-line Python script.
You can have variations on this, like allowing multiple rows per day, one row per event.
I also used to keep an unstructured "journal.txt" file, where notes were separated by two blank lines, and you could reference topics (like #toRead) and dates (like #4h24) with #, like social media hashtags.
I was thinking about this and came to the conclusion that I'd want to define some events per date, like you illustrated (`"12:30 dentist" > /cal/2024/08/04`), but others I'd like to define per event, like `2024-08-23 12:30 > /cal/massage`, which seemed messy. I didn't really resolve this question for myself.
I wasn't considering making it a virtual filesystem. My main goal was something that's editable with any text editor and syncable with SyncThing. I guess denormalization doesn't necessarily mean that these requirements are not met.
The point of such fake filesystems (like /proc or /sys) is that everyone immediately understands them. Yes, you could have a syscall for /proc, but it is more complicated.
