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

51–60 of 144 posts

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

#51

Post by Tiksi »

elros wrote: post #3
igravious wrote: post #2

I've been trying to teach myself some unicode code points because I'm getting sick and tired of continually Googling them and copying and pasting the result or bringing up a symbol character table. In fact, I'd say keyboards are woefully out to date. Specifically, I keep looking up † dagger (U+2020) and ‡ double-dagger (U+2021) for footnotes, black heart (U+2065) to be romantic, black star (U+2605) to talk about Davi…

On OS X, if you type Command+Control+Space, it brings up a character insertion menu where you can search by character name. I can get both daggers, black star and black heart quite quickly that way.

There's a program called gucharmap which does similar on linux, hotkeys probably vary though.

http://paste.click/MYRVrF

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

#52

Post by Zancarius »

ori_b wrote: post #13
dylan-m wrote: post #10

Earlier quoted context omitted.

Another really handy thing is the Compose key. If you're using GNOME it's under Keyboard Settings, under Shortcuts / Typing. I have it set to Right Alt. The idea is there's just a whole bunch of memorable key sequences for various common Unicode characters. For example, Alt + o + o = °; < + 3 = black heart, < + " = “, etc. It doesn't have all of the ones you like, but it's helpful :)

I usually map my insert key to compose -- I never use 'insert' for the default functionality, but I also don't type funny characters often enough to justify getting rid of an alt or control key.

I love reading about how different people map different things. For me, it would be a disaster to map insert since I use that for pasting (shift+insert--I'm a lefty and it's a bad habit I grew attached to years ago).

My choice for Compose is the right Windows key, which I think I eventually settled on because I use the left one in some keybinds (winkey+s for shell, etc.) and like you, I couldn't part with an alt or ctrl. I've often wondered what other folks tend to use.

To the grandparent: I'm sometimes amused by what Compose defines. There's ∞ (compose + 8 + 8), (compose + # + #), and oddly (compose + C + C + C + P). I think it may depend on system configuration, but I believe libX11 is responsible. (On my system, Arch, the key combinations appear to be documented under /usr/share/doc/libX11/i18n/compose for my locale.)

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

#53

Post by nils-m-holm »

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

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

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

#54

Post by dijit »

2trill2spill wrote: post #40
kazinator wrote: post #25

Earlier quoted context omitted.

That was baseless posturing. A famous study and its follow-up found that the utilities on GNU/Linux are more robust, and that was twenty years ago: ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz-revisited.pdf [1995] " This study parallels our 1990 study (that tested only the basic UNIX utilities); all systems that we compared between 1990 and 1995 noticeably improved in reliability, but still had significant rat…

> The maintainers of the free BSD's have been carrying that torch, but they don't believe in features. Stepping into a BSD variant is like a trip back to the 1980's. Not exactly the real 1980's, but a parallel 1980's in which Unix is more robust---but the features are all rolled back, so it's just about as unpleasant to use. Sorry but that's all BS. FreeBSD is definitely a modern system, has lot's of features and is…

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, but makes trade offs in how clean the implementation of the OS feels to keep up with linux.

or, at least it feels like this to me. But to say the BSDs aren't modern is deluded, there's a reason they're known to have the fastest software networking stack in the world.

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

#55

Post by comex »

deathanatos wrote: post #34

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

#56

Post by comex »

elros wrote: post #3
igravious wrote: post #2

I've been trying to teach myself some unicode code points because I'm getting sick and tired of continually Googling them and copying and pasting the result or bringing up a symbol character table. In fact, I'd say keyboards are woefully out to date. Specifically, I keep looking up † dagger (U+2020) and ‡ double-dagger (U+2021) for footnotes, black heart (U+2065) to be romantic, black star (U+2605) to talk about Davi…

On OS X, if you type Command+Control+Space, it brings up a character insertion menu where you can search by character name. I can get both daggers, black star and black heart quite quickly that way.

You can also set up custom text macros in the keyboard preferences, which are a bit faster to input. I have :lod: mapped to ಠ_ಠ...

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

#58

Post by [deleted] »

igravious wrote: post #8
jcranmer wrote: post #4

Earlier quoted context omitted.

That Ctrl+Shift+u hint is nice. Now I can type all the time I want without having to browse for the emoji page to copy it. And it sucks that I have to use so much that I know the code point for it (1F4A9) off the top of my head. :-( Edit: I'm definitely putting in U+1F4A9 (the PILE OF POO character), but apparently hacker news strips it out. I'm guessing it's filtering everything that has a symbol character class?

Yes! The Ctrl+Shift+u hint is nice. I can't believe I only just learnt it. How many _years_ have I been Googling unicode characters for? I am ashamed to think. I am glad PILE OF POO does not work for you. does (U+2603) snowman work? edit: noooo, no snowman

[deleted]

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

#59

Post by gjvc »

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…

>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) man page by default. So why the hell write the (1) notation every time you type the word xterm?

Because the convention exists to define the type of the component. It's a handy convention, and I'm betting there are a few people reading this who have never used anything other than GNOME terminal so appending the section number immediately helps the reader to place the component, otherwise they'd have to look it up. etc

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

#60

Post by plugnburn »

pilif wrote: post #39
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.

>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, because their values are not COMMA-separated (as the name implies), but semicolon-separated. And we, programmers, have to deal with it somehow, not to mention some obsolete Faildows encodings like CP1251 still widely used here in lots of tech-slowpoke organizations.

So: one encoding, one datetime format, one numeric format for the world and for the win. Heil UTF-8!

Post reply on HN