Re: Terminal - a good terminal?
Eduard Bloch wrote:
> * Jeff Teunissen [Thu, Oct 07 2004, 09:10:56AM]:
[snip]
> > > Who said that the "linux" console is a good kind of terminal
> > > emulation?
> >
> > It's what's expected.
>
> By whom?
By people who spend a lot of time at the console?
> > We could do just about any other type, including graphics terminals,
> > but TERM=linux is decent and simple.
>
> And primitive. And unuseable or not so comfortable when opening a shell
> on non-Linux system.
Primitive? heh. And as for the rest, I haven't had trouble -- it's just an
infocmp away. In any case, switching the emulation is trivial -- it's not
like terminal emulation is complicated.
> > > meta-keys in UTF-8 mode? Only after manual configuration.
> >
> > Not true -- OpenStep has an extra modifier key.
> >
> > Command is bound to the Alt_L keysym by default in gnustep-gui.
> > Alternate is by default bound to Alt_R. A different program lets you
> > easily set which keysyms get bound to the various modifiers.
> >
> > Alternate always does "meta". Command usually is grabbed for key
> > equivalents in the menus. The option to set Command as meta overrides
> > this. The option was created because on some configurations the right
> > Alt key changed its keysym to ISO_Level3_Shift or some other such
> > nonsense.
>
> I do not know which nonsence you mean but I do not have something
> special, just default Debian GNU/Linux environment and there it did not
> work. I had to set this switch.
Yeah, it was implemented for broken environments.
( /me grins and hides from overfiend :) )
Did you try using the right Alt key? If you did try it and it didn't work,
then X isn't reporting it as Alt_R, so -gui isn't telling the app that the
Alternate modifier is set.
Again, it's not an X program, it just happens to work when rigged with a GUI
backend that uses X.
And there's no such thing as a "default" X config.
[snip]
> It does not print anything useful when executed with -h or --help. It
> just ignores these options, that is not a very userfriendly behaviour,
> IMHO.
Because you're not supposed to execute it directly -- that's why it's not in
the PATH.
There are plenty of options when creating a new window, but they are not
available from the commandline (and won't be, until I create the tool to
exercise them).
[snip]
> > > UTF-8 support? Lousy or none. One has to choose it manually (and it
> > > supports only few encoding anyways).
> >
> > It can support more by just adding a couple of lines to the popup
> > button; GNUstep does all of its string handling in UTF-16 internally.
>
> Add more? It does not support UTF-8 well.
It supports UTF-8 fine, as long as it can get the glyphs.
[snip]
> Yeah. And a sane Unicode compatible terminal would try fallback to
> similar fonts. That is what Rxvt-Unicode or Gnome-Terminal do. Of course
> you can use the "missing in this font" excuse, but then you should made
> at least the font selector work. Currently, I see only four fonts there,
> and the selecting another one is either not stored, or has no effect.
I only get a few bad-glyph markers when I cat the UTF-8-demo. Well, except
for the Ethiopian sample, for which my 10646-1 terminal font has no glyphs.
And it's not the terminal, it's the GNUstep GUI backend (gnustep-back)
that's failing to do glyph substitution and coercion. Of course, there are
problems with font substitution that make it a pain in the ass when you have
a PostScript display model. e.g. since it's supposed to be WYSIWYG
throughout, doing substitution in the app isn't always going to result in
the same thing going onto the paper, so to DTRT means a lot more work. But
hey, who cares about that? I WANT MY TEXT.
It's not my fault that or whoever did the font setup for gnustep-back didn't
set the default fixed-width font to something reasonable for Unicode...but
then, the default character coding is Latin 1.
> > The ART backend graphics target's glyph generator doesn't currently do
> > glyph combining or font substitution, though the latter is apparently
> > in progress.
>
> Then please don't call it UTF-8 capable before it really supports most
> of it.
It does, and many other Unicode systems don't handle UTF-8 glyph-combining
either. But it's being worked on.
> > > Choosing the "Handle widht-chars" option has broken the output
> > > completely.
> >
> > Works here, what backend and font were you using?
>
> What is a "backend"? I just assumed what other people said and started
> it with defaults.
Well, I don't know what the default gnustep-gui backend is on Debian.
[snip]
> > > Italic font support? No.
> >
> > For what? There isn't an italic display command. Though I suppose we
> > could overload the blink bit to set italic, it hardly seems proper.
>
> Some applications (vim) support it with proper terminfo entry (not
> "linux").
Maybe it would help if you gave me the name of a sane terminfo entry that
has an "italic/oblique" display command.
--
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project http://www.quakeforge.net/
| Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Reply to: