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

Xterm(1) now UTF-8 by default on OpenBSD

undeadly.org

Post reply on HN
Print view View original

111–120 of 144 posts

Re: Xterm(1) now UTF-8 by default on OpenBSD

#111

Post by kazinator »

setra wrote: post #36
cplease wrote: post #35

Earlier quoted context omitted.

Just replying to point out that the grayed out comment above is the correct one. There is ugliness in coreutils, but it mature, functional, proven ugliness. A lot of it is even there for a reason. It's not difficult to make an elegant toy in isolation.

checkout the different implementations of echo across various operating systems: " https://gist.github.com/dchest/1091803" .

To delimit URL's, use square brackets: [https://gist.github.com/dchest/109180].

There is an RFC standard way of quoting URLs and addresses, namely angle brackets. HN doesn't implement it, though:

" rel="nofollow">https://gist.github.com/dchest/109180>.

See? The closing > is included in the URL, stupidly.

The convention first appeared in [https://www.ietf.org/rfc/rfc1738.txt] in 1995, with Tim Berners Lee the top author.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#112

Post by nils-m-holm »

guard-of-terra wrote: post #88
nils-m-holm wrote: post #53

Earlier quoted context omitted.

> The TTY must die!!!! Being sight-impaired, I have to disagree strongly! The TTY is the only thing that lets me adjust the font size of all programs running in it without going through lots of trouble. (BTW: didn't downvote your comment.)

Browsers let you do that. KDE also does, so do other environments. For a quick hack, set your sceen DPI to 50.

Set your minimum font size to 32 points and browse the web for a while! Let me know how it feels!

Re: Xterm(1) now UTF-8 by default on OpenBSD

#113

Post by guard-of-terra »

nils-m-holm wrote: post #112
guard-of-terra wrote: post #88

Earlier quoted context omitted.

Browsers let you do that. KDE also does, so do other environments. For a quick hack, set your sceen DPI to 50.

Set your minimum font size to 32 points and browse the web for a while! Let me know how it feels!

Browsers can set default zoom, not just font size.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#114

Post by cturner »

SixSigma wrote: post #38
kazinator wrote: post #30

Earlier quoted context omitted.

Only by not using subordinate clauses did you just avoid saying "plan 9" and "commercial" in the same sentence! Where is Plan 9 deployed? Who are the customers? Plan 9 is a strawman representative of "commercial Unix". > Combine a few GNU core utils, and you have more code than the whole plan 9 kernel. When you actually sit down and think of the cases that can occur, that translates into code. Handle this, handle tha…

While it is only a few : Sydney Olympics lighting system was Plan9 based. Inferno was used by NASA JPL projects Lucent use a real time version of plan9 in phone masts Coraid use Plan9 on their NAS servers Researchers at LANL and IBM use plan9 on the Blue Gene, and other, supercomputers I have worked for two plan9 based companies - ok they didn't survive but we tried :) The international plan9 conferences drew about 3…

Hey, this isn't really a direct response to any of the points you made, but I've been thinking about your get-rid-of-the-tty comment, and wanted to ask.

What is your take on syntax highlighting in a plan9 world? I've read a list of questions somewhere about p9, and remember this one being asked and having a typically abrasive response, along the lines of "just don't". And I often have a lot of time for those kind of arguments - embrace minimalism. But I regularly (daily) find syntax highlighting to be super-useful for highlighting small errors. What's your take? It seems like a regex-ey problem. Could it be done in a way that was within the spirit of such a system?

Re: Xterm(1) now UTF-8 by default on OpenBSD

#115

Post by pjc50 »

SixSigma wrote: post #37
cokernel_hacker wrote: post #28

Earlier quoted context omitted.

I don't think Rob meant stability. Rob was probably referring to the reality that modern Linux hasn't innovated itself past SVR4 by any appreciable amount. We are still using X, still using terminals powered by control codes, etc. Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always. Where is Linux? Still in bag-of-bytes-o-rama.

That and getting rid of the TTY altogether. We aren't using punched cards EDIT: people hate when I say this, which amuses me. The TTY must die !!!!

How do you operate a command line without something similar to the tty? Windows doesn't have a tty-style interface, and as a result its command prompt has been even more primitive.

(Powershell ISE is something else .. once it actually loads)

Re: Xterm(1) now UTF-8 by default on OpenBSD

#116

Post by recursive »

kazinator wrote: post #19

Great! Now just drop the embarrassing man(1) page reference, and you can call it modernized. Wow, I'm surprised that the people whose buttons this pushes are able to make(1) a HN account, let alone have enough points to downvote. Think about it. There is only one man page for xterm. I fyou type "man xterm" with no section number you get that man page. If there existed an xterm(7) page, you'd still get the xterm(1) ma…

Huh. I always thought those parenthesized numbers after unix commands were version numbers.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#117

Post by nils-m-holm »

guard-of-terra wrote: post #113
nils-m-holm wrote: post #112

Earlier quoted context omitted.

Set your minimum font size to 32 points and browse the web for a while! Let me know how it feels!

Browsers can set default zoom, not just font size.

Doesn't help. When the zoom factor is big enough, you have to scroll sideways while reading.

Anyway, I have tried a lot of things over the years and nothing even comes close to using a text interface.

To name a few nuisances: controls moving outside of the screen, overlapping elements in web content, unreadable buttons, unclickable input fields, tiny fonts in menus, etc. Nothing of this happens with text interfaces.

Thanks for your input, though!

Re: Xterm(1) now UTF-8 by default on OpenBSD

#118

Post by plugnburn »

Tiksi wrote: post #110
plugnburn wrote: post #77

Earlier quoted context omitted.

> And in 20-30 years we'll likely be saying the same about UTF-8. Well... If we will, why not? But the thing is that in 20-30 years we won't be able to invent any new writing systems that UTF-8 won't cover. Single-byte encodings were doomed because of their single-byteness. The same awaits two-byte encodings like UCS-2 (aka UTF-16BE) - we already have extended code points for something that glamour hipsters call "emo…

> But the thing is that in 20-30 years we won't be able to invent any new writing systems that UTF-8 won't cover. I think you underestimate humanity's aptitude at creating things that don't fit into well defined standards. My (admittedly poorly stated) point wasn't that we shouldn't be moving everything over to UTF-8. I personally use it wherever possible just because it makes life easier. My point was that there are…

I think you miss the point. When CP1251, KOI8-R and other crazy imcompatible things came around, they came around because there was a need: ASCII didn't provide a necessary character set. Now when we have Unicode that embodies virtually all character sets existing on Earth, we don't _really_ need either non-Unicode encodings, or even fixed-byte UTF versions. So a move to any hypothetical FutureText-64 will actually give no practical gain, unlike a move from single-byters to, for example, UCS-2 and then from UCS-2 to UTF-8.

But my main point is another: eliminate all single-byter and fixed-byter zoo and leave one universal encoding. When (if ever) it's time to replace it, we'll do it all and at once, not having those crazy iconvs everywhere.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#119

Post by plugnburn »

philh wrote: post #93
plugnburn wrote: post #60

Earlier quoted context omitted.

Here in ex-USSR we have those problems too. Why not standardize decimal separators altogether worldwide? We're not dealing with feeking paper handwriting! If a number is printed on a computer display, it must look like 123456.78, not like "123 456,78"! Same goes for datetime representation. This localization BS has spawned an entire race of nonsense, where, for example, CSV files are not actually CSV in some regions,…

> If a number is printed on a computer display, it must look like 123456.78, not like "123 456,78"! Humans find thousands separators useful. You're asking humans to give up useful things because they're hard to program. That said, I idly wonder whether they could be implemented with font kerning. The bytes could be 123456.78, but the font could render it with extra space, as 123 456.78. I don't know if it's possible…

I don't get neither how thousands separator is useful, nor what a "genius" came up with an idea to make comma a decimal separator in computers. I have nothing against either of these things in handwriting (though I personally never separate thousands), but in computing?..

I agree though that this can (and should) be solved at font-rendering level, not at an application level.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#120

Post by kazinator »

brohee wrote: post #49
neerdowell wrote: post #46

Earlier quoted context omitted.

OpenBSD's malloc(3) implementation is found in sys/kern/kern_malloc.c, and OpenBSD's malloc(9) implementation is found in lib/libc/stdlib/malloc.c

The reverse actually...

Of course the reverse; why would the traditional (3) section be suddenly taken over by kernel functions, and libc stuff moved to (9)?
Post reply on HN