Xterm(1) now UTF-8 by default on OpenBSD • Hacker News Board

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

#121

Post by guard-of-terra » Wed, Mar 09, 2016, 5:45 PM UTC

nils-m-holm wrote: post #117

guard-of-terra wrote: post #113

Earlier quoted context omitted.

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

For reading, consider installing beeline reader (yes the name is stupid-ish), in plugin or bookmarklet form.

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

#122

Post by plugnburn » Wed, Mar 09, 2016, 5:46 PM UTC

spiralpolitik wrote: post #90

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

Given that the world hasn't yet agreed on if a line ends by carriage return or carriage return-line feed I would not hold out much hope on this front (although with the death of just line feed some progress on this front as been made). See also paper sizes and electrical power outlets.

I also don't get why are you still using those miles and pounds when the rest of the world agreed on kilometres and kilograms.

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

#123

Post by plugnburn » Wed, Mar 09, 2016, 5:58 PM UTC

SixSigma wrote: post #92

plugnburn wrote: post #61

Earlier quoted context omitted.

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.

That's not quite a correct analogy because modern systems allow you to do things without mouse. Still there are some individuals that obviously strive to take those possibilities away and make a mouse like a tyre. I'm really happy it's not the case yet.

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

#124

Post by 2trill2spill » Wed, Mar 09, 2016, 6:05 PM UTC

kazinator wrote: post #105

dijit wrote: post #54

Earlier quoted context omitted.

He wants; Games, SystemD, complicated control interfaces, and most of all a fully interactive desktop environment which mounts his drives for him and plays flash videos.. .. Without taking much time to configure it. This is fair enough but it's not what I want in a machine, openBSD might be "behind" but it feels complete, supported, sustainable and most of all "very well thought out". FreeBSD is also exceedingly good…

I do not want any of that stuff. I found FreeBSD to be unusable simply in the command line environment. I was using only a text console login. I simply wanted a decent shell and editor. Heck, FreeBSD wouldn't even scroll back with the de facto standard Shift-PgUp. > mounts his drives for him That amazing advancement in Unix usability can be achieved by something called the "automount daemon" which was introduced in t…

> I found FreeBSD to be unusable simply in the command line environment. I was using only a text console login. I simply wanted a decent shell and editor.

If you don't like a command line interface install a desktop environment, if you want a different shell install one and if you wan't a different editor, again install a different one.

Nothing you have wrote suggest FreeBSD is unusable, apparently you prefer systems with this stuff already installed which is fine, but it doesn't mean you should knock the BSD's because you are unwilling or unable to install a couple new packages.

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

#125

Post by plugnburn » Wed, Mar 09, 2016, 6:19 PM UTC

TazeTSchnitzel wrote: post #97

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…

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.

So I see 2 steps here: dropping UTF-16 altogether (well, already, because there are plenty of extended codepoints above 0xFFFF), and when approaching the 31-bit limit - inventing something like "zero-width codepoint joiner" to compose codes of arbitrary length.

For example, in a hypothetical alien language, a hypothetical character "rjou" would have a code 0x2300740457 (all the previous codes are exhausted). We can't express this with a single code, so actually we split it into 2-byte parts and write "#" (0x0023), joiner, "t" (0x0074), joiner and "ї" (cyrillic letter yi, 0x0457). As we have a joiner between these codes, we know that we must interpret and display them not as a "#tї" sequence but as a single alien "rjou" character. I think you get the idea.

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

#126

Post by uf » Wed, Mar 09, 2016, 7:01 PM UTC

kazinator wrote: post #107

philh wrote: post #93

Earlier quoted context omitted.

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

Humans should agree on the decimal and separator symbols, the same way that they agreed on the Indo-Arabic numerals, and symbols like + (plus) and - (minus).

Like we all agreed to the metric system already?

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

#127

Post by TazeTSchnitzel » Wed, Mar 09, 2016, 7:35 PM UTC

plugnburn wrote: post #125

TazeTSchnitzel wrote: post #97

Earlier quoted context omitted.

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.

So I see 2 steps here: dropping UTF-16 altogether (well, already, because there are plenty of extended codepoints above 0xFFFF), and when approaching the 31-bit limit - inventing something like "zero-width codepoint joiner" to compose codes of arbitrary length. For example, in a hypothetical alien language, a hypothetical character "rjou" would have a code 0x2300740457 (all the previous codes are exhausted). We can't…

> dropping UTF-16 altogether (well, already, because there are plenty of extended codepoints above 0xFFFF)

UTF-16 can handle stuff above U+FFFF just fine, it encodes that with surrogate pairs. Are you thinking about UCS-2?

The 21-bit limit for Unicode comes from the limits of UTF-16's surrogate pairs.

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

#128

