Everything you ever wanted to know about terminals (2018)
xn--rpa.cc
xn--rpa.cc
Do you really mean to imply that sentences which start with lowercase letters are intrinsically visually offensive?
It's pretty clear she pays mind to grammar and cares about its proper usage more than most.
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 :)
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.
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.
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.
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?
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.
Oh?
%20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20
My mistake.
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.)
> 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?
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
Horrible console ioctls: man 4 console_ioctl
great content too.
> 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.
Not to mention that it is missing “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.
> $ 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 '.')
It happens all the time with anything systemd or networkmanager too
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. 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.txtMaybe grep should ignore ansi sequences optionally or by default, to solve this?
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?
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.
But very cool using macros to make an easy styling "language"!
I adore the format and writing style too.