lkml.org 
[lkml]   [1997]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Default character set of the Linux console
Date
From
>>>>> "Qrczak" == Qrczak  writes:

Qrczak> #define terminfo terminfo and termcap

Qrczak> Yes, I use this method now. But I treat this as a temporary
Qrczak> solution until terminfos distributed with new Linuxes are changed
Qrczak> this way.

Yes. But still this is userland problem.

Qrczak> Now the situation is not clear and some programs could
Qrczak> reset the terminal with terminfo sequence assuming that it will
Qrczak> reset the map (officially it still should reset the map, yes?), and

No. Tty mapping hasn't standardized in UN*X, so any application
relying on terminfo on changing mapping have to be declared broken.

Qrczak> other may use direct ESCc although it would be better to leave the
Qrczak> custom map active.

Why will they do that?

Qrczak> Maybe there are very few cases where this can
Qrczak> cause problems, but for me this needs some clarification. It seems
Qrczak> to work now, at least for programs using terminfo (logout resets
Qrczak> the map even after fixing terminfo).

Is it? Never checked, but it should be trivial to check, which
terminfo capability does it use. There are several init strings in
(#undef terminfo) terminfo, and I'm not sure how applications are
supposed to use them. Just in case I'd add \e(K to all of them.

Qrczak> I would be happy enough if it becomes the "official" way for doing
Qrczak> this - if I could say that the assumption that resetting with
Qrczak> terminfo rs1 sequence will reset the map is obsolete, and if good

In fact, where exactly does this assumption came from? I never saw
any definitions of it.

Qrczak> programs _had to_ use terminfo instead of direct ESCc (this is
Qrczak> probably true now).

Yes.

Qrczak> Probably one source of these problems is that many console settings
Qrczak> are write-only. Programs can't simply check them, set their own
Qrczak> values, use them and restore the previous state at the end. If
Qrczak> programs only _could_ restore various settings, maybe resetting the
Qrczak> terminal would be less important - now there is greater chance that
Qrczak> a program would leave bad settings, because it can't read the old
Qrczak> ones. There is even no simply check if console is in Unicode mode,
Qrczak> and programs in console-tools package do this by outputting three
Qrczak> bytes and checking how much the cursor had moved! This is obvious

Horrible :)

Qrczak> that knowing the state of Unicode mode is often important. Maybe
Qrczak> future terminals should allow reading of some settings?

Should be trivial to extend linux console code to do that, any
takers? :)

--
Best regards, -- Boris.

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.075 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site