Live data from Hacker News

Plain text has been around for decades and it’s here to stay

unsung.aresluna.org

151–160 of 172 posts

Re: Plain text has been around for decades and it’s here to stay

#151
post #123

Earlier quoted context omitted.

> If you only care about the UX of TUIs, that I can stand behind This is a confusing concession. Of course we love TUIs because of the UX, what other reason is there? Constraint breeds consistency and consistency breeds coherence. Take 1,000 random TUI designers and 1,000 random GUI designers and plot the variations between them (use any method you like)—the TUI designers will be more tightly clustered together becau…

> Constraint breeds consistency and consistency breeds coherence. In principle I would agree, but there are plenty of bad citizens among TUIs, it's absolutely not true that you can just start using one. The same way there are excellent GUI applications like blender or intellij.

I'm sorry, excellent GUI with Blender? With the 2.5 interface things were ass backwards but you had a bunch of stuff you could do with only the mouse. With the 2.8 interface suddenly a bunch of stuff was hidden behind arcane key combinations, options disabled by default, and the loss of important visual data like the bounding box view and having both the UV and cursor coordinates in the same tab in the UV/image editor. No matter what the controls are different with every sub-window type, and interface panels flip from top to bottom and left to right for best readability without thought spared for consistency. There's a reason why someone can learn FL Studio in a few weeks, but take months or even over a year to become competent in Blender. I love it's jank and have been using it for eleven years, but I would never call the UI more than serviceable.

Re: Plain text has been around for decades and it’s here to stay

#152
post #141

Earlier quoted context omitted.

> A file isn't meaningful unless you know how to interpret it; that will always be true. There are multiple levels of meaning, though; character encoding is just one part of it. For example, a text file might be plain text, or HTML, or JSON, or a C source code, etc; a binary file might be DER, or IFF, or ZIP, etc; and then there will be e.g. what kind of data a JSON or DER or IFF contains and how that level of the da…

