Previously:

https://news.ycombinator.com/item?id=21601600

https://news.ycombinator.com/item?id=18125167

The lack of attention to (or, rather, the complete disregard of) proper capitalization is ridiculous. This is the second post I'm seeing in two days that feature this "style". Quite a disturbing trend, if you ask me.

What is ridiculous and disturbing about using lowercase letters at the beginning of your sentences? In a world where this trend continues your eye will become used to it and it will no longer be a distracting shock from what your eye is used to.

For one thing, when the text resumes after an image or quotation, you can't (easily) tell if it's the beginning of a sentence or not.

If this is your argument supporting this trend, then I'm speechless ...

If the author otherwise (that is, first word capitalization issue aside) writes grammatically better than >99% of other internet writers, I submit that you can grant them this one shred of self-expressive style. Goes pretty well with the terminal user theme, to boot.

It's pretty clear she pays mind to grammar and cares about its proper usage more than most.

I did not say anything about grammar or even punctuation (in general). I have voiced a specific concern of a complete disregard of a proper capitalization. If you call it a "self-expressive style", well, it is your opinion and, of course, you are as entitled to one as everyone else. However, I highly doubt that most people would agree with your characterization of this as a "style". I welcome diversity of self-expression, but I would expect it to be in the form of writing itself (content and/or writing style) and/or visual aids (images), but not in ignoring expected traditional punctuation. BTW, the issue here includes lack of capitalization not only for the first word in a sentence, but also for the pronoun "I".

Well, I find it to pretty obviously be a self-expressive style, given the rest of its "form of writing itself (content and/or writing style) and/or visual aids (images)."

I could be wrong. Oh, well.

You might not have brought them up, but I largely (if not only ever) make the criticism regarding capitalization within contexts concerning grammar/punctuation or conveyance. And, given everything else in the article, I think it conveys pretty all right :)

This issue is not about conveyance, but rather about readability. As simple as that. So, let's agree to disagree. :-)

I'm of the opinion that there is much overlap between them. If I can have that (the opinion that is, not the concession on your part), then I accept.

I think that you and I are talking about different "readabilities". Yours implies a capability to effectively convey conceptual meaning, whereas mine (in this context) implies UX-focused - that is, purely visual - readability of the text at hand. I hope that this clarifies the source of our presumably different opinions.

I had considered both, as I think they considerably overlap (e: in this case, at least). In fact, if you want to want to completely isolate the two, I had mainly considered the UX-focused and visual aspect.

Contending over the ultimate conveyance of meaning in and of itself would have had me arguing for what we both already agree on.

Come onnnnn. It's not that bad with the grammar/punctuation, capitalization of acronyms and proper nouns, backtick highlights, and codeblocks.

If you are OK with a text being not that bad, hmm ... it is your choice. Readability is an extremely important UX concept, not to mention the accessibility in this case. For the current version of the text, people with less than great eyesight have to rely only on the (tiny) trailing dot to visually distinguish between sentences. Having proper capitalization within the context would enormously improve the text's accessibility.

As for "grammar/punctuation, capitalization of acronyms and proper nouns, backtick highlights, and codeblocks", well ... if the text would lack that, it would have been a completely unreadable wall of text.

I'm speaking of the readability being not that bad.

Accessibility arguments you're pushing here and elsewhere should have been brought up much earlier. I'm responding mainly to the "ridiculous!" outburst. (e: OK, no exclamation, and a more charitable reading will have me withdraw "outburst.")

> if the text would lack that, it would have been a completely unreadable wall of text.

Yet, in its form, it is more readable and coherent than most of what gets pushed out these days, even with proper capitalization. If anything, that is ridiculous.

With this shifting, I would like to take my leave. Be well, and good night.

> If this is your argument

I was not providing an argument, I was attempting to save time by rebutting the argument I thought you would make.

Why do you find this trend "ridiculous" and "disturbing"? Deeper in this thread you state this is somehow worse UX, and makes the text less readable. I... don't see how it's any less readable, could you elaborate?

I had thought you might say that this style is distracting, because it is so unusual you're involuntarily pulled from the content and made to focus on the form. I was trying to say, this effect is real, but it is at worst a temporary one. As you note this is a real trend and I expect soon we'll all be used to it. I'm already pretty used to it.

