Live data from Hacker News

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

undeadly.org

91–100 of 144 posts

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

#91

Earlier quoted context omitted.

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 !!!!

> 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.)

Plan9 has an environment variable $font that sets the system font for everything. The windowing system can even start inside one of its own windows so you can have different fonts for different sets of programs, all settable at runtime.

The TTY must die.

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

#92

Earlier quoted context omitted.

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 !!!!

Seems like your mouse never broke (or, if you have a wireless one, the battery in it has never died, and if it did, you could immediately replace it). Or are you the type that does everything on a touchscreen? Because, judging from your logic, traditional computer controls must die too...

The high frequency of mouse failure, the high cost of downtime and the low price of mice suggest that having spare mice makes sense.

By your logic, I would be stranded at the side of the road wishing I had a spare tyre.

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

#93
post #39

Earlier quoted context omitted.

>Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always The problems solved by LANG or LC_ALL are not solved by UTF8 alone. Even if you use UTF8 for all your input and output, there is still the question of how to format numbers and dates to the user and how to collate strings. These things are dependent on country and language, sometimes even varying between different places in a…

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 with current font technology, and there are probably all sorts of problems with it even if it is, but it might be vaguely useful.

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

#94

Earlier quoted context omitted.

The basic problem, as i see it, is that the Gnome/Freedesktop people got hold of the user space reins, and turned what used to be a kernel up development process into a desktop down development process.

I don't know if it ever was a "kernel up" development process. Gnome (and KDE) both had their own, pretty complex stack, even before Freedesktop.org came up (e.g. KDE had DCOP and a bunch of other services). And they weren't exactly bug-free, either -- but at least they covered a lot less surface. I don't think it's a simple problem, and I don't think all the blame should be laid on Freedesktop.org, where a lot of go…

Not in a planned sense. But until Freedesktop, i had the impression that you had the kernel, then CLI user space, and the X and the DEs that wrapped the CLI tools in certain ways and the CLI tools in turn talked to the kernel.

Thus you could go from bare kernel, to CLI to GUI in a layered manner (and fall back when a higher layer had issues).

With Dbus etc the CLI has been sidelined. Now you have a bunch of daemons that talk kernel at one end and dbus at the other.

Never mind that they tried to push a variant of dbus directly into the kernel. And as that failed, is now cooking up another take that yet again is about putting some kind of DE RPC/IPC right in the kernel.

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

#95

I and others have pushed changes into XTerm to improve mouse support of terminal-based applications. All terminal emulators should implement XTerm's command set, especially these: Bracketed paste mode: allows editor to determine that text is from a mouse paste instead of typed in. This way, the editor can disable auto-indent and other things which can mess up the paste. Libvte now supports this! Base64 selection tran…

[deleted]

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

#96

Earlier quoted context omitted.

Yes but UTF-8 with or without byte order mark ? ;-)

Without. BOM (when used for UTF-8) is an obsolete crap invented by necrosoft in order to make their software incompatible with normal.

It's not a Microsoft invention, and MS's use of it is really quite sensible. They had a problem of distinguishing UTF-16, UTF-8 and non-Unicode (possibly a single-byte "extended ASCII" type encoding, possibly some multi-byte monstrosity) text files. Since UTF-8 and ASCII-compatible encodings look similar when there aren't many >U+007F characters in use, and identical if none are in use, they could get confused. Prepending a Byte Order Mark solves this problem, in that it makes a file unambiguously UTF-8 (or UTF-16, for that matter).

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

#97
post #73

Earlier quoted context omitted.

And in 20-30 years we'll likely be saying the same about UTF-8. I figured that "ANSI" would give away that I wasn't being serious since it's not actually an encoding.

> 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…

Unicode is currently limited to 21 bits for compatibility with UTF-16. Eventually we might manage to exhaust all available codepoint space, and with that we'd have to move to yet another encoding with a whole new kind of surrogate pairs. Though UTF-8 could originally handle 31 bits, that's no longer the case.

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

#98
post #55

Repeat after me: UTF-8 is the sane default in this day and age. This is a good change. The whole "the ISO 6429 C1 control code 'application program command'" thing is a bit surprising though. (I'm guessing this change doesn't actually avoid this directly? If you sent an APC it'd still do it, it's just that APC is multiple bytes in UTF-8, and hopefully a bit rarer?) > Reinterpreting US-ASCII in an arbitrary encoding T…

UTF-16 isn't a superset of ASCII, for one. Doesn't seem that anyone uses a native UTF-16 terminal, but if you're trying to use grep or whatnot on a UTF-16 encoded file, it'll happily silently not do what you want...

畂桳栠摩琠敨映捡獴!

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

#99

Earlier quoted context omitted.

> The maintainers of the free BSD's have been carrying that torch, but they don't believe in features. I used Linux for more than a decade before switching to OpenBSD precisely because Linux developers believe in features to the point where how well they're implemented is no longer relevant. The arrogant, know-it-all kids that we so lovingly nurtured in the Linux community grew up to be its forefront developers today…

What's so cool about OpenVMS? You're not the first person to praise it but nobody ever explained why.

The comparison may be a little anachronistic but... well, in order to understand why OpenVMS made such a dent on computer history, you have to put it in context first.

OpenVMS's days of glory more or less coincided with the Unix wars. Unix was brilliantly hacker-friendly, but a lot of basic things that we now take for granted in Linux -- virtual memory, high-speed I/O and networking -- were clunky and unstandardized. Others (like Files-11, VMS's excellent filesystem) were pretty much nowhere to be found on Unices (or, if they were, they were proprietary and very, very expensive). An Unix system included bits and pieces hacked together by people from vastly different institutions (often universities) and a lot of the design of the upper layers was pretty much ad-hoc.

OpenVMS had been a commercial project from the very beginning. It had a very well documented design and very sound engineering principles behind it. I think my favourite feature is (well, technically, I guess, was) the DLM (Distributed Lock Manager), which was basically a distributed concurrent access system with which you could do concurrent access to resources (such as, but not only, files) in a clustered system. I.e. you could acquire locks to remote resources -- this was pretty mind-blowing at the time. You can see how it was used here: e.g. http://www3.sympatico.ca/n.rieck/docs/openvms_notes_DLM.html .

Also, the VAX hardware it ran on rocked. The whole thing was as stable and sturdy as we used to boast about Linux in comparison to Windows 98, except at a time when many Unices crashed if you did the wrong thing over NFS.

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

#100
Wouldn't it be better if all those dangerous escape sequences (like Application Program-Control, redefining function keys, alternate character sets, etc.) were disabled by default in xterm? Anyone using the obsolete software that uses them could enable them if they wish.
Post reply on HN