Live data from Hacker News

Write plain text files

sive.rs

401–410 of 425 posts

Re: Write plain text files

#401

Plain text adoption often implies markdown for a richer experience, but we also have the wonderful https://orgmode.org markup. There is no shortage of markdown-based tools on all platforms. Our org markup options, on the other hand, are very few outside of Emacs. Org markup itself is super versatile and can power lots of use-cases. I built two org-powered apps for iOS myself: https://plainorg.com https://flathabits.c…

I've been intensively using Orgmode for a year and a half (wrote my thesis in it) and then abandoned it to switch to Markdown. Orgmode quickly turns into not-quite-plaintext with humanly impossible to read and very distracting data structs stuck inside the text. I think these were called "Properties"? For me the beauty of plain-text is that it can be read and written in any Editor without needing syntax highlighting.…

The kind of “data-rich” org file you don’t like would presumably be impossible in markdown. So what are you gaining at all? Just don’t write such data-rich org files. That’s totally under your own control.

Re: Write plain text files

#402
post #274

Earlier quoted context omitted.

So when you need to remember a user/password combo for a new device, offline doorbell maybe, or a parcel number, or the address of a friend, then you record a 4K video instead of writing it in a text file? Plain text just works, everywhere, all the time.

> Plain text just works, everywhere, all the time. No it doesn't. Try a plain text description of an electronic circuit vs a circuit diagram. Try a a plain text instruction sheet vs an illustrated one. Try plain text sheet music vs actual sheet music. Try a mathematical plot vs plain text tables. Try concept drawings of product vs text descriptions. Try construction drawing vs plain text descriptions. I could go on a…

> Try a plain text description of an electronic circuit vs a circuit diagram.

It’s called a Hardware Description Language. According to my textbooks, they’re the industry standard. My personal experience certainly prefers them to unusable “diagram” drawing GUIs.

> Try a mathematical plot vs plain text tables.

You can do plots in unicode. And more importantly, the code that produces the plot is plain text.

Pretty much anything regular can be done better with a plain text source that subsequently compiles to more visual mediums.

Re: Write plain text files

#403
post #361

Earlier quoted context omitted.

You won’t be able to. See if you’d like Joplin or Simplenote. I still use Simplenote. Because even though FSNotes seems promising, it’s still not there.

but both of them store notes in a proprietary way, so if they shut down (or I just wanted to move), wouldn't it be harder to migrate off?

I use nvAlt for Simplenote on Mac where I chose to keep the file in text format in a Dropbox folder and it also sync to Simplenote server which easily makes the data available to mobile app. So Simplenote server does the sync between apps and since I keep the data in Dropbox folder the data is synced/backed up (I separately backup that folder as well) there as well.

