Live data from Hacker News

Calendar.txt

terokarvinen.com

111–120 of 143 posts

Re: Calendar.txt

#111
post #60

Earlier quoted context omitted.

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.

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 "Möbius Sync" not actually syncing in the background. It's annoyi…

It is much better on Android

Re: Calendar.txt

#112
post #21

Emacs got you covered, my friend, no reason to reinvent the wheel: https://www.gnu.org/software/emacs/manual/html_node/emacs/Fo...

The diary is fine, but have you seen org-mode?

Re: Calendar.txt

#113
post #82

Earlier quoted context omitted.

Just a hard to guess one. Like using UUID or things.

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..

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.

Re: Calendar.txt

#114
post #70
post #68

Earlier quoted context omitted.

> 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/

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?

Not marttt, but I'm a big fan of beancount after using it for the past few years for my company's books. Recycling an old comment of mine that might be helpful: https://news.ycombinator.com/item?id=37937942 (more upthread from that as well)

Re: Calendar.txt

#115
post #91

Earlier quoted context omitted.

> 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?

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.

There's also cli access to Keep. And Google keeps on improving integration of mail,calendar,tasks and keep.

Re: Calendar.txt

#116
post #91

Earlier quoted context omitted.

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.

There's also cli access to Keep. And Google keeps on improving integration of mail,calendar,tasks and keep.

cli access to keep --> no its unofficial api gkeepapi would not trust with my gmail credentials

Though limited android keep app has one simple intent using which i create all my notes

Re: Calendar.txt

#117
Cool but how do I share events with my family and coworkers so we are on the same page?

The point of calendars is to align with other people’s lives

Re: Calendar.txt

#118
post #105

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 s…

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 #include 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…

Very recently, I tried using a combination of nail(1), and calendar(1) on OpenBSD as an email and calendaring combination for home use. "nail" is provided by the OpenBSD s-nail package and provides an extended POSIX mailx style environment. calendar(1) is part of the base OpenBSD distribution.

It worked far better than expected. The only thing missed was age calculations for birthdays. I never figured that out. Using the Emacs Diary provided that sort of thing though.

I've since moved to KDE Kontact for mail/calendaring. It works more smoothly if you do a lot of calendar sharing with others, but I could see going back to nail(1)/calendar(1) if Kontact disappoints.

Re: Calendar.txt

#119

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 categori…

Would love to see the code for this! Do you have it available?

Re: Calendar.txt

#120
post #70
post #68

Earlier quoted context omitted.

> 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/

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?

FWIW, I'm a single-person company with a tiny turnover and only a handful of expense categories. I've used ledger-cli for many years, but at one point, I started to migrate my data to pta [1]. The reason was that in my country (Europe), all reporting seems to implicitly rely on a numbered chart of accounts (something like "101 Cash", "201 Accounts payable" etc), and the journal format of ledger-cli is not built around this idea by default.

pta, however, does this numbering [2], so for filing taxes in my country, its journal format seems more straightforward in case auditors should have any interest in it. I also quite like its terseness (1 transaction = often 1 line, as compared to 3 in a ledger-cli journal -- gives a better overview and is somewhat better to parse further with sed or awk when needed [3]). Finally, it is a single Perl script, thus very portable and lightweight.

All that said, pta doesn't seem to have much of a following, as compared to ledger-cli, which, obviously, is a much more mature project.

There was also an interesting discussion regarding pta vs ledger, involving the author, OpenBSD dev Ingo Schwarze [4] -- well worth a read regarding the general plain text accounting philosophy also. Interesting stuff.

1: https://mandoc.bsd.lv/pta/

2: https://cvsweb.bsd.lv/pta/accounts.example.en?rev=1.3&conten...

3: https://cvsweb.bsd.lv/~checkout~/pta/journal.example.en?rev=...

4: https://www.undeadly.org/cgi?action=article;sid=202009281234...

Post reply on HN