Hacker News Reader

Comment by superkuh | Hacker News Reader

A flat text file. I will never again use anything proprietary or even non-human readable. A single text file combined with search does everything. If you require multimedia then just put the path to where it is on disk as text.

View on HN

I totally understand avoiding proprietary formats, but why write off non-human readable formats? I've been using sqlite for things like this. I figure sqlite is not going anywhere. And in the worst case scenario, if for some reason the software I use to interact with the sqlite db was no longer tenable, I could easily dump my data out of it into a text file.

How is your database structured? One table for everything? Something fancy? How do you use it?

Nothing too fancy, the skeleton of the schema is basically just:

    Tags(tag_id, tag_name)
    Files(file_id, file_address)
    FileTags(file_id,tag_id)

That's for organizing files using tags. I can organize notes like this by either putting notes into many text files and tagging them, or by putting notes directly into the DB with another Notes table. I've prioritized the former, since many of my "notes" are actually photographs of whiteboards or other non-text data. Storing textual notes directly in the sqlite database works well too though.

To interact with the system, I threw together a quick emacs client and a GUI client. Nothing fancy or pretty yet, but functional enough for my day-to-day use.

Bit flips and other errors kill or make non-flat formats only non-trivally accessible. Anything requiring programatic interpretation is fragile.

I use a notes directory with multiple flat text files named in some brief but sensible way.

I alias a command ('showNotes') to open the directory in sublime and use sublime's search to search my text files or edit/add files as appropriate.

I use to just stick to plain text and code snippets but have started using markdown for newer notes.

Same here. I've been using a 'notes' file since I first got into Unix back in the late 80s. I've kept with it ever since. I still haven't found something I like better. So portable, easily searchable and easy to manipulate with standard unix tools, etc.

Do you use a mobile device to edit? How? That always seems to be my sticking point with text based methods. It’s not easy to modify with my phone.

Not only that - how do you do structure? I'm especially thinking about trees here, which is how most concepts seem to be presented the best.

I store my text notes on Dropbox, using various subfolder layers. The android app allows both creation and editing of .txt files.

I self host Seafile. It has a simple and markdown friendly editor in its mobile app.

How is text not easy to modify on your phone? If anything this is a problem with phones being terrible computers and not text files. But I don't see how anything I said about how I do it on a desktop computer does not apply also to phones.

Plus the version control ^^

I'm using org-mode's link functionality to maintain a simple multi-file text wiki. I'm not an org-mode wizard, so I'm probably not using all the functionality available in org-mode, but it's enough for me.

It won't work for some. I often need to remember charts, pictures, maps... I need a visual nudge or hint to quickly scan thing. I can't tag/annotate everything all the time.

> never again use anything proprietary or even non-human readable

100% agree with this. I have settled on a very lightly (headers and lists) formatted markdown file. I like how I can just click on bookmarked link from the rendered HTML file to load in the browser (vs. copy paste from text files).

I did write a script to parse this file to mark broken (non 200 response code) links but forgot about it till now. Time to fire it up again.

do you edit the file on tablets/phones too? how do you handle multimedia on those devices?

I'm in the same boat, but would be on the market for a lightweight tool that searches for hashtags in the file

Every text editor has search. Tags are just words. If you put the text into the text file it is automatically a searchable "tag". If you want you can put some markup around it but it's really not needed.

fair point

only thing I can think of that I'd want that grepping doesn't provide is some ability to define multiline sections that get captured in a search

I mean, grep will find content in those sections but won’t be limited to those.

To limit it, if you devote the first 3 lines to title, summary, tags

You could extract the first 3 lines of each file and grep those.

If not, if they have a prefix,

    title: 
    summary:
    tags:

You could grep those first then grep the output.

    grep -E ‘title:|summary:|tags:’ | grep ‘query’

A simple script can be built.

What about `grep` ?

Reply on news.ycombinator.com