Hacker News new | past | comments | ask | show | jobs | submit login
This is a regular text file. People will read it. Maybe. (slopjong.de)
88 points by blinry on June 23, 2013 | hide | past | web | favorite | 68 comments

Nice, I like text files. Paragraph width is a little too wide for me, however.

I assume you made the line breaks manually, but it IMHO looks better if you let a decent algorithm do it.

Most Unix systems should have fmt, but par is better. If you are a vim user, just hit gqip inside of every paragraph.

The manual of par [1] has an example that shows the superiority of a dynamic programming algorithm (par, TeX) over a greedy algorithm (fmt, aprox. format manually).

[1] http://www.nicemice.net/par/par-doc.var

> Nice, I like text files. Paragraph width is a little too wide for me, however.

This is why we need markup languages like HTML. Inevitably people will want different widths paragraphs due to different devices, preferences, etc. Just because some people use HTML badly doesn't mean we need to go back to text.

Ideal paragraph width is not a function of device display size. A line of text should contain about 12 words, give or take. Long enough to not feel choppy but short enough to not feel like a "wall of text."

Deviate too much from this and readability suffers.

Edit: adequate whitespace in the margins is important too.

Because HTML is the only way you can have variable paragraph width?

Of course not. You could write it in RTF.

You could write it in plain text and only have line breaks when fitting a new paragraph, leaving it up to the user's software to wrap the lines.

But it wouldn't handle indentation properly, unless you define a standard formatting convention similar to Markdown. For example, you need to handle bullet points. But what if a plain, non-indented text just happens to contain a star at the start of a line? This means headaches for text writers to avoid these edge cases, and wrong indentation when viewing legacy texts.

Also, all viewers would have to support it, which somewhat defeats the purpose of using plain text.

> But it wouldn't handle indentation properly

8 spaces is fine.

> For example, you need to handle bullet points.

Asterisks are fine.

> Also, all viewers would have to support it, which somewhat defeats the purpose of using plain text.

I think that you're over thinking what plain text is. I don't mean "plain text with some additions". I really do just mean plain text.

> 8 spaces is fine.

I'm not talking tab characters, I'm talking indentation of whole paragraphs with plain spaces, as seen in the article. Most existing viewers just wrap long lines so that the wrapped content is unindented: this makes any indentation hard to notice and mostly useless. For your proposition to be viable, viewing software has to detect indentation and keep that indentation in wrapped lines.

> Asterisks are fine.

Ok, but usually you want to indent the wrapped contents by 2 columns otherwise asterisks become hard to notice. This is only possible with special magic in the viewer.

  I'm not talking tab characters, I'm talking indentation of whole paragraphs
  with plain spaces, as seen in the article.
  Ah, okay. You're right, indenting an entire paragraph is hard.
  This is the kind of thing they'd do on Usenet.
  All you get is a very verbose markup language :-)
  --- END MESSAGE ---

> I'm not talking tab characters, I'm talking indentation of whole paragraphs with plain spaces, as seen in the article.

Ah, okay. You're right, indenting an entire paragraph is hard.


This is the kind of thing they'd do on Usenet.


Sometimes there is no replacement for just a big honking array of ASCII.

This is the best solution, because you never know how large the text will be when rendered by the user's software. For example, this is how it rendered on my iPad:


It looks terrible, and I didn't read it, effectively falsifying the article.

People who want to modify paragraph widths and mess with the designer's vision are why we need PDF.

As a European designer who hates the fact that so many PDFs are in US letter format: fuck designers.

You Europeans have things too easy with your metric paper sizes and sales tax included in displayed prices and standardized road signage and drinkable beer and functional healthcare systems. We'll stick with PDFs, and fluid ounces, and trying to calculate 18% of pretax dinner tabs thanks. Excuse me while I go fight with my health insurance company over my last doctor bill.

If you're implying that the US doesn't produce drinkable beer, I'd humbly suggest you're going to the wrong bars :).

It's true that the beer situation in the US is just fine these days.

I'd say it's more than fine. I just spent three weeks in Europe and I was underwhelmed by the beer everywhere except Munich, Berlin, and Copenhagen (Mikeller was great). Foreigners seem to think of American beer as PBR, Bud Light, Miller, etc... and they have a good reason to--it's what most Americans drink.

But the strong microbrew renaissance going on right now is producing some of my favorite beers. Beers with the same depth and complexity as the finest of wines--he said, opinionatedly.

Now, I've learned that this experimental attitude towards beer is highly American. I don't think I've seen anywhere else in the world, except maybe Belgium, that is quite as crazy and experimental with what they put in their beers. After all, who in their right minds would like sour beers?

