1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Here's a list of problems you might encounter. There usually isn't a
satisfactory solution, but at least you won't live in ignorance.
1. Terminal emulator doesn't set WINDOWID
Most terminal emulators set that environment variable for you. It
contains a number which uniquely identifies terminal's X window.
Slrnface needs it to know which window the terminal emulator is using
and cannot operate without this information.
If your terminal emulator doesn't set this variable, you're out of luck.
You can set it manually, but it's a cumbersome procedure:
a) Start "xwininfo"
b) Click somewhere in the terminal window
c) You'll get several lines of output. The first one will be something
like:
xwininfo: Window id: 0x900003 "xterm"
That's your window identifier. Put it in the environment variable.
For sh compatible shells:
WINDOWID=0x900003; export WINDOWID
For csh compatible shells:
setenv WINDOWID 0x900003
Slrnface should be happy now, but I suppose this isn't a procedure you'd
like to execute often. You might try to upgrade to the newer version of
the terminal emulator, if there is one, in hope that it got this
feature. If that proves to be futile, the only remaining option is to
use another terminal emulator.
2. WINDOWID is not forwarded along telnet/rlogin/ssh/whatever session
For a start, read the documentation for your client program. It might
have an option to forward environment variables. For example, some
telnet clients can be asked to do that in ~/.telnetrc file.
If your client has this feature and you've told it to use it, but it
still doesn't work, perhaps the server doesn't support it. In that case
you're out of luck.
Most notably, OpenSSH cannot forward environment variables. You might
try to do something like:
ssh -t user@remotehost "export TERM=$TERM; export WINDOWID=$WINDOWID; slrn"
but that will only start a remote slrn session, not the shell session.
You might get around the problem if you write a wrapper for your
communication command. Since most of the communication protocols and
tools support forwarding the TERM variable, you could overload it with
the WINDOWID info. For example, the wrapper could set it to
$WINDOWID::$TERM before invoking the real command. Then your shell
startup script on the server side should check if the TERM variable
contains "::", and if so, initialize both WINDOWID and TERM to the
proper components. It's messy, but it works.
And, of course, you could mail OpenSSH folks and nicely ask them to
do something about environment variable forwarding.
3. X resources don't have any effect
It could be a bug in slrnface or it could be a buggy terminal emulator.
Slrnface is somewhat equipped to work around problematic terminals, but
the support is far from ideal. The problem comes from the way certain
terminals identify themselves to the X Window system. To check if your
terminal has a problem, execute:
xprop | grep WM_CLASS
and click on the terminal window. You might get something like:
WM_CLASS(STRING) = "Eterm 0.9.2", "Eterm"
The dot in any of those strings is a problem. X resources use dots (as
well as stars and question marks) as separators between fields. When
slrnface asks for a resource property, it first constructs the full
resource name from the name which terminal window has registered with
the window system and the property name its interested in. So with the
above example, the full name might be "Eterm 0.9.2.slrnface.xOffsetChar".
Then it calls certain X function which retrieves the value. But the poor
X function is utterly confused with this and usually won't return a
match, no matter what you try to do.
Even worse are terminal emulators which can open several windows from a
single process, but then they give them different names, such as
"Terminal.0", "Terminal.1" and so on.
In case when X resource matching function doesn't return a match,
slrnface will take a look at the command line arguments and use the
values set there[1]. That might be good enough for you. If you're using
slrnface with slrn, you can just edit the S-Lang script and add command
line options for the slrnface invocation. If you want to make it work
with different broken terminals, you'll have to read them from a file, I
suppose. In case you are using slrnface with mutt, you'll have to edit
the mutt patch and recompile mutt.
In any case, don't forget to send the bug report the the terminal
maintainers.
[1] Normally, that same X function takes care of the command line
arguments too, so X applications don't have to process them, but the
poor function gets so much confused with this business that it
completely ignores them. So slrnface code base had to grow somewhat.
4. slrn and slrnface don't agree about color shades
Suppose you configured slrn to show certain kind of text in red and you
configured slrnface to paint X-Faces in red. Chances are that those two
red colors won't look the same. Almost, but not quite.
Color terminals usually have 8 or 16 colors. There is no good reason for
this limitation and terminfo capability base provides ways for a terminal
to advertise most of the features you can think of, but most terminal
emulators just don't implement nice features.
Sometimes users can configure the colors, but not always. When you can
configure them, it's usually by using X resources or by storing the
values in some file. If you don't configure them, the terminal will use
hard-coded fallback values.
If the color values are in a file, slrnface has no way to know which
file and what the format might be. If the X resources are used, slrnface
has no way to know the names of those resources. If the user hasn't
configured anything, slrnface has no way to know which defaults were
used when the terminal application was compiled.
So slrnface cannot adjust itself to the terminal. Instead, slrnface is
using the color database which is supposed to be used by all X
applications. The mapping from color names to RGB values is usually
stored in a file called rgb.txt[2], somewhere in your X directories. X
server knows where it is and all applications are supposed to ask X
server about the mapping, so all applications should show the same shade
when the user asks for "red".
If you can configure the colors used by your terminal, you have a good
chance that "red" will mean the same shade it means to slrnface. If you
keep using the defaults, tough luck.
[2] Some systems also use a file called Xcms.txt for device independent
color schemes, but that also doesn't help us.
|
