Would it be sensible and acceptable to have xterm default to
using the encoding of the user's locale at startup? Seems to be
several ways of forcing UTF-8 to on, however I'm curious why it
doesn't just detect the locale by default and use UTF-8 if in a
.UTF-8 locale.
If this sounds like a goo
On Wed, Feb 19, 2003 at 11:09:57AM -0500, Mike A. Harris wrote:
> Would it be sensible and acceptable to have xterm default to
> using the encoding of the user's locale at startup? Seems to be
only if you happen to be running redhat 8.x
--
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible
On Wed, Feb 19, 2003 at 11:28:11AM -0500, Thomas Dickey wrote:
> On Wed, Feb 19, 2003 at 11:09:57AM -0500, Mike A. Harris wrote:
> > Would it be sensible and acceptable to have xterm default to
> > using the encoding of the user's locale at startup? Seems to be
>
> only if you happen to be runn
On Wed, Feb 19, 2003 at 11:09:57AM -0500, Mike A. Harris wrote:
> Would it be sensible and acceptable to have xterm default to
> using the encoding of the user's locale at startup? Seems to be
> several ways of forcing UTF-8 to on, however I'm curious why it
> doesn't just detect the locale by
On Wed, Feb 19, 2003 at 08:53:14PM +0100, Thomas Zander wrote:
> I've heard the same discussion on KDE lists. And as on KDE the point
> is that the whole system has to be utf-8 to work correctly.
Close -- the way Red Hat 8 is set up, it seems like the whole world
needs to be UTF8 :/
This is an ex
On Wed, Feb 19, 2003 at 11:32:26AM -0500, Jeff Garzik wrote:
>
> TBH there are really two problems here.
>
> In my opinion, Red Hat 8's UTF8 support definitely needs work... ssh
> into a redhat box and run "man ", and watch it display poorly
> due to incorrect UTF8 assumptions. There are clearly
On Wed, Feb 19, 2003 at 04:40:48PM -0500, Matt Wilson wrote:
> stored in ~/.i18n). ssh does not transmit the current locale of the
> machine you're coming from (nor should it - it could be different if
> you're coming from a Solaris box into a RHL 8.0 box).
That is indeed part of the problem, tha
On Wed, 19 Feb 2003, Thomas Dickey wrote:
>> Would it be sensible and acceptable to have xterm default to
>> using the encoding of the user's locale at startup? Seems to be
>
>only if you happen to be running redhat 8.x
I'd like to know what problems are caused by autodetecting the
user's loc
On Wed, Feb 19, 2003 at 03:48:02PM -0500, Jeff Garzik wrote:
> On Wed, Feb 19, 2003 at 08:53:14PM +0100, Thomas Zander wrote:
> > Its news to me that a locale can specify that its utf-8, since I always
> > thought that locales don't define encodings.
>
> It's news, then :)
>
> You can specify "en
Thomas Zander <[EMAIL PROTECTED]> writes:
> > You can specify "en_US.UTF-8" as your locale. Which implies to me that
> > xterm can recognize, from its environment, the encoding, and act
> > accordingly.
>
> Hope you aren't using the locale standard 'Variation' variable for
> that; in most europe
On Wed, 19 Feb 2003, Mike A. Harris wrote:
> On Wed, 19 Feb 2003, Thomas Dickey wrote:
>
> >> Would it be sensible and acceptable to have xterm default to
> >> using the encoding of the user's locale at startup? Seems to be
> >
> >only if you happen to be running redhat 8.x
>
> I'd like to know w
On Thu, Feb 20, 2003 at 10:57:23AM +0100, Gerd Knorr wrote:
> Thomas Zander <[EMAIL PROTECTED]> writes:
>
> > > You can specify "en_US.UTF-8" as your locale. Which implies to me that
> > > xterm can recognize, from its environment, the encoding, and act
> > > accordingly.
> >
> > Hope you aren't
Thomas Zander <[EMAIL PROTECTED]> writes:
> Not true; the locale is nothing more then a pointer to the i18n and l10n
> specific for that person using the computer.
> Naturally the l10n implies certain things like currency, date format etc.
> The nl_NL@EURO has a variant to change one aspect of the
On 20 Feb 2003, Gerd Knorr wrote:
>> Knowing my locales; encondings should not be in a locale! (Since the
>> user can override them)
>
>The encoding _is_ in the locale. Allowing the user to override it is
>a design bug (de_DE@euro with iso-8859-1 isn't going to work ...).
>Use the correct locale
On Thu, 20 Feb 2003, Thomas E. Dickey wrote:
>> >> Would it be sensible and acceptable to have xterm default to
>> >> using the encoding of the user's locale at startup? Seems to be
>> >
>> >only if you happen to be running redhat 8.x
>>
>> I'd like to know what problems are caused by autodetecti
On Thu, Feb 20, 2003 at 06:32:56PM +0100, Gerd Knorr wrote:
> Thomas Zander <[EMAIL PROTECTED]> writes:
> > Conclusion;
> > An xterm should be able to display chinese if man or ls outputs that,
>
> That works just fine if xterm and applications use the same charset.
> And exactly thats why xterm s
"Mike A. Harris" <[EMAIL PROTECTED]> writes:
> >And, yes, of course xterm should start up in utf-8 mode if the locale
> >encoding is UTF-8.
>
> Thanks, that was my original conclusion also. I had just
> wondered why it doesn't. Just an xterm bug I guess.
Recent xterm versions do exactly that.
On Thu, Feb 20, 2003 at 10:30:43PM +0100, Thomas Zander wrote:
> Whatever the solution its a bug in ssh, not X.
> I have the opinion that forwarding does not solve all problems (since one of
> the machines may not know about utf8) so ssh could better convert the data
> stream using the different lo
> You can specify "en_US.UTF-8" as your locale. Which implies
> to me that xterm can recognize, from its environment, the
> encoding, and act accordingly.
Which only encourages the sort of bugs that many an autoconf
script has had, that assumes because iconv() doesn't accept
UTF-8 as a valid str
Thomas Zander <[EMAIL PROTECTED]> writes:
> I am wondering how xterm should handle different shells (using screen for
> example). The perfect-world-solution would be to ask the bash its env-var
> at every printf, but that may prove to not really be feasable..
xterm can be switched from and to utf
>> And, yes, of course xterm should start up in utf-8 mode if the locale
>> encoding is UTF-8.
MH> Thanks, that was my original conclusion also. I had just
MH> wondered why it doesn't. Just an xterm bug I guess.
*locale: true
(Credit to Tomohiro Kubota.)
JG> Though I disagree that ssh should not transmit the current locale: it
JG> _should_, precisely because it could be different coming from Solaris,
JG> or Debian, or Windows, and you want to make sure both sides agree on
JG> the encoding. Of course, this also assumes that there is some suitable
J
On Thu, Feb 20, 2003 at 01:50:40PM -0800, Kean Johnston wrote:
> > You can specify "en_US.UTF-8" as your locale. Which implies
> > to me that xterm can recognize, from its environment, the
> > encoding, and act accordingly.
> Which only encourages the sort of bugs that many an autoconf
> script
Juliusz Chroboczek <[EMAIL PROTECTED]> さんは書きました:
>>> And, yes, of course xterm should start up in utf-8 mode if the locale
>>> encoding is UTF-8.
>
> MH> Thanks, that was my original conclusion also. I had just
> MH> wondered why it doesn't. Just an xterm bug I g
> There's a "libcharset" that I think comes with libiconv and
> is also used in GLib that you can use to work around this problem.
Which is fine if you use GNU iconv. For those of us that use
the iconv as it was originally invented, libcharset doesn't
seem to help very much. Maybe I am missing wha
On Fri, Feb 21, 2003 at 09:47:01AM -0800, Kean Johnston wrote:
> defined conversions are used first, and for all those Linux-centric
> applications that are so badly written to really only support one
> OS now "just work".
s/all those/many of the/
--
Thomas E. Dickey <[EMAIL PROTECTED]>
http://i
On Fri, 2003-02-21 at 12:47, Kean Johnston wrote:
> > There's a "libcharset" that I think comes with libiconv and
> > is also used in GLib that you can use to work around this problem.
> Which is fine if you use GNU iconv. For those of us that use
> the iconv as it was originally invented, libchar
> > defined conversions are used first, and for all those Linux-centric
> > applications that are so badly written to really only
> support one OS
> > now "just work".
>
> s/all those/many of the/
Beg pardon for the ambiguity. I meant all of the badly written
applications, not all Linux applica
> The GLib library (used by GTK+, GNOME, etc) works around this
> by using the libcharset data in both directions ... as well
> as getting a standardized form of encodings reported by the
> operating system, it will use it convert standardized names
> into names that are likely to work for icon
On Fri, Feb 21, 2003 at 09:47:01AM -0800, Kean Johnston wrote:
> defined conversions are used first, and for all those Linux-centric
> applications that are so badly written to really only support one
> OS now "just work".
I'm sure it gives you a hardon to bash Linux, but
you're being intellectual
> I'm sure it gives you a hardon to bash Linux, but
> you're being intellectually dishonest.
For openers, sexual references are inappropriate. This is a
list of professionals, and it ill behoves you to not treat
us that way.
Secondly, I was in *NO WAY* bashing Linux. I am a HUGE fan
of open source
31 matches
Mail list logo