> ... (although I think UTF-8 should not be used for Japanese either) ... The people putting up websites in Japanese disagree with you, it would seem. According to Wikipedia (in the Shift JIS article), as of March 2026 99% of websites in the .jp domain were in UTF-8, with only 1% being in Shift JIS. Japan used to have two different encodings in common use, Shift JIS (usually used on Windows) and EUC-JP (more common o…

If they are misinterpreted, it is because the character encoding is not declared properly.

I still sometimes see mojibake in Japanese web pages, but sometimes it works; if it works, it is because the character encoding is declared properly.

In my opinion, EUC-JP is a generally better encoding of JIS (especially in e.g. C source code, which should not use Shift-JIS but EUC-JP is OK), but Shift-JIS does have some benefits in some circumstances (such as making a character grid with one byte per character cell; if using Shift-JIS for a Pascal source code then you should use (* *) instead of { } for comments please).

Re: Plain text has been around for decades and it’s here to stay

#153
post #144

It's fun to see a plaintext accounting view as the example... I just switched from QuickBooks to Beancount+Fava for my sole proprietorship, and couldn't be happier. I've added a text-based simple invoice system, a text-based vehicle mileage tracker, and have validators that ensure that every expense with a tax status has a document attached to it. It's far easier and faster to use than QuickBooks, I don't have to put…

Thanks for mentioning Beancount; I didn't know about it before. I'm American but have a job in a different country, so I deal with two currencies routinely, and haven't found a good way of handling multiple currencies in Gnucash. So my wife and I have been keeping our records in text files. I'll look into what it would take to switch over to Beancount; I bet I could write a conversion script (or get an LLM to write m…

One small warning about Beancount: v3 is a huge change from v2, and a lot of the documentation on the web is in v2 and it's not clearly demarcated that it doesn't apply anymore.

I'd recommend looking up information with an LLM, and not trusting web pages. This is the first time I've made such an unusual suggestion, but LLMs are actua really good at information retrieval and translation. The Beancount community has a bit of cleaning up to do before web searches can be trusted again.

That said, Fava is such a huge step up from the hledger web ui that it's totally worth it, especially since I want quick and easy attachment of documents and viewing of documents. It's super easy to convert between hledger/ledger and beancount formats, so it's fairly easy to switch to the other if you already have your data in such clear and clean formats.

Re: Plain text has been around for decades and it’s here to stay

#154
post #21

Earlier quoted context omitted.

XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown... Plenty of plaintext, but structured information formats that are "yes, and". Yes, I can process them as lines of plain text, and I can do structured data transformations on them too, and there are clients (or readers) that know how to render them in WYSIWYG style.

If that’s our definition of “plain text”, sure. I would still rather our tools were more advanced, such that printable and non-printable formats were on a more equal footing, though. I always process structured formats through something that understands the structure, if I can, so I feel that the only benefit I regularly get out of formats being printable is that I have to use tools that only cope with printable form…

Hm, you made me think about non-printing characters as metadata, which is of course immediately lost on printing and therefore does not round trip between digital and printed versions.

Many nonprinting characters imply some directive; line break (hard-wrap the text here, but this is not a paragraph), page break (let the rest of the page be blank, start the next paragraph overleaf), EOL (file over, bye bye), nonbreaking space (keep these two words together, always, till death do them part).

This is out-of-band information spliced in-band (with the text corpus), which a computer program can "see", but a person can't.

Re: Plain text has been around for decades and it’s here to stay

#155
post #33

Earlier quoted context omitted.

UTF-8 does not encode "European glyphs" in two bytes, no. Most European languages use variations of the latin alphabet, meaning most glyphs in European languages use the 1-byte ASCII subset of UTF-8. The occasional non-ASCII glyph becomes two bytes, that's correct, but that's a much smaller bloat than what you imply. Anyway, what are you comparing it to, what is your preferred alternative? Do you prefer using code pa…

Unicode could have just been encoded statefuly with a "current code page" mark byte. With UTF and emojis we can't have random access to characters anyways, so why not go the whole way?

Unicode had support for language tag codepoints. They still exist but have long been deprecated. They were intended to deal with glyph variants, especially with regards to Han unification.

Re: Plain text has been around for decades and it’s here to stay

#156

Earlier quoted context omitted.

Sure you can: data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH hhx4dbgYKAAA7 from: https:/…

You cannot send your photo in color though.

[deleted]

Re: Plain text has been around for decades and it’s here to stay

#157

Earlier quoted context omitted.

Sure you can: data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH hhx4dbgYKAAA7 from: https:/…

You cannot send your photo in color though.

Of course you can. You can convert any image to base64.

Re: Plain text has been around for decades and it’s here to stay

#158
post #141

Earlier quoted context omitted.

> ... (although I think UTF-8 should not be used for Japanese either) ... The people putting up websites in Japanese disagree with you, it would seem. According to Wikipedia (in the Shift JIS article), as of March 2026 99% of websites in the .jp domain were in UTF-8, with only 1% being in Shift JIS. Japan used to have two different encodings in common use, Shift JIS (usually used on Windows) and EUC-JP (more common o…

If they are misinterpreted, it is because the character encoding is not declared properly. I still sometimes see mojibake in Japanese web pages, but sometimes it works; if it works, it is because the character encoding is declared properly. In my opinion, EUC-JP is a generally better encoding of JIS (especially in e.g. C source code, which should not use Shift-JIS but EUC-JP is OK), but Shift-JIS does have some benef…

> If they are misinterpreted, it is because the character encoding is not declared properly.

OR because the software is buggy, or making assumptions about encoding and not checking them (which also counts as "buggy", of course). You can declare the encoding all you like, it won't protect you against the stupid decisions that other people make in writing their software. (See Excel, for example).

Yes, if you declare your encoding properly, things should work. Most of the time. And if you're using any encoding that is not the worldwide default (which these days is UTF-8), then you definitely should declare the encoding. But you'll still occasionally hit badly-written software that doesn't even think about other encodings and doesn't handle them properly. The only defense against that situation, where you declare your encoding properly and it still doesn't work, is to just use the encoding that the software was written to expect, which is almost certainly the worldwide default.

Re: Plain text has been around for decades and it’s here to stay

#159
post #118

Earlier quoted context omitted.

One of TUI advantages over GUIs (including modern web sites) - all text can be selected/copied (you may need to use modifies in some TUI). It's a bit frustrating when GUI shows text but I cannot select and copy it.

Is that always beneficial? Do you ever want to select the text of a confirm button? What if it just popped on top in a dialog to the content you were about to select?

It's not only about buttons. A web-app of trading platform I use doesn't allow to copy-paste a fund name (both in web and in the mobile app). I don't think they disallow this intentionally, likely an artefact of GUI framework they use.

Re: Plain text has been around for decades and it’s here to stay

#160

Earlier quoted context omitted.

* L a u g h s i n u t f 1 6 *

That’s cool ! How did you do that ?

Manually, with spaces. Ironically each actual space took 3 spaces, which HN truncated to one space removing any concept of words. Technically this is incorrect because a real post would be 0x00 and not 0x20, but my point was even ‘basic’ text can be problematic if you’re not aware of encoding types, and it can really fukin bite if you’re not ready for it.
Post reply on HN