It's also a little ironic that you're rebelling against a new capitalization scheme but you're happy to use "BTW". Can you find a dictionary from 10 years ago which includes "BTW"? You're clearly okay with some form of language evolution, why draw the line here?

> Deeper in this thread you state this is somehow worse UX, and makes the text less readable. I... don't see how it's any less readable, could you elaborate?

Sure. I argue that this "style" provides poor UX due to decreased readability. Why decreased readability? Well ... Since late Middle Ages (maybe even earlier), people have realized that it is much easier to visually distinguish and consume concepts (in the form of sentences and paragraphs) when they are marked by specially formed characters (capital letters for sentences and initials aka drop caps for paragraphs and chapters). The following link points to the image (as an example) of an illuminated Psalter manuscript from Southern Germany circa 1240-1260: https://www.abebooks.com/images/medieval-manuscripts/german-.... You see what I mean, don't you? Read on ...

> ... this is a real trend and I expect soon we'll all be used to it.

I strongly disagree - there is no chance we all get used to it. With 99.(9)% of all text in the world using traditional capitalization rules / approach, it is practically infeasible that we all somehow get used to an extremely tiny subset of visual styles that make no sense to our brain. Historically, psychologically and, more importantly, physiologically, humans are wired for chunking information for easier digestion and anything that obstructs that is doomed to fail. Here is a relevant UX-focused article on the subject: https://www.nngroup.com/articles/chunking.

> It's also a little ironic that you're rebelling against a new capitalization scheme but you're happy to use "BTW" ... You're clearly okay with some form of language evolution, why draw the line here?

I draw the line between using a slang abbreviation widely prevalent on the Internet - essentially a de facto standard abbreviation for informal communication (which my brief comment on Hacker News certainly is) - and using an extremely unusual, to put it politely, text capitalization scheme for a long (and much more formal than my comment) blog post.

In a world where everyone has terrible body odor, your nose will become used to it and it will no longer be a distracting shock.

This analogy doesn't hold. You were born with a sensitivity for body odor, you were not born with any sensitivity for lowercase letters.

Do you really mean to imply that sentences which start with lowercase letters are intrinsically visually offensive?

Every time I've given the benefit of the doubt to someone who opens our interaction by intentionally burning social capital on something frivolous, it has been a mistake.

ever heard of konsequente kleinschreibung?

Never heard about it before seeing your comment. However, I have just looked it up and I think that the very limited scope (both temporal and geographical) of this "movement" just additionally emphasizes and supports the points that I have made in this thread.

why is it disturbing it reads fine to me

bEcAuSe pRoPer cApItAlIzAtIoN iS iMpOrTaNt fOr rEaDaBiLiTy ;-)

Here are a few seventh bits (01000000, \100, 64, 0x40) for your ANDing pleasure, so you can pull a Timothy Dexter and peper and solt it as you plese: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Perhaps, I'm dumb as rock, but what does your comment have to do with what I originally wrote above?

> for your ANDing pleasure

Oh?

It turns out I'm an idiot. I should have provided sixth bits (00100000, \040, 32, 0x20) for your XORing pleasure:

%20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20

My mistake.

I recently rewrote my fork of cplay and got fed up with curses. Boy do I wish I had found this article earlier because it describes everything I painfully had to cobble together. This is great!

Just one nit: Doing stuff in a signal handler is usually a bad idea because it can interrupt your code at any time. The usual work around is a trick called "self-pipe". https://ldpreload.com/blog/signalfd-is-useless

For anyone interested, I created a library in the process: https://github.com/xi/boon (It takes some inspiration from react but bare with me, I think it actually makes sense.)

Oh man, they left out the part I was hoping to find out more about!

> it's good form to have a function called resize() or similar that you run on program start and later when the terminal window is resized. while there is a horrible way to do this with ANSI escapes, it's better to just bite the bullet and learn how to use ioctls and termios.

I wanted to know about the horrible ANSI escape sequences to send that can query the window size. Afaict one has to read from the terminal to get the answer--but these are control sequences that could be inserted into the normal stream--when, where, how?

You can look at the programmer's guide for the VT100[1], which does a good job of explaining the different ANSI escape codes.

To put it simply, you can move the cursor down and to the right. For example, you'd move the cursor 999 lines down, then 999 columns to the right, and then query the cursor's position[2]. You can then read the output through STDOUT and parse it.

