support for ESC % G

[Marc Lehmann]

On Mon, Apr 19, 2010 at 10:01:30AM +0200, Michal Svoboda <michal.svoboda at agents.felk.cvut.cz> wrote:
> > The solution for your problem is to use the correct TERM setting,
> > obviously.
> 
> This is somewhat dubious attitude since as I said urxvt already contains
> some compatibility features that go beyond what is strictly necessary
> for TERM=rxvt-unicode. How is this feature different?

I know of no such compatibility features - but you surely know better...

> > > Try echoing ESC % @ and catting an utf8 file, then the same with ESC
> > > % G.
> > 
> > Well, try it yourself, obviously the locale of cat or other programs
> > will be the same as before (including what they might or might not
> > think about e.g. character width).
> 
> Yes. I don't know how the term 'locale' got incorporated here.

By urxvt, which supports locales...

> sequence is about switching encodings.

...and not encodings.

locales contain a lot more info, for example, the width of each character,
which is crucial to know.

> With % @ it will treat incoming bytes as in latin1, with % G as in utf8.

Yes, and fails to work with unicode.

Urxvt is supposed to be a terminal that gives some support for unicode
beyond latin1 - if you just want utf-8 encoded latin1, then the linux
console is great.

> Obviously you should use % G if you want to run a program that uses the
> utf8 locale on the console fd, otherwise you'll get 2 or more gibberish
> chars for each non-ascii one.

There are many utf-8 locales, often they are incompatible with each
other. IF you know an algorithm that maps esc % G on a locale, speak up.

> I believe urxvt derives its input encoding from the current locale
> setting

Yes.

> so it already should support either encoding at launch time.

If the current locale is not utf-8, it cannot "derive" utf-8 from it. It
makes no sense.

> Making the encoding run-time switchable via the esc sequence shouldn't
> be too hard.

It already is, by using the lcoale mechanism, which a) works and b)
provides the necessary info.

> > Yes, and if you sent it control codes specific to hp terminals, it
> > will also not support it.
> 
> How many users have requested compatibility with hp terminals recently?

Two so far (that was a while ago), which is 100% more users than people
who wanted compatibility with the linux terminal :)

> > It's printed only on deliberately misconfigured systems, i.e. yours.
> 
> I don't see how my terminal is misconfigured.

rxvt-unicode, as thre name implies, is an rxvt-unicode terminal. The only
correct configuration is to use TERM=rxvt-unicode. TERM=rxvt is supported
to some extent, as is vt100, ansi, xterm and even linux to a much lesser
degree. Using any of those is still a misconfiguration *by definition.*

> In fact it is pretty well configured to match the behavior of the
> 'linux' term.

For somebody with almost nonexistant requirements sure, but if you lower your
requirements enough, then TERM=hp2616 is also supported and not a
misconfiguration.

In case you don't realise it, you are making a clown out of yourself right
now.

> terminal programs that don't have that much configuration options. I'm
> using (u)rxvt for what? 10+ years specifically because of this.

That's impsosible - you can't use rxvt or urxvt for it's support for
TERM=linux, precisely because neither rxvt nor urxvt supports it.

Youc na still use rxvt or urxvt on your totally misconfigured system, but you
need to keep in mind that your problems are your problems to keep - the fix
for your problems is to properly configure rxvt or urxvt :)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\