Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Elegance of the ASCII Table

danq.me

Post reply on HN
Print view View original

131–140 of 189 posts

Re: The Elegance of the ASCII Table

#131

Post by yencabulator »

WalterBright wrote: post #52

Too bad we now have Unicode, an elegant castle covered with ugly graffiti and ramshackle addons. For example: 1. normalization 2. backwards running text (hey, why not add spiral running text?) 3. fonts 4. invisible characters 5. multiple code points with the same glyph 6. glyphs defined by multiple code points (gee, I thought Unicode was to get away with that mess from code pages!) 7. made up languages (Elvish? Come…

I can't wait for when the majority of Unicode codepoints/glyphs are emojis that are no longer fashionable! That'll be a really weird relic of history, later.

Re: The Elegance of the ASCII Table

#132

Post by yencabulator »

BobbyTables2 wrote: post #12

I always lament that since at least 1980s or so, it seems the vast majority of the control characters were never used for their intended purpose. Instead, we crudely use commas and tabs as delimiters instead of something like RS (#30).

Ah, Deborah␞ Records. Little Debbie Records, we call her.

Re: The Elegance of the ASCII Table

#133

Post by flohofwoe »

Sharlin wrote: post #72
lucasoshiro wrote: post #2

Once I saw a case-insensitive switch in C using that pattern of letters: switch (my_char | 0x20) { case 'a': ... break; case 'b': ... break; }

Yes, that’s very intentional and just masking (or setting) the bit is the intended way to do case-insensitive comparison of the letter range in ASCII (eg. stricmp in C), or to transform text to lower or upper case (tolower, toupper). But what’s more, ever wondered whence the control (Ctrl) key presses like Ctrl-H to backspace, or Ctrl-M for carriage return? Well, inspecting the ASCII chart it becomes evident: the Ctr…

...it's a bit of a shame that the same upper/lowercase trick doesn't apply to all UNICODE codepoints (at least those that have upper/lower variants).

It seems to work for codepoints up to U+00FF, for instance:

    - Å (U+00C5) vs å (U+00E5)
...but above 0xFF lowercase follows uppercase:

    - Ă (U+0102) vs ă (U+0103)
Typical for UNICODE though, nothing makes sense ;)

Re: The Elegance of the ASCII Table

#136

Post by fitsumbelay »

augusto-moura wrote: post #67

Useful tip, on linux (not sure about other *nixes) you can view the ascii table by opening its manpage: man ascii It's been useful to me more than once every year, mostly to know about shell escape codes and when doing weird character ranges in regex and C. It can be a bit confusing, but the gist is that you have 2 chars being show in each line, I would prefer a view where you see the same char with shift and/or ctrl…

strange: on MacOS 14.5 I get output for `man ascii` but `ascii` goes "command not found"

Re: The Elegance of the ASCII Table

#137

Post by AnimalMuppet »

fitsumbelay wrote: post #136
augusto-moura wrote: post #67

Useful tip, on linux (not sure about other *nixes) you can view the ascii table by opening its manpage: man ascii It's been useful to me more than once every year, mostly to know about shell escape codes and when doing weird character ranges in regex and C. It can be a bit confusing, but the gist is that you have 2 chars being show in each line, I would prefer a view where you see the same char with shift and/or ctrl…

strange: on MacOS 14.5 I get output for `man ascii` but `ascii` goes "command not found"

On my Linux VM, it's the same, and it's because 'man ascii' comes from man(7), not man(1). It's not a man page for a program. It's just a man page.

Re: The Elegance of the ASCII Table

#138

Post by p_l »

news_to_me wrote: post #119
p_l wrote: post #61

Earlier quoted context omitted.

How to say you don't know what Unicode is for without saying it. 1, 2, 4, 5, 6, and, unfortunately, 8, all fall under "ability to encode written text from all human languages". And that includes historical. Some of the issues (5 & 6) are due semantic difference even if the resulting glyph looks the same. Unfortunately you can't expect programmers to understand pesky little thing like languages having different writin…

> "a + ogonek accent" and another (properly) sent "a with ogonek" (these print the same but are semantically different!) How can these possibly be semantically different? Isn’t the point of combining characters to create semantic characters that are the combination of those parts?

There's a semantic difference between "accented letter" and "different letter that happens to visually look like another language's accented letter".

"Ą" in polish is not "A" with some accent. And the idea behind unicode was to preserve human written text, including keeping track of things like "this is letter A1 with an accent, but this is letter A2 that looks visually similar to A1 with accent but is different semantically". Of course then worries about code page size resulted in the stupidity of Han unification, so Unicode is a bit broken.

Re: The Elegance of the ASCII Table

#139

Post by jiveturkey »

theamk wrote: post #31
jiveturkey wrote: post #4

ebcdic is also quite elegant https://news.ycombinator.com/item?id=13543715

It's really not. In base-2 machines, the letters are mixed with punctuation, which is pretty horrible design which makes simple things complex, and does not actually bring anything new to the table. In BCD machines it is slightly better, except letters aren't contiguous either - row 0 is bad, but it's the extra space between R and S which is really ugly. And it's unusable with BCD operations anyway, as high nibble va…

It was designed for a specific purpose ... elegance in context

Re: The Elegance of the ASCII Table

#140

Post by Gormo »

snvzz wrote: post #75

The ASCII table is defective; it is missing a dedicated code for newline. CR and LF aren't dedicated, and have precise cursor movement meanings, rather than being a logical line ender. There was a proposal in the 80s to reassigning the -otherwise useless- VT (vertical tab) character for the purpose. Unfortunately unfruitful.

> Unfortunately unfruitful.

Fortunately unfruitful, since if it had gained adoption, there'd be a mix of three different line endings (and combinations thereof) in widespread use, instead of two.

Post reply on HN