I'd recommend anyone who's interested in playing around with ANSI and learning how to write a pure terminal-based program to look into the Kilo text editor[3]. That's where I learnt the above instructions.

[1] https://vt100.net/docs/vt100-ug/chapter3.html

[2] https://vt100.net/docs/vt100-ug/chapter3.html#CPR

[3] https://viewsourcecode.org/snaptoken/kilo/

Horrible escape sequences: man 4 console_codes

Horrible console ioctls: man 4 console_ioctl

Can barely read the content with that colorscheme.

that site has great personal branding. recall seeing other articles from lexi halle on the feediverse some time ago and immediately recognized it.

great content too.

What's this stuff about:

> also, i'm a) a nobody and b) a woman. nothing i wrote would ever gain any traction; any project designed to supplant ncurses needs to come from someone who's actually known to the FOSS community. and a maintainer who isn't a cripple.

Did ncurses gain popularity because of the identity of its maintainer(s)?! I was of the impression that it's whoever gets there first.

That’s pretty nasty - this article is factually incorrect in probably the worst way: the code will work on author’s computer, but not for other people [0]

Not to mention that it is missing “good citizen” features like turning off colors when stdout is not a tty.

[0] https://news.ycombinator.com/item?id=18125374

> (...) the code will work on author’s computer, but not for other people

Is it actually the case?

The comment you cite says the code won't work on xterm or gnome-terminal.

I've checked with what I had available: XTerm(330) and GNOME Terminal 3.30.1 using VTE 0.54.1. On both terminals the last code sample from the post works perfectly fine as far as I can tell.

What terminal should I use to see improper behavior of the program?

> “good citizen” features like turning off colors when stdout is not a tty.

Better solution: do not detect whether your output is a tty or not.

Let the user decide they want colors or not by using `--color=always` or `--color=never` or similar.

There's few things worse than writing a script and getting different output just because you're no longer running the program interactively.

I don't see how this is supposed to work? Let's take "grep" for example -- you want both of these to work, and print color to terminal:

    grep box file.txt
    grep box file.txt | grep -v orange-box

Having --color=always is nice sometimes, but there is a reason grep has "--color=auto" and it is the default. If we write invisible characters to file, this breaks all sorts of tools, so it is much safer and more predictable to not include them.

If I wanted to see just orange-box, then I would do

    grep --color=always orange-box file.txt

But, I don't want to see just orange-box. I want to see orange-box and compare against other cases of box. So I would do:

    grep --color=always box file.txt | grep --color=always orange-box

Without that --color=always, other cases of box will be drowned out by the noise.

And if I wanted to write that out to a file then I would do

    grep --color=never orange-box file.txt > matches.txt

Alternatively, I'd add a filter to the file with `ansi2txt`

    grep --color=always box file.txt | grep --color=always box | ansi2txt > no-color-matches.txt

I think the point the person you are replying to was trying to make is that in your proposed sequence of colored greps, the second one would not catch the "orange-box"es because of the extra chars added for coloring the output of the first grep.

Maybe grep should ignore ansi sequences optionally or by default, to solve this?

Gah i got bit by this with 'jq'!

> $ echo "{}" | jq > {} > $ echo "{}" | jq > out.json > jq - commandline JSON processor [version 1.5-1-a5b5cbe] ... etc ...

Turns out when stdout isn't a tty you _must_ specify a filter (in this case '.')

Yup! I had the same problem too. It was 'fixed' in jq 1.6, such that it now assumes `.` is the filter if no program arguments are provided [0].

It happens all the time with anything systemd or networkmanager too

[0]: https://github.com/stedolan/jq/releases/tag/jq-1.6

> Not to mention that it is missing “good citizen” features like turning off colors when stdout is not a tty.

It's a tutorial, not a 1000 page book. Some things won't be in there.

Besides, detecting stdout or tty isn't even relevant for interactive TUI applications.

ncurses is a lot more readable than just dropping raw control codes into your source code, and it works, whereas raw control codes might work and often don't.

Interesting, but I wish it was less emotionally charged.

But very cool using macros to make an easy styling "language"!

I was just reading up an ANSI escape sequences a few days ago, this is gold.

I adore the format and writing style too.