Live data from Hacker News

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

unsung.aresluna.org

111–120 of 172 posts

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

#111
post #8

The list at the top could be longer: - https://asciiflow.com/ - https://asciidraw.github.io/ Anybody know more?

https://github.com/TheoKVA/ascii-box-editor A visual editor of UTF-8 BOX DRAWING characters, contrary to "ascii" in the name. No server, no installation: browser-side Javascript only.

"ascii" for some means "anything textlike", so for example you may see roguelike game developers saying "nice ascii" in response to a screenshot full of CP437, Unicode, or text-like glyphs, all very much not ASCII. Some will get defensive when called out on this, claiming that CP437 is okay to call ascii because it's "extended ASCII" (nevermind the many different and conflicting extensions), or others point out that they do not have a better term for something textlike.

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

#112
post #86

Earlier quoted context omitted.

Yikes. That would lose the ability to know the meaning of the current bytes, or misinterpret them badly, if you happen to get one critical byte dropped or mangled in transmission. At least UTF-8 is self-syncing: if you end up starting to read in the middle of a non-rewindable stream whose beginning has already passed, you can identify the start of the next valid codepoint sequence unambiguously, and then end up being…

We've already lost all that with emojis and other characters in supplementary planes.

No, we haven't. You can start at any byte in a UTF-8 document and resume reading coherent text. If you start reading from the middle of a multi code point sequence, then the first couple of glyphs may be wrong, for example you may see a lone skin tone modifier rendered as a beige blob where the author intended a smiley face with that skin tone. But these multi code point sequences are short, and the garbled text is bounded to the rest of the multi code point sequence. The entire rest of the document will be perfectly readable.

Compare this to missing a code page indicator. It will garble the whole section until the next code page indicator, often the whole rest of the document. The fact that you're even comparing these two situations as if they're the same is frankly ridiculous.

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

#113
post #48
post #42

Earlier quoted context omitted.

Gnu plot dumb terminal mode?

That’s possible as well. I wish common terminals (the kind that is shipped with the OS) would do ReGIS, Tektronix, or even sixel (yuck!).

Thanks to all posts above for engaging with my quest for minitab style text character dotplots! Below is an example of what I'm on about (artisan construction in Mousepad) and apologies to anyone on a narrow screen where the text mode is going to get jumbled.

  0            .   .   . . . . . .    . .
 
  
  1                                     :     .:..       ..      .
    
                .
  2     .    ..::          ..
    --|-------|-------|-------|-------|-------|-------|-------|-----
     32      40      48      56      64      72      80      88 
The example is typed out from

https://support.minitab.com/en-us/minitab/help-and-how-to/gr...

The `plotrix` package for R looks hopeful (mentioned on one of the links kindly provided above) as it includes a 'minitab style dotplot' function.

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

#114
post #40
post #5

Couldn't help riffing off on a tangent from the title (since the article is about diagramming tools)... Dylan Beattie has a thought-provoking presentation for anyone who believes that "plain text" is a simple / solid substrate for computing: "There's no such thing as plain text" https://www.slideshare.net/slideshow/theres-no-such-thing-as... (you'll find many videos from different conferences)

I read that article long time ago, and for me it's a hard disagree. A system as complex and quirky as Unicode can never be considered "plain", and even today it is common for many apps that something Unicode-related breaks. ASCII is still the only text system that will really work well everywhere, which I consider a must for calling something plain text. And yes, ASCII means mostly limiting things to English but for…

I agree with you that Unicode is too complicated and messy, although it also shows that whether or not something is considered "plain" is itself too difficult.

Unicode has caused many problems (although it was common for m17n and i18n to be not working well before Unicode either). One problem is making some programs no longer 8-bit clean.

Unicode might be considered in two ways: (1) Unicode is an approximation of multiple other character sets, (2) All character sets are an encoding of a subset of Unicode. At best, if Unicode is used at all, it should be used as (1) (as a last resort), but it is too common for Unicode to be used as (2) (as a first resort), which is not good in my opinion.

(I mostly avoid Unicode in my software, although it is also often the case (and, in many (but not all) programs, should be the case) that it only cares about ASCII but does not prevent you from using any other character encodings that are compatible with ASCII.)

> ASCII is still the only text system that will really work well everywhere, which I consider a must for calling something plain text.

Yes, it does work well (almost) everywhere.

Supersets of ASCII are also common, including UTF-8, and PC character set, ISO 2022 (if ASCII is the initially selected G0 set, which it is in the ASN.1 Graphic string and General string types, as well in most terminal emulators), EUC-JP, etc. In these cases, ASCII will also usually work well.

