Live data from Hacker News

Calendar.txt

terokarvinen.com

101–110 of 143 posts

Re: Calendar.txt

#101
post #69

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

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.

Re: Calendar.txt

#102
post #82
post #80

Earlier quoted context omitted.

Could you elaborate on the "hidden URL"?

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

Re: Calendar.txt

#103
post #43

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.

Programming languages are substantially more complex than text or lists but are edited as text.

Re: Calendar.txt

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

Re: Calendar.txt

#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 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
"""

Re: Calendar.txt

#106

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…

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

Re: Calendar.txt

#107
post #73

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

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…

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?

Re: Calendar.txt

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

todo.txt accomplished this with community apps that provided web and mobile interfaces to the text file: http://todotxt.org/

Yeah, simpletask

Re: Calendar.txt

#109
post #69

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

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

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.

Re: Calendar.txt

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

If you like this you might like org-mode
Post reply on HN