Post by sherr » Wed, Mar 09, 2016, 7:58 PM UTC

jhallenworld wrote: post #20

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…

Yes, Thomas Dickey's been maintaining xterm and a lot else for donkey's years now. A lot of people owe him a big "thank you" for all his hard work. Thanks Thomas.

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

#129

Post by kazinator » Wed, Mar 09, 2016, 9:30 PM UTC

notalaser wrote: post #101

digi_owl wrote: post #94

Earlier quoted context omitted.

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

I wouldn't have a problem with a bunch of daemons talking D-Bus to each other, if their interfaces were properly documented, if D-Bus were properly documented and, in general, if D-Bus weren't quite a mess. I mean, if it weren't for this obscurity, issuing commands over D-Bus wouldn't be that vastly different than issuing them on a console, only more verbose. Unfortunately, there is a lot of weird interaction between…

This seems an almost inveitable consequence of interfaces based on asynchronous message passing. Collaboration scenarios emerge which become impossible to trace. "If this secret handshake is done that way among these three processes, then such and such a use case is satisfied."

One problem with message passing as such is that messages are like function calls, but you can't put a breakpoint into the system and see a call stack!

If we call a function f on object a, which calls b.g(), a breakpoint in b.g() tells us that something called a.f() which then called b.g(). If we send a message f to a, which then sends a message g to b, a breakpoint in b on the receipt of message g tells us diddly squat! The g message came in for some reason, evidently from a. Well, why did a do that? Who knows; a has gone off and is doing something else.

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

#130

Post by kazinator » Wed, Mar 09, 2016, 10:07 PM UTC

plugnburn wrote: post #122

spiralpolitik wrote: post #90

Earlier quoted context omitted.

Given that the world hasn't yet agreed on if a line ends by carriage return or carriage return-line feed I would not hold out much hope on this front (although with the death of just line feed some progress on this front as been made). See also paper sizes and electrical power outlets.

I also don't get why are you still using those miles and pounds when the rest of the world agreed on kilometres and kilograms.

I live in Canada. Before that I grew up in a metric country. Though Canada is metric, I use imperial measures here and there.

I use miles for the sport of running. This is because 1609 meters is close to 1600. Four laps around a standard 400 meter track is about a mile and everything follows from that. All my training is based on miles. I think of paces per mile. If I'm traveling abroad and some hotel treadmill is in kilometers and km/h, it annoys the heck out of me.

However, paradoxically, road signs and car speedometers in miles and miles/hour also annoy the heck out of me; though at least since I use miles for running, at least I'm no stranger to the damn things.

For laying out circuit boards, I use mils, which are thousandths of an inch: they are a subdivision which gives a metric air to an imperial measure. This is not just personal choice: they are a standard in the electronics industry. The pins of a DIP (the old-school large one) are spaced exactly 100 mils (0.1") apart, and the rows are 300 mils apart. So you generally want a grid in mil divisions. (The finer-grained DIPs are 0.05" -- 50 mils.).

There is something nice about a mil in that when you're working with small things on that scale, it's just about right. A millimeter is huge. The metric system has no nice unit which corresponds to one mil. A micron is quite small: it's 25.4 mils. (How about ten of them and calling it a decamicron? Ha.)

Inches themselves are also a nice size, so I tend to use them for measuring household things: widths of cabinets and shelves and the like. Last time I designed a closet shelf, I used Sketchup and everything in inches.

Centimeters are too small. Common objects that have two-digit inch measurements blow up to three digits in centimeters.

Centimeters don't have a good, concise way to express the precision of a measurement (other than the ridiculous formality of adding a +/- tolerance). In inches, I can quote something as being 8 1/16 inch long. This tells us not only the absolute length, but also the granularity: the fact that I didn't say 8 2/32 or 8 4/64 tells you something: that I care only about sixteeth precision. The 8 1/16 measurement is probably an approximation of something that lies between 8 1/32 and 8 3/32, expressed concisely.

In centimeters, a measurement like 29 cm may be somewhat crude. But 29.3 cm might be ridiculously precise. It makes 29.4 look wrong, even though it may the case that anything in the 29.1-29.5 range is acceptable. The 10X jump in scale between centimeters and millimeters is just too darn large. The binary divisions in the imperial system give you 3.3 geometric steps inside one order of magnitude, which is useful. For a particular project, you can chose that it's going to be snapped to a 1/4" grid, or 1/8" or 1/16" based on the required precision.

So for these reasons, I have gravitated toward inches, even though I was raised metric, and came to a country that turned metric before I got here. (And of course, the easy availability of rulers and tape measures marked in inches, plus support in software applications, and the enduring use of these measures in trade: e.g. you can go to a hardware store in Canada and find 3/4" wood.)