However, as another comment mentions, and I agree with them, that if you mean "ASCII" then it is what you should say, rather than "plain text" which does not tell you what the character encoding is. That other comment says:

> Plain text is text intended to be interpreted as bytes that map simply to characters.

However, it is not always so clear and simple what "characters" is, depending on the character sets and what language you are writing. And then, there are also control characters, to be considered, so it is again not quite so "plain".

> And yes, ASCII means mostly limiting things to English but for many environments that's almost expected. I would even defend this not being a native English speaker myself.

In my opinion, it depends on the context and usage. One character set (regardless of which one it is) cannot be suitable for all purposes. However, for many purposes, ASCII is suitable (including C source code; you might put l10n in a separate file).

You should have proper m17n (in the contexts where it is appropriate, which is not necessarily all files), but Unicode is not a good way to do it.

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

#115
This and just use it instead of a .pdf.. stay libre make it work for all platforms of all ages and all over the world...

no rtf nothing needs to be fancy

a canonical .txt resource, is parseable and universal. Don't restrict your audience. For example:

If a repo has a .txt backup of some changelog it's therefore not tied to whatever platform.. The repo is a living project and memory.. don't assume anything: ( ie if for some reason your a/c is gone... that information is not lost its saved forever... )

usually if I must reference a pdf it means a browser.. And often I don't want a browser running..

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

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

Yes, I thought of what you mentioned too, and in my opinion, DER is a better format, and it is a binary format rather than text.

(In my ideas of an operating system design, there is a structured binary format (similar to DER but different) used for most files and data, so that the tools (and the command shell) would be usable consistently with most of them; and if some need special handling, you can use other programs and functions to convert them and/or handle them in a way that can be interoperable.)

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

#117
post #49

Earlier quoted context omitted.

But why? You easily have 4k pixels, why use a tiny subset of those in a very inefficient way? We have proper hardware to make a bunch of these computations actually fast, and yet we should stuck with drawing relatively expensive text everywhere? If you only care about the UX of TUIs, that I can stand behind (though mostly as a guideline, it doesn't fit every workflow), but you can do that with a proper GUI just as we…

You could double or quadruple the number of pixels, and it wouldn't make any difference in how much information humans comprehend easily. You would be using more computing power and more memory to deliver the same amount of useful information less efficiently. A "proper GUI" is rarely better than a well-designed TUI for communicating textual information, IMO. And the TUI constraints keep the failure-states for badly-…

What about a map, or an image? We can surely agree that humans can take in a lot more information than a readable letter-grid allows, depending on the type of information.

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

#118
post #49

Earlier quoted context omitted.

But why? You easily have 4k pixels, why use a tiny subset of those in a very inefficient way? We have proper hardware to make a bunch of these computations actually fast, and yet we should stuck with drawing relatively expensive text everywhere? If you only care about the UX of TUIs, that I can stand behind (though mostly as a guideline, it doesn't fit every workflow), but you can do that with a proper GUI just as we…

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?

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

#119
post #68

Earlier quoted context omitted.

The point is, a lot of work went into making that happen. I.e., plain text as it is today is not some inherent property of computing. It is a binary protocol and displaying text through fonts is also not a trivial matter. So my question is: what are we leaving on the table by over focusing on text? What about graphs and visual elements?

TUIs can include these, see the kitty graphics protocol, implemented by most if not all modern terminals. https://sw.kovidgoyal.net/kitty/graphics-protocol/

I was not very descriptive, but I was referring to the next layer up of building blocks. Instead of text, we could also express things in hybrid ways with text but also visual nodes that can carry more dense information. The usual response is that those things don't work with text-based tools, but that's my point. Text based tools needed invention and decades of refinement, and they're still not all that great.

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

#120
post #46

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.

XML arguably isn’t plain text, but a binary format: If you add/change the encoding declaration on the first line, the remaining bytes will be interpreted differently. Unless you process it as a function of its declared (or auto-detected, see below) encoding, you have to treat it as a binary file. In the absence of an encoding declaration, the encoding is in some cases detected automatically based on the first four by…

Another way that the character encoding could be declared is ISO 2022. When using ISO 2022, the declaration of UTF-8 is , rather than the that XML and some other formats use.

However, whether you do it that way or another way, I think that the encoding declaration should not be omitted unless it is purely ASCII in which case the encoding declaration should be omitted.

Post reply on HN