(To be honest that works better for me than FSNotes' complicated way of doing this. I wish they had a way to do that in Mac app while still utilising invisible iCloud Sync; but without me having to specify a dozen places for storage, sync, external folder etc etc)

Joplin is FOSS. Format is not proprietary and it is easily readable and they also do a raw export https://joplinapp.org/help/#exporting

Re: Write plain text files

#404
post #279

Earlier quoted context omitted.

I tried to git my resume once upon a time. It's still something I'd love to finish doing, it just makes sense to have a git repository as a timeline of your life: https://github.com/ben174/bugben

I do the same by having my resume in latex which I’ve checked in to git. Been meaning to write a GH action to generate the pdf artifact automatically.

I've decided to migrate my CV to Markdown instead -- pandoc can dump to LaTeX, PDF, you name it.

Re: Write plain text files

#405

Earlier quoted context omitted.

The faithful are still on Roam. Others have moved to: 1. Obsidian: has bidirectional linking and knowledge graphs, is faster and better supported, but doesn't have the outlining structure that Roam is based on. 2. Logseq: basically an open source Roam with 90-95% feature parity and some cool stuff that is its own. 3. Foam/Dendron/Athens etc: Roam clones. 4. Notion/Evernote/something else entirely.

I don't think Dendron is a Roam clone. All notetaking apps of the new generation have certain similarities, but Dendron has a pretty different philosophy for how you should organize your notes. Roam's about the block within an outline, interlinking and transclusion. Dendron's core schtick is making traditional hierarchies easier to work with. Like, with Roam a feelings of power scenario would be queries getting you s…

Appreciate your input. I'll admit I haven't looked into Dendron as deeply.

Re: Write plain text files

#406

Earlier quoted context omitted.

I had no idea these options were a thing. Thank you for pointing them out, adding them to my config immediately and hoping it makes some merges and whatnot easier going forward.

Hint: rerere doesn't always work. It's still guesswork, like the rest of merges/rebases/cherry-picking in Git. This is because looking only at the tips of branches doesn't work, and that's the only thing Git can do (with or without diff3 as the merge algorithm).

The rerere database is content-addressed, and rerere will apply a resolution only if the pair of conflicting files is a bit-exact déjà-vu of a conflict it has seen before.

I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before.

The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution.

That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it.

I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.

Re: Write plain text files

#407
post #402
post #274

Earlier quoted context omitted.

> Plain text just works, everywhere, all the time. No it doesn't. Try a plain text description of an electronic circuit vs a circuit diagram. Try a a plain text instruction sheet vs an illustrated one. Try plain text sheet music vs actual sheet music. Try a mathematical plot vs plain text tables. Try concept drawings of product vs text descriptions. Try construction drawing vs plain text descriptions. I could go on a…

> Try a plain text description of an electronic circuit vs a circuit diagram. It’s called a Hardware Description Language. According to my textbooks, they’re the industry standard. My personal experience certainly prefers them to unusable “diagram” drawing GUIs. > Try a mathematical plot vs plain text tables. You can do plots in unicode. And more importantly, the code that produces the plot is plain text. Pretty much…

> It’s called a Hardware Description Language. According to my textbooks, they’re the industry standard

So when confronted with a faulty circuit board with multimeter in hand and bench power supply on stand-by, you are looking at VHDL like this

  Library ieee; 
  use ieee.std_logic_1164.all;
  
  entity mux is
     port(S1,S0,D0,D1,D2,D3:in bit; Y:out bit);
  end mux;
  
  architecture data of mux is
  begin 
     Y
to figure out which components might be broken when there's a buck converter that gets no power or where the capacitor is located that should smooth out incoming voltage on a certain bus. Yeah, sure.

> You can do plots in unicode. And more importantly, the code that produces the plot is plain text.

So you're one of those people who don't listen to electronic music and prefers to read the parameters of the VCAs, LFOs and VCFs instead? After all it's just code that produces the sound waves in the end, no?

> Pretty much anything regular can be done better with a plain text source that subsequently compiles to more visual mediums.

And again we're back to data storage vs representation. I'm interested in the representation, not the storage format.

If you're one of those geniuses that can squint at a quintic formula and say - yep, there's a local maximum at about x=-9.7513, more power to you. The rest of us prefer a curve.

Re: Write plain text files

#408

Is there a modern text editor that only supports ASCII, so I can take my plain text notes and store pages and pages of them in one or two KB?

Numerous modern editors support ASCII. There's no reason to want one to only support ASCII, and it certainly isn't required to deal with plain text notes.

Where do you store them now?

And 2 KB is 2 thousand characters ... "pages and pages" of notes sounds like more than that.

Re: Write plain text files

#409

I hate to be pedantic[1], but: > HTML, Markdown, JSON, LaTeX, and many other standard formats, are just plain text. On this definition, Word and Excel are just (zipped) plain text files. > Every device, including ones long gone, and ones not invented yet, can read and edit plain text. This definitely isn't true, and it kind of misses the point that there's no such thing as "plain text". It's still encoded in ascii, o…

Older Word (doc) and Excel (xls) files aren't "zipped" and aren't plain text files.

> This definitely isn't true

Yes, actually it is.

> and it kind of misses the point that there's no such thing as "plain text".

Who here made such a point? Anyway, that's not true either.

> It's still encoded in ascii, or utf-8

So, plain text files.

> and still potentially has problems being read on other machines.

What "other machines"? What problems? What matters is the software, not "machines".

> It's reasonable to say that ascii has become so ubiquitous as to be universal, but it definitely wasn't always so

I was alive when EBCDIC was common, but that isn't relevant.

> and won't definitely always be.

Sure, there's the heat death of the universe eventually.

Re: Write plain text files

#410

Earlier quoted context omitted.

> that there's no such thing as "plain text" Please show me a computing device that cannot deal with ASCII. And UTF-8 has, by now, reached a level of ubiquity that encompasses almost everything in IT as well.

indeed, why not use real plain text – not markdown. Homer was able to write the fall of troy and Shakespeare Hamlet without bold text. So what can't one express without?

Markdown is "real plain text".

Why not just use letters and avoid punctuation ... that's all Markdown is: punctuation.

> Homer was able to write the fall of troy and Shakespeare Hamlet without bold text.

Oh really? Have you ever seen a manuscript?

Unlike handwritten text, plain text doesn't provide a means to underline, use italics, subscripts and superscripts, etc. Things like Markdown provide conventions for denoting such things in plain text.

Post reply on HN