Any rxvt-Sized Unicode-Aware Terminal Emulators? 48
Viqsi writes "Just on a lark, I started a short while back to try to convert my environment totally to UTF-8. One of the big hangups that I've run into so far, however, is my X terminal emulator. I've been very happy with rxvt (I tend to have several $XTERMs open at once, so Low Memory is Good!), but it doesn't seem to support anything Unicode. A bit of searching has turned up nothing that isn't as big as or larger than xterm itself. So, the question -- are there any low-memory terminal emulators that support UTF-8, or any other Unicode encoding? (tabbed-window style terminals Don't Count, and that goes double for Konsole!)"
Why (Score:1)
I also have a question regarding Unix and Unicode.
Although GNU/Linux and BSD systems can support Unicode libraries for the apps that need it, the OSes themselves use only ascii (from what I understand). Has there been, or ever will be, a form of Un*x that natively supports Unicode in all things? Or would doing such a thing create too many problems?
Re:Why (Score:1)
Re:Why (Score:2, Funny)
Why yourself (Score:2)
Re:Why yourself (Score:3, Insightful)
Or more than 640KBytes of RAM. Or more than a 33MHz processor. For that matter, why do they need both uppercase and lowercase? Why do they want monitors? What's wrong with a VT100?
The days of "sorry, no accents or unAmerican characters" are over. Unicode support at every level would be a big help for non-US-English development.
Re:Why yourself (Score:3, Informative)
When it boots, there's a whole slew of lines, many of which are purely numbers, but some of them could be localized (just as a big part of userland is). Now, since it would be in kernelspace, you'd maybe want to choose which one at compile time, but if you don't have access to a kind of Unicode for outputting strings, your choice of supported languages will be quite small.
Now, this doesn't go in the argument if it's a desired behavior or not, just that it's something necessary before outputting for any language.
Context! Purpose! (Score:2)
The Linux kernel is not a very big entity -- which is a prime reason for its success. I find it hard to see what use it can make of extended character sets. And even if adding such a feature to the kernel had some benefit, there's a cost in terms of size. speed, and risk of bugs and security holes. You need to weigh the benefits against the risks, not just assume every bit of software in the world has to support UTF-32768. And the plain fact is, there doesn't seem to be any benefit at all.
Perhaps I'm wrong. But to prove me wrong, you're going to have to suggest some real-world examples or scenarios that contradict me. Reciting cliches about vaguely relevent history says nothing.
Note that I'm not attacking the general concept of Internationalized software. In point of fact, I spend a lot of time documenting the International features of my own company's products. All serious development tools support Internationalization. But they support it from the run-time-library level on up, where 99.99% of all development occurs.
Re:Context! Purpose! (Score:2)
If you are a kernel hacker (I'm not....), and you want to use chinese characters as variable names, why should you not be able to do that? Is that what you meant? Just which parts of a computer should only ever be referred to using glyphs from the Roman empire, and why?
I can't think of any reason for any part of a computer system being ascii only, except the reason:
"It's quite hard to change, and there's not much demand". Which is fine, but given that most people in the world can't communicate using ASCII, it's surely only a temporary excuse....
Re:Context! Purpose! (Score:1)
i18n is great, utf-8 is great, but using non-english languages when hacking free software is not so great -- at least if you want to share your code.
At one point, the macro language used in MS Word (WordBasic or whatever) was translated into Swedish in the Swedish version. Everything was translated, including IF-THEN-ELSE statements etc. It was completely useless.
I'm not sure what gcc would say if you started using non-ascii utf-8 in your variable names though...
Re:Context! Purpose! (Score:2)
Because the common language of kernel hackers is English.
Re:Context! Purpose! (Score:1)
Re:Context! Purpose! (Score:2)
But I digress. You seem to be assuming that "Unicode support" is this magic thing you can add to any program and suddenly support every Unicode character. In fact, no program directly supports the complete Unicode character set -- Unicode was never meant to be used that way. Instead you support an "encoding" that gives you access to a manageable subset of Unicode.
The most widely-used encoding is UTF-16, which supports a 2^16-character subset of Unicode. Most major programming languages support both ASCII and UTF-16. Some (notably Java and Visual Basic) support UTF-16 instead of ASCII. Unfortunately, the documentation for these languages usually refers to their their "wide" characters as "unicode" characters, as if Unicode were just a 16-bit "universal" character set. In fact, there are important Unicode-supported characters that are not in UTF-16.
There's also UTF-8, a variable-width encoding that's backward-compatible with ASCII. I believe GCC already supports UTF-8, and could probably be made to support UTF-16, as most C compilers aready do. And since GCC is written in GCC, you could probably allow kernel programmers to use these extended character sets in their source code. But it's a tricky thing to do [cam.ac.uk], and it's difficult to see the benefit.
I hate the term "politically correct", but maybe it applies here. You seem to feel that any software that isn't character-set-agnostic is unfair to non-Western users. Putting such an assumption ahead of issues of reliability and security is a very poor kind of prioritizing.
Messages, variables (Score:2)
And before you accuse me of being English-centric, note that the guy who invented and still maintains the Linux kernel is not a native English speaker.
Re: (Score:2)
Re:Plan 9 uses Unicode. (Score:2)
Also Don't use any of the M$ products for the Mac because they do not support Unicode at all.
Use OmniWeb for a Web Browser and Just use TextEditor for an word editor.
Also Terminal uses UTF8 for the default encoding, you can change this if you want.
Re:Plan 9 uses Unicode. (Score:2)
much Unix as OpenBSD, Linux, Windows NT/2000/XP are.
Well, I wish OpenBSD hat native UTF-8 - currently it
is totally locale unaware and just makes 8bit==latin-1
assumptions.
This does not mean I want NLS or I18N: localized
error messages, locale in general, LANG= and LC_*=
do suck a lot.
Re:Plan 9 uses Unicode. (Score:2)
The Windows server in Windows NT/2K/XP is part of the kernel while under UN*X, it is an userland program. And also Mac OS X, *BSD are based loosely around the UNIX source. Also Linux is inspired by MINIX which is inspired by UNIX.
Re:Plan 9 uses Unicode. (Score:2)
Re:Plan 9 uses Unicode. (Score:2)
If I remember correctly the "Windows" part of "Windows NT" is simply a "personality" which is hosted under the NT kernel. In the beginning Windows NT wasn't even going to be called "Windows" - it was just "NT". Only part-way through the development of the GUI-agnostic NT kernel, was the Windows personality added on (there was also a short lived OS/2 personality IIRC). So you're statement isn't so accurate. Now perhaps it actually lives in kernel space, or over time has integrated more or less with the kernel proper, but making this claim seems to be a standard "criticism" of NT. For all intents and purposes, operating systems should come with GUIs. I'd be glad if Linux (which is now being pitched as a desktop OS) actually came with real GUI support in the kernel. Or at least shift the video drivers from XFree into the kernel.
Re:Plan 9 uses Unicode. (Score:2)
You might want to look at the kernel framebuffer support. That's exactly what it does. My [somewhat uninformed] understanding of why there are still video drivers in both places is that:
Re:Plan 9 uses Unicode. (Score:1)
The fact that the kernel seems to be a bizzaire mess is not, in my mind, what prevents NT from being a "Unix". Sit me down infront of a system where everything is in the kernel and runs as one big 'file' and I'll call it a Unix if it does what a Unix is supposed to do and does it well. I'll say the programmers need to have their heads extracted by a qualified proctologist and subsequently beat with a sendmail manual, but I'll call it a Unix.
Re:Plan 9 uses Unicode. (Score:1)
Re:Plan 9 uses Unicode. (Score:1)
which emulates a BSD-alike kernel. And it's got
some of the old FreeBSD userland IIRC.
Re:Why (Score:2)
The OS's support arbitrary strings of 8-bit characters, which means they support UTF-8. There is no point in a modern Unix kernel where you would want to use UTF-8, and it won't let you, short of arbitrary hardware or standards limitations (weird foreign filesystems and what not.)
Re:Why (Score:2)
Yes, it's really large. It uses 2.3MB of RAM on my machine, of which, 1.8 or so is shared with other processes. The sad fact is, though, that so is rxvt these days (and indeed, all current terminal emulators). xterm includes a tektronics emulator, amongst other things, which 99% of users will never need (in fact, I'm the only person I know that has ever had a genuine need for it). As a reaction to xterm's size, one of my lecturers at University wrote xvt, a minimal terminal emulator, without the bloat. Over time, that evolved into rxvt, which is growing more and more features, and is no longer as small as it once was. It's still smaller than xterm, but that's not hard. For comparison, opening up a new term uses up the following amount of RAM per new window:
It should be noted that both konsole and gnome-terminal have massive startup costs, with konsole starting up 4 kdeinit processes, and gnome-terminal starting up gnome-pty-helper.
freshmeat has many.... (Score:5, Insightful)
Ask slashdot is becoming increasing ridiculous, with the answer to almost every question found at either google or within OSDN. I don't mean to flame the editors, but it would be good if they would be a little more selective WRT ask slashdot.
Re:freshmeat has many.... (Score:1)
Re:freshmeat has many.... (Score:1)
I'm not *that* dumb.
Re:freshmeat has many.... (Score:1)
gnome-terminal --use-factory (Score:3, Informative)
Why so many xterms? (Score:3, Insightful)
Using screen also helps.
Just try Konsole instead. (Score:1, Insightful)
The shortcut for switching between console is is LShift+RArrow for going to the next console and LShift+LArrow for going to the previous console.
You can name your consoles which is VEY handy. I frequently have 5-6 consoles open and name every one of them. It really helps. A little extra benifit of Konsole is that you can have customized profiles. One for Bash, one for ZSH, one for Midnight Commander, one for
I didn't like it a lot at first but I grew to love it. Now I cant stand terminal programs that aren't like it.
Mikey likes it.
Okay, I'll explain all my reasonings, then. (Score:1)
1) I *like* having $XTERMs scattered everywhere. I use my $XTERMs as a Be-Anywhere-Doing-Anything type tool; ergo, concentrating them in one space would be counterproductive - hence, no tabbing. I'm odd that way.
2) Memory isn't cheap on a laptop. I hate desktop systems. I'm odd that way.
3) Excepting Opera (and it'll go the instant the Moz folks get their heads out of their asses about tabbing through links vs. tabbing through form elements), I want nothing at all to do with Qt. I just don't like it.ÂI more or less tolerate Opera only because I used it back in my Windows days and so am used to it already. I'm odd that way.
4) I tend to leave a lot of terminal windows open to preserve state that may or may not be important. I'm
The suggestion for gnome-terminal --use-factory would probably be best (is Way cool; I never knew about that before), except that gnome-terminal's i18n is broken at the moment.
Such are my motivations for asking. Now You Know.
Re:Okay, I'll explain all my reasonings, then. (Score:1)
Post a 'top' of your system and then everyone here can all get together and critique your memory usage. I'm sure there are other things you can stop using to save an extra K or two, so maybe you can splurge on an extra xterm.
Don't expect other people to care all that much about your particular set of tradeoffs. If you care that much, take the xterm and cut out all the Tektronix graphics and other stuff yourself.
If you are using xterms on multiple desktops, look into just using one and making it sticky.
As far as saving state, nothing beats screen. It saves state even if X dies.
You should get over your irrational problems with Qt also.
You do realize that some of the old folks had to run good old xterms back in dinosaur times, on machines with half as much RAM as your laptop.