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.