If you think the beer situation in the US is poor try out some Russian River, Boulevard, or Elysian brews and come back to me.

As a Dutch man, I think our beer is highly overrated. Belgian and German beers are great though.

Do i really need to explicitly flag my remark as sarcastic? Apparently so.

Or just use

     nano -W --fill=65 filename.txt
to start with.

I like the playfulness of these pages (the original and this parody) and I hope both authors achieve their aims.

The worst thing isn't that it's too wide but that the line length is inconsistent.

Call me rough, but I still wrap my papers with fold.

M-x autofill-mode

gggqG - wraps the entire document

Good call, but it does violence to the ASCII creature:-(

That's why I suggested gqip on every paragraph, but I'm sure there are more efficient ways.

Could you place the cursor just above the ASCII art and then wrap from there to the top of the document?

For that, you could place the cursor above the ASCII art; press (ma) to set marker 'a'; (gg) to go to the top; (gq`a) to wrap until marker a. ;)

gqG also does violence to some plain-text formatting, such as numbered lists or other short sections in which a specified line length or presentation is preferred.

Long lines and wrapping within the text viewer is probably your best bet.

Ah, I do see your point!

Why three g's at the beginning?

(g) invokes extra commands. here two are used: (gg) places the cursor at the top. (gq) wraps the text until (G) the end of the document.

This made me laugh harder than it should have. Or maybe it was just really good, I am not sure yet. Either way, thanks. I had a slightly cranky response to that other thread I never typed, and enjoying this instead is much better.

And yes, some people read that stuff. Though I would rather read something silly that is honest, than something that ultimately tries to sell me something. Which reminds me of this! http://textfiles.com/directory.html <-- Anyone remember spending hours being fascinated by that as a teenager? Text files are the best files.

This is how I basically keep notes on assorted topics like bash.txt, vi.txt, postfix.txt, etc :)

Does anyone know of an easy way to improve the readability of raw text files in the browser? I'm writing a novel using github and the raw text file output looks very ugly in the browser, even using things like readability [1].

It's easy to convert a static text file into something more readable, but I can't seem to find a solution for a dynamic text file at a static address.

[1] http://readability.com/

Make sure your text files are readable in the first place (line length, paragraph length, etc.).

Chose a readable font. Text files are shown with the browser default monospace font, but you change it to whatever you like best.

I think there is not much else you can do with raw text files in the browser. The next level would be to write in something like markdown and view the processed text, I think.

I've been trying to avoid adding manual line breaks to the text file because in prose, unlike code or poetry, line breaks are presentation, not content.

I suppose I could try to write something that scrapes the text file, adds <p> tags around paragraphs and presents it with some really basic CSS. I don't know how to code, but I might try cobbling something together.

You could alternatively use an online markdown editor (such as http://markdown.pioul.fr/). It'll wrap your paragraphs in <p> tags.

Additionally, since it uses the Markdown syntax, it might give you more than paragraphs if you use more than line breaks. (Have a look at the quick reference for more about the syntax.)

Edit: Didn't see your answer to @kybernetikos. I still think this could help you out. Also note that in HTML (what you'll get by adding <p> tags to your text), whitespace is collapsed (except inside <pre> tags)

Good point.

Instead of writing a converter yourself you could try to use Markdown on your files without modification and see how well it does. The design goal of Markdown is:

    Markdown allows you to write using an easy-to-read,   
    easy-to-write plain text format, then convert it to 
    structurally valid XHTML (or HTML). 
There is also AsciiDoc and some others.

Firefox styles plain text as 'pre' elements, so you can apply CSS using javascript, like as a bookmarklet:


The styling applied there really clashes with the explicit breaks in the story text. Anyway, that gets you down to one click each time you want to review the text file, which is maybe still more than you want.

Interesting, thanks.

Create a gh-pages branch for your content, and make an _layouts folder. Then put something like this inside it: https://github.com/Shikaga/story/blob/gh-pages/_layouts/main...

Now write your novel in markdown in an index.md file. Every time you check in github will render a nice html file for you that's easy to read, but your source remains easy to write and diff since it's just markdown.

This is an interesting approach, but markdown strips whitespace which could be problematic with some forms of indentation (for dialogue, etc.)

Might still be worth it though. Thanks.

What sort of indentation do you want? Markdown allows pre-formatted text for code and the like. http://daringfireball.net/projects/markdown/syntax#precode

I had exactly that problem, although use of text-indent in the css meant that every paragraph starts indented, so you just make each line of dialogue a new paragraph and it works out ok. So yes, it's not ideal, but it's still pretty good.

1: http://readable.tastefulwords.com/

2: Replace the monospace font with a non-monospace font one

3: Tweak other settings until you have the typesetting you prefer

4: save as bookmarklet specifically for formatting raw text


I think this is a bridge too far. Justin Jackson made a good point about approaching your content first etc, but stripping back to just plain text just makes this harder to read. In fact, if you've read the first post http://justinjackson.ca/words.html, I'd argue that this almost impossible to read through to the end without skipping. Which sort of dilutes the whole point...

Perhaps the post should read:

This is a regular text file. Nothing advanced and not much to see here but some words. And you're pretty sure you've read this already, quite recently in fact...


You're probably not even reading this bit, as most of you will have elected to skip to the end only to find I'm plugging something.

Now that's amazing...

The whole point is that it /is/ hard to read. That it isn't just about content, but how that content is presented.

> All these people didn't manage to get the driver compiled and installed, one cause surely was that the readme author didn't care about how to present the content at all. He just cared about functionality.

> If a client wants to get something done, I'd like to challenge you to think about user expierence (UX). If you want to sell products you will have more success with some good designs and layouts.

By taking it to an exteme of just a text file they're demonstrating that to communicate the content you need to present it effectively, and nice fancy layouts help with that.

I think I was conflicted over the idea of making a point by making said point hard to read. But to be fair, since I last read the text file, the width has been fixed up, which has... made it much easier to read (the original was full width lines). If it had originally been presented in it's current format, I would have never made my comment.

> In fact, if you've read the first post http://justinjackson.ca/words.html, I'd argue that this almost impossible to read through to the end without skipping.

That's interesting: I saw the plaintext version first, which I had no problem reading. But in the HTML version, the fact that all bold sentences are pretty mundane and the excessive use of italic and bold just made me want to skip the whole page. In fact I didn't even notice it was the same content until I went back to your post!

My instant thought is that the bold headings draw the eye away from the bit you are currently reading.

"You" read the first heading, and decide to read the plain text below. As you are reading that, your eyes notice another heading below what you are reading, and if the paragraph you are currently reading is not holding your attention enough, the next heading gets your attention. Your eyes then leave the paragraph you are currently reading because the heading below it now has your attention. So, you start on the next paragraph and the whole thing loops as you go down the page.

So, I would suggest that one should use headings and attention grabbers as little as possible, make the paragraphs worth reading, and try to get the message of the paragraph across in the first sentence or two.

Does that work?

The plain text file has been fixed up since I made my comment. I agree, the plain text file is now quite easy to read, making my snarky comment look quite silly... :)

I don't think not using a CMS was Justin Jackson's point: his core point was that content is king - design can come later, it's a distraction before your content is written. You can easily use a CMS with a very lightweight template.

Plain text can be readable too: you can keep it to 72 columns like the RFCs.

When referring to the post that inspired it, it would have been useful to take advantage ad some kind of technology that, let's say, allowed me to click with my mouse on that link you wrote and be magically transported there.

>I wrote this in a text editor. It's 4.9 KB.

That's 0.9 KB too large for a 4K demo.

Love this (assuming it's satire). I think there is a bit of group think on HN lately.

Sometimes, we have a highly up voted UX article that tells us users "can't read" so we should not rely on text.

At other times, we have this highly up voted manifesto that tells us we should focus more on text.

Am I the only one to see a contradiction?

PS: I do think text/plain HTML files are great (in some cases).

If you look carefully, this dilemma exists in all forms of creative work.

Say I'm creating a piece of electronic music, do I start working on the bare melody on a piano first or do I start with picking voice textures that blend well together? Both can be exciting to work on and both can lead to great songs. Just two different points of entry. Two different layers of abstraction.

This is extensible to almost any type of creative work that I know of, and I think people who regularly create things have tried at least a few of these points of entry in their creation process.

For me, if I want to narrow down my focus, I go with the piano, the pen, the text editor – black and white, minimum degree of freedom. Otherwise, I start by finding two or more voices/tones/shapes/colors that go/interact well together and focus on the overall experience instead.

Looks awful on an iPhone due to the manual line breaks. If your goal was to let your words speak for themselves, you failed -- I was so distracted by the jagged text I couldn't make it to the end.

Made me laugh. Thanks. :)

It's time for someone to step up and write an article that says the conscious choice of tools (or medium) most adequate for the particular problem is what really matters.

Someone please do a snarky markdown one next.

Or maybe an HTML5 or PURE CSS or asm.js?

Is that you Mark McCahill?

cat this_is_a_regular_text_file.txt | morse

Useless use of cat!


Someone should make .jpg file with nice typography saying:"This is an image. Not much to see, but you are starring at it anyway..." - Instant first page of HN :)

Different guy, written because of that previous webpage http://justinjackson.ca/words.html

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact