[HN Gopher] Calendar.txt
___________________________________________________________________
Calendar.txt
Author : Iuz
Score : 254 points
Date : 2025-02-24 14:51 UTC (4 days ago)
(HTM) web link (terokarvinen.com)
(TXT) w3m dump (terokarvinen.com)
| ndegruchy wrote:
| 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.
| oneeyedpigeon wrote:
| 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.
| tero wrote:
| Such an alarm system would be interesting (and even sounds
| feasible), even though I don't use reminders myself.
| smikhanov wrote:
| 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 with a
| calendar.
|
| If you're ready to ditch reminders, attachments, locations, use
| the paper diary planner. At least it won't let you screw the
| dates with botched copy-paste.
|
| Update: also, sorting by date must be done manually, my god.
| lifeisstillgood wrote:
| Oh I agree ... but
|
| I believe software is a form of literacy, not engineering. And
| I believe everyone should be literate it brings great benefits
| socially and individually
|
| And if this works for him/her it's a calendar on a piece of
| paper stuck to the fridge. Great, it works for them and some
| people might find it good for them too
|
| But yeah.
|
| "One day I will get organisssseed"
| aqueueaqueue wrote:
| The format is probably ok for non-edit logging like journalling
| or recording something like weight loss.
| oneeyedpigeon wrote:
| > 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.
| tero wrote:
| 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.
| lblume wrote:
| > 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.
| oneeyedpigeon wrote:
| Without any explanation, this comment isn't particularly
| productive. Can you explain how it doesn't do it well?
| kapep wrote:
| 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.
| jbreckmckye wrote:
| 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.
| woodrowbarlow wrote:
| > You could build a client on top of that but then, you
| lose the benefit.
|
| disagree. having the data in a simple format makes it
| syncable, trackable, and guarantees that even if you don't
| have access to the software you're used to, you can always
| edit it by hand as long as you can access the file.
|
| you can build some software on top of it; or better yet,
| build sync plugins for existing software, and benefit from
| nicer UX without giving up the benefits.
| JohnKemeny wrote:
| It even says:
|
| > Unix philosophy. It's one day, one line. You can grep (only
| show lines).
|
| Surprisingly, grep is able to output several lines, so even if
| you were to use a (say) more sensible format of one line per
| _event_ , grep could still output all lines, and display them.
| emacsen wrote:
| 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 with plain text calendar software, but it would
| still need to do things such as provide a mechanism to work on my
| desktop and mobile device. It would need to handle recurring
| events automatically, and it would need to allow me to invite
| others to events and ideally to track when they've accepted or
| rejected my invites.
|
| I'd need to be able to update, cancel or propose to move events
| in such a way that others would be updated.
|
| I wish I knew of a good command line tool to interact with CalDav
| or similar servers, or that I could maintain my calendar in a
| file format and then handle the synchronization automatically.
|
| Maybe calendar.txt could play a role in that, but on its own,
| it's not quite enough for me.
| TZubiri wrote:
| This is definitely in the camp of oversimplifying by missing
| the whole problem domain.
| tero wrote:
| For reminders and other automated actions, pydry suggested
| "orgzly revived with org mode"; and kruffalon suggested
| 'remind'. I have not tried those, but they might be better
| options for notifications and reminding than calendar.txt.
|
| I use calendar.txt on a cell phone with Markor text editor. For
| my desktop, I just use micro editor on terminal, the same I use
| for most text editing tasks.
|
| Bookkeeping using plain text files sounds both interesting and
| challenging.
| marttt wrote:
| > Bookkeeping using plain text files sounds both interesting
| and challenging.
|
| It has quite a bit of a following; I personally would never
| switch back to some more "complete" application. I believe
| all the most popular implementations are listed here:
| https://plaintextaccounting.org/
| tero wrote:
| So many tempting options...
|
| Can you recommend a tool and open your accounting workflow,
| marttt?
|
| Are there any pain points, like filling tax forms or
| handling travel paperwork?
| qudat wrote:
| I've used this tool before for caldav:
| https://github.com/pimutils/khal
| divbzero wrote:
| todo.txt accomplished this with community apps that provided
| web and mobile interfaces to the text file: http://todotxt.org/
| dddw wrote:
| Yeah, simpletask
| kruffalon wrote:
| Have you looked into remind[0] while working on this?
|
| There might be value in checking that out.
|
| Personally I haven't used it in years, but the latest release is
| from this year so it seems active.
|
| ---- [0] https://dianne.skoll.ca/projects/remind/
| guessmyname wrote:
| I created a super-simple CalDav-esque web endpoint in my personal
| website that receives HTTP requests from a command line tool,
| stores the calendar events, and then returns them as a dynamic
| ICS file. Then, I use Apple's Calendar app to subscribe to a
| "hidden" URL and iCloud automatically distributes the
| subscription to all my devices.
|
| It sounds super dumb but it works so well.
|
| The main feature is that I can categorize the events (personal,
| family, work, friends, etc.) and share individual URL's with
| other people. Admitedly, I didn't try solving this problem with
| Google Calendar, Apple Calendar, or any other calendar service,
| mostly because I wanted to own my data and also learn a bit more
| about CalDav itself.
| acidburnNSA wrote:
| This is close to what I want. I manage all my calendars in
| radical caldav server and want a sharable calendar that just
| shows the empty spots between all calendars with minimal detail
| fo easy scheduling.
| zaik wrote:
| It would be nice if Radicale could serve a FREEBUSY URL which
| takes contents from a your calendars. Some applications
| support this format and can help with scheduling meetings. I
| never got to use it in practice though.
| vhantz wrote:
| Could you elaborate on the "hidden URL"?
| edoceo wrote:
| Just a hard to guess one. Like using UUID or things.
| vekatimest wrote:
| I'd be way more comfortable with a VPN or some kind of
| access-gating for a personal calendar compared to just
| exposing it on the web and relying on obscurity..
| KMnO4 wrote:
| Web calendars don't offer authentication. You have to
| build it into the URL anyway. If a service I use -- let's
| say my bank's chequing account, wants to offer a calendar
| I can subscribe to, I'll be given a URL that looks like
| https://somebank.com/api/cal?token=abc12345. Anyone who
| knows _that_ URL can see the calendar as well. No
| different than my own web app where the URL is
| https://mysite.com/dev/cal_abc12345.ics.
|
| For a personal calendar, I see no reason to make it any
| more secure than an obscure URL.
| neilv wrote:
| For a few years, I evolved a slightly-modified Todo.txt format
| for this purpose, to represent both tasks and appointments.
|
| http://todotxt.org/
|
| https://www.neilvandyke.org/todotxt/
|
| In some ways it worked well, but there were a few drawbacks, and
| eventually I switched to native calendar programs on desktop and
| mobile.
|
| Drawbacks I personally felt:
|
| * In the text file, recurring tasks didn't show up when I looked
| into the future, such as to schedule an appointment.
|
| * Calendar invites over email weren't integrated, so I had to
| enter and update those manually anyway. (Though one advantage
| over the native calendar programs I use now is that todo.txt
| doesn't force the appointment headline someone else wrote into my
| calendar view, and refuse to let me edit it in my local copy.)
|
| * I had to keep editing dates on tasks manually, every day, for
| my "current day view" of top of the file to work with priorities.
|
| * No visual calendar views with the tools I was using.
|
| * No device sync with the tools I was using (though possible).
|
| * There are only so many ways in which I was willing to be a
| weirdo at once, and this one didn't make the cut.
|
| I don't discourage anyone from trying todo.txt or calendar.txt.
| Just a heads-up of some things you might want to find
| solutions/workarounds for.
| miles wrote:
| Previously:
|
| 3 days ago, 7 points, 0 comments
| https://news.ycombinator.com/item?id=43169019
|
| 1004 days ago, 202 points, 93 comments
| https://news.ycombinator.com/item?id=31574125
| Brajeshwar wrote:
| A very similar idea and philosophy - http://todotxt.org
| tero wrote:
| 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.
| 6510 wrote:
| 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.
| tero wrote:
| Thank you for bringing up calendar.txt. My homepage is feeling
| the hug. In the meanwhile:
|
| https://web.archive.org/web/20250216110151/https://terokarvi...
| tero wrote:
| Now my homepage should answer in under 300 ms again. Thanks for
| visiting!
| pydry wrote:
| 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.
| kleiba wrote:
| Emacs got you covered, my friend, no reason to reinvent the
| wheel:
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Fo...
| krupan wrote:
| The diary is fine, but have you seen org-mode?
| jaza wrote:
| I don't like that week numbers are (documented as) mandatory. I
| wouldn't see myself grepping on a week number. I'd end up
| constantly looking up the correct week number in order to
| annotate each event properly, with no benefit in return. Then
| again, could write a macro/plugin thingy for one's editor of
| choice, to fill in the week number for you (ditto for day of
| week, which I would at least find quite useful, but which would
| similarly be a right pain to have to fill in manually all the
| time).
|
| Also: claims to be "one thing per line", yet allows and
| encourages multiple events on one line (as long as they're on the
| same day). This is a calendar - is an event not the main "thing"
| we're dealing with?!
| tero wrote:
| I use a template [1] that has the dates (including week
| numbers) there already. That way, I only need a text editor.
|
| In my work, similar events happen on the same week numbers in
| different years. The importance of week numbers probably
| depends on your area of work.
|
| For me, one thing is a day. That's also the context I need when
| reviewing and planning. But if I remember correctly, previous
| HN thread on calendar.txt had a suggestion where someone had an
| event-per-line format, if you prefer that.
|
| [1] https://terokarvinen.com/2021/calendar-txt/calendar-txt-
| unti...
| sunshine-o wrote:
| I love it but I believe I am deeper in that rabbit hole.
|
| I just create files in a folder with the `yyyy-MM-dd-hh:mm`
| format. I use `XX` for recurring events.
|
| I use `at` for reminders/notifications.
| bArray wrote:
| 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 is a new day and the tasks are listed
| similarly. The only modification is that sometimes I put some
| letters to theme a task, i.e.: * [ ] YYYY-MM-DD
| * [x] Home: Walk the dog
| james-bcn wrote:
| This is a much nicer format than the one in the linked article.
|
| I think my approach would be to generate a file in Markdown,
| then import that into a good Markdown editor. You could
| generate it each week or month from a template, making it
| easier to add repeating tasks like exercise and dog walking.
| bArray wrote:
| I think the format I suggested would parse in markdown, but I
| created it pre-markdown.
|
| For me the best parts are:
|
| 1. You could write a parser very quickly.
|
| 2. It's very easy to edit and add to as a human.
|
| 3. It can easily be tracked in git or via a diff-based tool.
|
| I did already think about the repetitive tasks, a long time
| ago I used to have a tool that would look at the past tasks
| and recommend future tasks (with appropriate distributions).
| One example was booking a dentist appointment every 6 months,
| even if I forgot to schedule something it would remind me to
| book one in, dismiss it or push it back.
| einpoklum wrote:
| 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.
| bArray wrote:
| I think it's somewhat passable with line-based tools, i.e.
| you could easily use sed to match a range [1].
|
| I think that it's far more important that it is human
| readable, if it becomes too tricky to edit manually, then
| just go with a database.
|
| [1] https://unix.stackexchange.com/a/236754
| apricot wrote:
| I use a small paper planner that I keep in my pocket at
| (nearly) all times. People are taken aback and ask why I don't
| use something more modern, but why should I? This works better,
| for me, than anything else I ever tried.
| tero wrote:
| It's unfair to computers how well paper planners worked.
| Among with todo.txt, paper calendars were an inspiration and
| a benchmark for writing calendar.txt.
| mock-possum wrote:
| Nested list of checkboxes in markdown is exactly how I organize
| my work days - I write it I every morning, and then review it
| every afternoon before I power down. It's basically job-
| journaling, it helps fix everything in my head day-to-day.
| setopt wrote:
| Why did you make the day itself into a checkbox? Did you use
| this for weekly reviews or something?
| krupan wrote:
| If you like this you might like org-mode
| gherard5555 wrote:
| its https://xkcd.com/927/ all over again
| NoboruWataya wrote:
| Are there that many calendar formats? I thought iCal was by far
| the most ubiquitous. I've heard of jCal as well but never seen
| it in the wild.
| jeroenhd wrote:
| I'm pretty sure the entire world uses ical files. It's a bit
| of an annoying format to parse, though. The calendar.txt file
| format seems to be made for people to interact with it
| directly through a terminal (which the target audience
| probably already had open).
| noduerme wrote:
| The first online store/cart I wrote (in php 3 or 4, around 2001),
| I didn't know sql so I worked backwards into inventing a database
| from scratch using text files. This was great for a couple years
| until someone put an asterisk into the name of a product.
| Asterisk was my row delimiter. lol.
| _glass wrote:
| Seriously, with the number of invites, slots, to juggle. Might be
| better to work again like a dev and with text files in an IDE.
| Would be funny to send invites with raising a PR. Merging,
| reviewing, ... what a beautiful mess.
| jeroenhd wrote:
| Seems useful for very basic calendar requirements. I'm not seeing
| much about timezones or anything at all about DST so I'm guessing
| this format just ignores those for convenience. Saying "times are
| local to events" is great for physical events but when you're
| dealing with an international call, you probably want to specify
| that.
|
| Using a full stop as a separator seems rather limiting, something
| less likely to appear in an event description such as a vertical
| pipe would make more sense. Now you'd need some kind of weird
| logic to write an event titled "read top 10 news.ycombinator.com
| articles". Using @ as a special character also means you can't
| store "email support@localhost.com" as an event title.
|
| And, of course, everything is hard coded in English, using
| English style time notation.
|
| This seems like a fine solution for a personal file format but
| everyone will probably have to modify it to fit their own needs.
| If I were to use it, I'd violate the "spec" all over the place by
| time and date notation alone. This could be fixed by adding some
| kind of header, but I doubt any full application will ever
| support a format like this so it's hardly a problem.
|
| If I were to use this as a file format, I'd add headers to store
| things like language, default time zone, ltr vs rtl, and alter
| the separator characters. Adding something like a title, an
| author, and the moment of last edit might also be useful.
|
| I'd personally also probably store events as separate, duplicate
| lines. That way, you can easily add an event to the bottom of the
| file without having to find/replace an existing date (or generate
| an entirely new line). Using basic POSIX tools you can easily get
| the events back to a single line without making scripts too
| difficult to read. Assuming culture and other headers match,
| you'd be able to import another calendar file by simply appending
| the event lines.
| tero wrote:
| Interesting ideas for formalization and metadata, jeroendh.
| Some comments on those:
|
| Calendar.txt is indeed a personal calendar. So feel free to
| violate the spec as much as you need or want to. My main use
| for calendar.txt is editing with text editor, and thus, I have
| not given emphasis to automatic modification.
|
| Time notation is ISO-8601 date and week number. In my view,
| ISO-8601 is an international standard and not tied to a
| specific country. I find it convenient to read and sort.
|
| I use local time for physical events. For international calls,
| I just write down the timezone "13:00Z" or "11:00EET" (update:
| or mark it in my local time).
|
| At-sign "@" for context was chosen to match todo.txt, as I also
| use that. As the calendar is personal, it does not need to be
| fully machine readble. But for your example on email addresses,
| you could still do it: @WORK email bob@example.com. The context
| starts with an at "@", email does not.
|
| Full stop "." is easy to type on a cell phone. It's true that a
| rare char would be more suitable for automatic parsing.
|
| Thanks for the ideas!
| roland35 wrote:
| 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.
| tero wrote:
| 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.
| Jotalea wrote:
| This is an idea so basic, yet so good, that it should be general
| knowledge already.
| Jotalea wrote:
| I will try to include it in my custom OS from scratch. Should
| be simple, right?
| 6510 wrote:
| Fix the bug where it starts in 2021
| dewey wrote:
| 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.
| smilliken wrote:
| Programming languages are substantially more complex than text
| or lists but are edited as text.
| arrty88 wrote:
| One event per line might just be better.
|
| `YY-MM-DD:HH:MMa (Optional repeat cron definition) "Event
| string"`
| account-5 wrote:
| I like text based formats for things. But I find that you need
| software to help with the maintenance and presentation of such
| things. Todo.txt and plain text accounting are two examples of
| this; sure you could edit the plain text but a software system
| just makes it better to use, especially on mobile.
|
| With that in mind I don't see how this is a replacement for
| caldav. Sure looking at the plain text of a caldav file is worse,
| especially one generated by a computer, but at least all expected
| calendar functionality is included. Though the sprawling RFC is
| hardly simple to follow or implement.
| Communitivity wrote:
| I like this, but need more detail in my log and have too many
| things in a given day to have them all on a line. Had the
| following idea, and will try it out at some point. Call it
| calendar.md
|
| Use calendar.txt format and method with the following changes:
|
| 1) Use markdown, with a top level heading of Calendar (so
| inclusion is easier) and the portion
|
| 2) Use :tag: instead of +tag. Tags can be run together
| (:tag:tag2:). This helps with Org mode compatibility
|
| 3) Third level heading for each event in day, following same
| format as calendar.txt
|
| 4) text under heading is for notes about the event
|
| 5) Searching and seeing info on event in day, or summary about
| day is no longer easy with grep. This is the biggest drawback
| from not using calendar.txt. Overcome by writing a tool mgrep
| that is specifically designed to search markdown files in a
| Markdown aware way (search headings or specific level of
| headings, show all headings under matching heading or just one
| level under, show all content under matching headings, search
| text and show either lines or section text is in optionally along
| with ancestry of headings).
|
| 6) Create CalendarMDMode, minor mode designed to facilitate
| calendar.md use and editing within Emacs, requires OrgMode,
| things like shortcuts for new date, new event, in-editor use of
| mgrep, etc.
|
| 7) Attempt to add CalendarMD support to Helix, which is my daily
| notes editor, using the as-yet unlanded Scheme based plugin
| system (see https://github.com/helix-editor/helix/pull/8675 )
| tero wrote:
| I especially like your 'mgrep', please do write it!
|
| I have considered similar tools that make use of MarkDown
| syntax, I feel that there are many tools waiting to be written
| here.
| abound wrote:
| I think mdq [1], which was recently on HN somewhere, fits
| this.
|
| [1] https://github.com/yshavit/mdq
| tero wrote:
| Mdq seems just what I've been looking for. I have yet to
| test it.
|
| Based on documentation, you can mdq for the chapter whose
| heading is "## Foobar"; or extract all lists in chapter
| "### Xyzzy".
|
| Thanks, abound!
|
| Update: mdq discussion
| https://news.ycombinator.com/item?id=43152704
| slmjkdbtl wrote:
| To me the biggest block for using any plain text format for daily
| stuff is I need a good mobile - laptop sync method that I can
| easily read / write and manage files on both mobile and laptop,
| does anyone have any recommendation? The best choice I can think
| right now is SimpleNote which I've been using for notes for a
| long time, but is there a way I can actually use .txt file
| instead of text been stored somewhere in a database.
| antiframe wrote:
| I just use SyncThing.
| tero wrote:
| I recommend https://syncthing.net/
|
| Works with all file formats, from photos and movies to text
| files. Cross platform: Linux, Windows, Android, probably also
| Mac and BSD.
|
| Update: And it's end-to-end encrypted and free, open-source
| software.
| barbazoo wrote:
| I use syncthing for notes across iOS and macOS devices and I
| wouldn't say it's great. It works most of the time until it
| doesn't, until one client all of a sudden stops syncing and
| then you gotta figure out where it's hanging. Couple of days
| ago it was the macOS syncthing app. Just wouldn't start,
| wouldn't show an error. Usually it's the iOS helper app
| "Mobius Sync" not actually syncing in the background. It's
| annoying but still better than using a cloud provider.
|
| I suspect the experience is better on Android.
| krupan wrote:
| It is much better on Android
| sunshine-o wrote:
| If you find Syncthing too chatty and is a bit suspicious to
| what it connect to, you can really to set it up to only connect
| explicitely between nodes in a Tailscale network for example.
| ftr1200 wrote:
| I use my Gmail drafts as permanent, in-sync notes (with subject
| as the title of each note) Why?
|
| - No extra app needed
|
| - Keeps them quite hidden / private / secure
|
| - Always easy access (I always have emails open)
|
| - In sync with different devices
| barbazoo wrote:
| > Gmail drafts
|
| > Keeps them quite hidden / private / secure
|
| Not hidden from Google obviously :) At that point, why not
| just use Keep at that point to get proper support for notes?
| ftr1200 wrote:
| ha, well, nothing to hide to that extent.
|
| I don't know about Keep, but it's another app, which is
| kind of my point - I already use Gmail.
| nxobject wrote:
| I'm skeptical about convenient plain text is, compared to more
| structured formats, once we try to encode even more of the
| conveniences we get out of current calendaring (e.g. time zone
| shifting, notes of indefinite length, events that last the whole
| day, repeated events...)
|
| There are a few more structured formats for calendaring that
| share the virtues of their workflows: if we used JSON, would jq
| be a UNIXy tool? What about sqllite and commandline queries? Both
| would be much more easier for my overloaded mind - especially
| when parsing records - without adding more inherent complexity
| beyond a sufficiently overloaded raw text calendar.
| hoherd wrote:
| I do something similar for daily notes for work. I have a shell
| alias `tdw` for `TODO work` which opens a YYYY-MM.md file in vim.
| Inside of that markdown file I use a vim macro that generates a
| date similar to what is shown in calendar.txt, where I take notes
| about what I am working on and what I have worked on. Here's ane
| example of what it looks like: ## 2025-02-27
| W09 Thursday - Team standup - Looking up
| flights to Venus - Meeting with Acme - Discuss
| hydrocoptic marzlevanes - TODO: read up on them
| <http://example.com/docs/hydrocoptic-marzlevanes> -
| (personal) Feed the dragon - #5934 Fix glitch in dingle
| arm reciprocator
|
| I kind of like the calendar.txt idea of prefixing every line with
| the date, because it makes grepping easier, but at the same time,
| it doesn't allow for sub-lists and more detailed notes about what
| was worked on. It hasn't been a big enough problem to deal with
| though, because of things like `grep -i -B10 encabulator`
|
| The vim macro I use is: " Macro To Do Today
| nmap mtdt <esc>O<CR><esc>k"=strftime('## %F W%V
| %A')<CR>Pa<CR><CR>-
| setopt wrote:
| For people interested in non-Vim alternatives, Logseq and Org-
| mode both streamline a very similar workflow. (I'm one of those
| who eventually migrated from Vim to Emacs because of Org-mode,
| now combined with Howm-mode.)
| stavros wrote:
| I made a small utility to make this easier:
|
| https://pypi.org/project/dia/
| faxmeyourcode wrote:
| I've got something very similar as a function in my ~/.zshrc,
| except instead of days separated by lines I start a new file
| for each topic.
|
| Most of my notes are write-only for a day or so but I keep the
| old ones around just in case I need to grep through everything
| (and I've saved myself doing this a few times).
| function notes { THIS_MONTH="$(date '+%Y-%m')"
| mkdir -p "$NOTES_FOLDER/$THIS_MONTH" # create folder if it
| doesn't exist. cd "$NOTES_FOLDER/$THIS_MONTH"
| if [ -z "$1" ]; then return 0 fi
| vim $1 cd - }
|
| Running `notes` will take you to today's directory to poke
| around, and `notes file.md` will open file.md in the
| appropriate dir.
| hoherd wrote:
| I do something very similar for my public notes as well! I
| have `tn` to search for a note and open it in a browser, and
| `tne foo` to open my `foo.md` note in my editor, which in
| this case is not vim. I then commit them to git, where a
| post-commit hook uses mkdocs to build them, and gh-deploy to
| publish them EG https://danielhoherd.com/tech-notes/exiftool/
| is the output of my exiftool.md note.
| s0fasurfa wrote:
| Nice idea, but the calendar format is a bit verbose for my taste.
| Week number is something I would have to look up constantly and
| surely get wrong more than once.
|
| If you want to follow UNIX philosophy, why don't you write an
| augmenter/converter tool `caug` that adds "computed" information
| such as week number, weekday or even relative date?
| > cat calendar-src.txt 2025 ====
| 03-01 9-12 project groups > cat calendar-src.txt |
| caug 2025-03-01 w09 09:00-12:00 project groups +tomorrow
| +thisweek > cat calendar-src.txt | caug | grep
| "thisweek" 2025-03-01 w09 09:00-12:00 project groups
| +tomorrow +thisweek
| tero wrote:
| I use a template [1] that includes week numbers.
|
| With some traditional GUI calendar software, I was often
| hunting and miscopying week numbers. Some software also had a
| weird (non ISO-8601) idea of week numbers.
|
| In case you need calendar.txt after 2033, I wrote a small tool
| [2] to generate more templates.
|
| [1] https://terokarvinen.com/2021/calendar-txt/calendar-txt-
| unti...
|
| [2] https://terokarvinen.com/2021/calendar-txt/calendartxt-
| gener...
| listeria wrote:
| I also wrote a small tool to generate more templates, and it
| fits in a comment: usage: weeks YYYY-MM-DD
| YYYY-MM-DD weeks () { one_day=$((60 *
| 60 * 24)) unix_from=$(date +%s --date="$1")
| unix_to=$(date +%s --date="$2") while [
| $unix_from -lt $unix_to ] do echo
| @$unix_from unix_from=$((unix_from + one_day))
| done | date +'%F w%V %a' -f - unset -v
| one_day unix_from unix_to }
|
| seriously, what's a compressed 1.2MB small tool?
| danso wrote:
| That was my first thought too; I often use Google Sheets/Excel
| as a lightweight todo calendar, and I'll make formulas to
| calculate week-of-year and day-of-week. These lists are so
| lightweight and adhoc that having to do that kind of
| calculation would be enough friction to not maintain the lists
| after a short period
| 65 wrote:
| This seems like it'd be much more practical as a CSV file.
| kragen wrote:
| I've been doing this since 02001, except without the week
| numbers. I switched from CVS to Git around 02009.
|
| Anyone who knows me will tell you I am not very organized.
| Possibly this is why.
|
| Android support is definitely substandard, even with Termux.
|
| It's not foolproof. On one occasion I typed in the month wrong,
| though in the right place in the file. When I noticed that the
| line was out of order, I moved it to where the date said it
| should be. Arriving a month late, I discovered that the studio
| space I'd paid for no longer existed.
| Spare_account wrote:
| I like your future proof year numbering. Most current date
| formats are going to have a BIIG problem come the end of 9999
| but not you!
| jrm4 wrote:
| In the spirit of friendly competition; I gotta argue that
| Skroll's "Remind" supercedes this in every way. More flexible and
| more powerful.
| philsnow wrote:
| Absolutely agree. Remind has been around for literally decades
| and so has tons of user discussions that are easily searchable.
| janpot wrote:
| my dad keeps his calendar in an excel file with almost the exact
| same format except he omits dates with no entries. Every week he
| prints a new version of this on a single A4 which he folds and
| keeps in his wallet. new events are hand written at the bottom
| and get included in the excel weekly. he's been doing this for as
| long as I can remember.
| philsnow wrote:
| I love having the system-of-record being something powerful on
| a laptop, alongside having some paper artifact with just a
| small constrained view, which you update with a pencil and then
| reconcile with the SoR later.
|
| This is what I do for todos and reminders, with a few index
| cards binder-clipped together with a tiny pen. I use [0]; its
| size is right but it's just a ballpoint refill that isn't
| particularly great. Using it makes me miss my typical fine-tip
| gel pens. Anybody else use this kind of system and have a tiny
| pen to recommend?
|
| [0] https://www.amazon.com/dp/B0776LK634
| doenwe wrote:
| Is support for 2034 announced?
| BuildTheRobots wrote:
| Tangentially related, but the built-in Windows Notepad still to
| this day will append the current time and date to a file on
| opening, if the first line is ".LOG".
| gnabgib wrote:
| Or press <F5>
| doenwe wrote:
| Is support for 2034 on the calendar?
| tero wrote:
| Yes [1]. In the unlikely event you need a calendar after
| 2038-01-19 w03 Tue, the program can generate you templates [2]
| for hundreds of years [3].
|
| [1] https://terokarvinen.com/2021/calendar-txt/calendartxt-
| gener...
|
| [2] https://terokarvinen.com/2024/format-date-calendar-
| txt/dateg...
|
| [2] https://terokarvinen.com/2024/format-date-calendar-txt/
|
| Update: Added the template until 2400.
| p4bl0 wrote:
| I did something like this for _years_ before having to switch to
| an actual calendar app. A text calendar has a lot of advantages,
| like easily being able to have a list of the current and next
| days event displayed each time you open a terminal by putting the
| right call in your .bashrc :).
|
| My text calendar management script is still available here:
| https://code.up8.edu/pablo/myutils/-/blob/master/kal
| thesuitonym wrote:
| You make a good argument on why to use a plain text calendar, but
| not why you shouldn't use the `calendar(3)` format. I think this
| really speaks to the problem of discoverability that standard
| Unix tools have. A lot of problems have already been solved by
| those tools that are included on every BSD, every Mac OS
| computer, and most Linux distributions, but nobody knows about
| them, and there isn't really a good way to see what already
| exists. Sure, you could browse `/usr/bin` to see what's
| available, and I _guess_ that 's the Unix Way, but it's unwieldy.
|
| It would be cool if there were a crash course on this stuff, but
| even that wouldn't work well, because the first time you use a
| unixy system, it would be too much information to retain, and
| subsequent times you're likely to just gloss over all this stuff.
|
| Perhaps the only real solution is asking about what you want to
| do on messages boards, and hoping some weird old curmudgeon who
| is familiar with the small program you want to use sees your
| question.
| tero wrote:
| Based on the man page, calendar(3) would not suit my use well.
| It's quite different from calendar.txt. But I'm happy to hear
| that you use it.
|
| I installed it just to read the man page: """
| LANG=C Easter=Ostern
| #include <calendar.usholiday> #include
| <calendar.birthday> 6/15\tJune 15 (if
| ambiguous, will default to month/day). Jun.
| 15\tJune 15. 15 June\tJune 15.
| Thursday\tEvery Thursday. June\tEvery June 1st.
| 15 *\t15th of every month. May
| Sun+2\tsecond Sunday in May (Muttertag)
| 04/SunLast\tlast Sunday in April, \tsummer time
| in Europe Easter\tEaster
| Ostern-2\tGood Friday (2 days before Easter)
| Paskha\tOrthodox Easter
|
| """
| dingnuts wrote:
| >Perhaps the only real solution is asking about what you want
| to do on messages boards, and hoping some weird old curmudgeon
| who is familiar with the small program you want to use sees
| your question.
|
| I'm an AI curmudgeon in general but this is a place where LLMs
| really excel. You ask "how do I do x thing I want to do" and it
| either tells you, from the morass of docs it knows about, or it
| hallucinates and you find out ten seconds later when there's no
| man page for the command -- and then you fall back to
| traditional methods.
|
| Either the LLM gives you a discoverability shortcut, or you're
| back where you started, anyway.
___________________________________________________________________
(page generated 2025-02-28 23:01 UTC)