|
0
|
1 ## Why does st not handle utmp entries? |
|
|
2 |
|
|
3 Use the excellent tool of [utmp](https://git.suckless.org/utmp/) for this task. |
|
|
4 |
|
|
5 |
|
|
6 ## Some _random program_ complains that st is unknown/not recognised/unsupported/whatever! |
|
|
7 |
|
|
8 It means that st doesn’t have any terminfo entry on your system. Chances are |
|
|
9 you did not `make install`. If you just want to test it without installing it, |
|
|
10 you can manually run `tic -sx st.info`. |
|
|
11 |
|
|
12 |
|
|
13 ## Nothing works, and nothing is said about an unknown terminal! |
|
|
14 |
|
|
15 * Some programs just assume they’re running in xterm i.e. they don’t rely on |
|
|
16 terminfo. What you see is the current state of the “xterm compliance”. |
|
|
17 * Some programs don’t complain about the lacking st description and default to |
|
|
18 another terminal. In that case see the question about terminfo. |
|
|
19 |
|
|
20 |
|
|
21 ## How do I scroll back up? |
|
|
22 |
|
|
23 * Using a terminal multiplexer. |
|
|
24 * `st -e tmux` using C-b [ |
|
|
25 * `st -e screen` using C-a ESC |
|
|
26 * Using the excellent tool of [scroll](https://git.suckless.org/scroll/). |
|
|
27 * Using the scrollback [patch](https://st.suckless.org/patches/scrollback/). |
|
|
28 |
|
|
29 |
|
|
30 ## I would like to have utmp and/or scroll functionality by default |
|
|
31 |
|
|
32 You can add the absolute path of both programs in your config.h file. You only |
|
|
33 have to modify the value of utmp and scroll variables. |
|
|
34 |
|
|
35 |
|
|
36 ## Why doesn't the Del key work in some programs? |
|
|
37 |
|
|
38 Taken from the terminfo manpage: |
|
|
39 |
|
|
40 If the terminal has a keypad that transmits codes when the keys |
|
|
41 are pressed, this information can be given. Note that it is not |
|
|
42 possible to handle terminals where the keypad only works in |
|
|
43 local (this applies, for example, to the unshifted HP 2621 keys). |
|
|
44 If the keypad can be set to transmit or not transmit, give these |
|
|
45 codes as smkx and rmkx. Otherwise the keypad is assumed to |
|
|
46 always transmit. |
|
|
47 |
|
|
48 In the st case smkx=E[?1hE= and rmkx=E[?1lE>, so it is mandatory that |
|
|
49 applications which want to test against keypad keys send these |
|
|
50 sequences. |
|
|
51 |
|
|
52 But buggy applications (like bash and irssi, for example) don't do this. A fast |
|
|
53 solution for them is to use the following command: |
|
|
54 |
|
|
55 $ printf '\033[?1h\033=' >/dev/tty |
|
|
56 |
|
|
57 or |
|
|
58 $ tput smkx |
|
|
59 |
|
|
60 In the case of bash, readline is used. Readline has a different note in its |
|
|
61 manpage about this issue: |
|
|
62 |
|
|
63 enable-keypad (Off) |
|
|
64 When set to On, readline will try to enable the |
|
|
65 application keypad when it is called. Some systems |
|
|
66 need this to enable arrow keys. |
|
|
67 |
|
|
68 Adding this option to your .inputrc will fix the keypad problem for all |
|
|
69 applications using readline. |
|
|
70 |
|
|
71 If you are using zsh, then read the zsh FAQ |
|
|
72 <http://zsh.sourceforge.net/FAQ/zshfaq03.html#l25>: |
|
|
73 |
|
|
74 It should be noted that the O / [ confusion can occur with other keys |
|
|
75 such as Home and End. Some systems let you query the key sequences |
|
|
76 sent by these keys from the system's terminal database, terminfo. |
|
|
77 Unfortunately, the key sequences given there typically apply to the |
|
|
78 mode that is not the one zsh uses by default (it's the "application" |
|
|
79 mode rather than the "raw" mode). Explaining the use of terminfo is |
|
|
80 outside of the scope of this FAQ, but if you wish to use the key |
|
|
81 sequences given there you can tell the line editor to turn on |
|
|
82 "application" mode when it starts and turn it off when it stops: |
|
|
83 |
|
|
84 function zle-line-init () { echoti smkx } |
|
|
85 function zle-line-finish () { echoti rmkx } |
|
|
86 zle -N zle-line-init |
|
|
87 zle -N zle-line-finish |
|
|
88 |
|
|
89 Putting these lines into your .zshrc will fix the problems. |
|
|
90 |
|
|
91 |
|
|
92 ## How can I use meta in 8bit mode? |
|
|
93 |
|
|
94 St supports meta in 8bit mode, but the default terminfo entry doesn't |
|
|
95 use this capability. If you want it, you have to use the 'st-meta' value |
|
|
96 in TERM. |
|
|
97 |
|
|
98 |
|
|
99 ## I cannot compile st in OpenBSD |
|
|
100 |
|
|
101 OpenBSD lacks librt, despite it being mandatory in POSIX |
|
|
102 <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_13>. |
|
|
103 If you want to compile st for OpenBSD you have to remove -lrt from config.mk, and |
|
|
104 st will compile without any loss of functionality, because all the functions are |
|
|
105 included in libc on this platform. |
|
|
106 |
|
|
107 |
|
|
108 ## The Backspace Case |
|
|
109 |
|
|
110 St is emulating the Linux way of handling backspace being delete and delete being |
|
|
111 backspace. |
|
|
112 |
|
|
113 This is an issue that was discussed in suckless mailing list |
|
|
114 <https://lists.suckless.org/dev/1404/20697.html>. Here is why some old grumpy |
|
|
115 terminal users wants its backspace to be how he feels it: |
|
|
116 |
|
|
117 Well, I am going to comment why I want to change the behaviour |
|
|
118 of this key. When ASCII was defined in 1968, communication |
|
|
119 with computers was done using punched cards, or hardcopy |
|
|
120 terminals (basically a typewriter machine connected with the |
|
|
121 computer using a serial port). ASCII defines DELETE as 7F, |
|
|
122 because, in punched-card terms, it means all the holes of the |
|
|
123 card punched; it is thus a kind of 'physical delete'. In the |
|
|
124 same way, the BACKSPACE key was a non-destructive backspace, |
|
|
125 as on a typewriter. So, if you wanted to delete a character, |
|
|
126 you had to BACKSPACE and then DELETE. Another use of BACKSPACE |
|
|
127 was to type accented characters, for example 'a BACKSPACE `'. |
|
|
128 The VT100 had no BACKSPACE key; it was generated using the |
|
|
129 CONTROL key as another control character (CONTROL key sets to |
|
|
130 0 b7 b6 b5, so it converts H (code 0x48) into BACKSPACE (code |
|
|
131 0x08)), but it had a DELETE key in a similar position where |
|
|
132 the BACKSPACE key is located today on common PC keyboards. |
|
|
133 All the terminal emulators emulated the difference between |
|
|
134 these keys correctly: the backspace key generated a BACKSPACE |
|
|
135 (^H) and delete key generated a DELETE (^?). |
|
|
136 |
|
|
137 But a problem arose when Linus Torvalds wrote Linux. Unlike |
|
|
138 earlier terminals, the Linux virtual terminal (the terminal |
|
|
139 emulator integrated in the kernel) returned a DELETE when |
|
|
140 backspace was pressed, due to the VT100 having a DELETE key in |
|
|
141 the same position. This created a lot of problems (see [1] |
|
|
142 and [2]). Since Linux has become the king, a lot of terminal |
|
|
143 emulators today generate a DELETE when the backspace key is |
|
|
144 pressed in order to avoid problems with Linux. The result is |
|
|
145 that the only way of generating a BACKSPACE on these systems |
|
|
146 is by using CONTROL + H. (I also think that emacs had an |
|
|
147 important point here because the CONTROL + H prefix is used |
|
|
148 in emacs in some commands (help commands).) |
|
|
149 |
|
|
150 From point of view of the kernel, you can change the key |
|
|
151 for deleting a previous character with stty erase. When you |
|
|
152 connect a real terminal into a machine you describe the type |
|
|
153 of terminal, so getty configures the correct value of stty |
|
|
154 erase for this terminal. In the case of terminal emulators, |
|
|
155 however, you don't have any getty that can set the correct |
|
|
156 value of stty erase, so you always get the default value. |
|
|
157 For this reason, it is necessary to add 'stty erase ^H' to your |
|
|
158 profile if you have changed the value of the backspace key. |
|
|
159 Of course, another solution is for st itself to modify the |
|
|
160 value of stty erase. I usually have the inverse problem: |
|
|
161 when I connect to non-Unix machines, I have to press CONTROL + |
|
|
162 h to get a BACKSPACE. The inverse problem occurs when a user |
|
|
163 connects to my Unix machines from a different system with a |
|
|
164 correct backspace key. |
|
|
165 |
|
|
166 [1] http://www.ibb.net/~anne/keyboard.html |
|
|
167 [2] http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-5.html |
|
|
168 |
|
|
169 |
|
|
170 ## But I really want the old grumpy behaviour of my terminal |
|
|
171 |
|
|
172 Apply [1]. |
|
|
173 |
|
|
174 [1] https://st.suckless.org/patches/delkey |
|
|
175 |
|
|
176 |
|
|
177 ## Why do images not work in st using the w3m image hack? |
|
|
178 |
|
|
179 w3mimg uses a hack that draws an image on top of the terminal emulator Drawable |
|
|
180 window. The hack relies on the terminal to use a single buffer to draw its |
|
|
181 contents directly. |
|
|
182 |
|
|
183 st uses double-buffered drawing so the image is quickly replaced and may show a |
|
|
184 short flicker effect. |
|
|
185 |
|
|
186 Below is a patch example to change st double-buffering to a single Drawable |
|
|
187 buffer. |
|
|
188 |
|
|
189 diff --git a/x.c b/x.c |
|
|
190 --- a/x.c |
|
|
191 +++ b/x.c |
|
|
192 @@ -732,10 +732,6 @@ xresize(int col, int row) |
|
|
193 win.tw = col * win.cw; |
|
|
194 win.th = row * win.ch; |
|
|
195 |
|
|
196 - XFreePixmap(xw.dpy, xw.buf); |
|
|
197 - xw.buf = XCreatePixmap(xw.dpy, xw.win, win.w, win.h, |
|
|
198 - DefaultDepth(xw.dpy, xw.scr)); |
|
|
199 - XftDrawChange(xw.draw, xw.buf); |
|
|
200 xclear(0, 0, win.w, win.h); |
|
|
201 |
|
|
202 /* resize to new width */ |
|
|
203 @@ -1148,8 +1144,7 @@ xinit(int cols, int rows) |
|
|
204 gcvalues.graphics_exposures = False; |
|
|
205 dc.gc = XCreateGC(xw.dpy, parent, GCGraphicsExposures, |
|
|
206 &gcvalues); |
|
|
207 - xw.buf = XCreatePixmap(xw.dpy, xw.win, win.w, win.h, |
|
|
208 - DefaultDepth(xw.dpy, xw.scr)); |
|
|
209 + xw.buf = xw.win; |
|
|
210 XSetForeground(xw.dpy, dc.gc, dc.col[defaultbg].pixel); |
|
|
211 XFillRectangle(xw.dpy, xw.buf, dc.gc, 0, 0, win.w, win.h); |
|
|
212 |
|
|
213 @@ -1632,8 +1627,6 @@ xdrawline(Line line, int x1, int y1, int x2) |
|
|
214 void |
|
|
215 xfinishdraw(void) |
|
|
216 { |
|
|
217 - XCopyArea(xw.dpy, xw.buf, xw.win, dc.gc, 0, 0, win.w, |
|
|
218 - win.h, 0, 0); |
|
|
219 XSetForeground(xw.dpy, dc.gc, |
|
|
220 dc.col[IS_SET(MODE_REVERSE)? |
|
|
221 defaultfg : defaultbg].pixel); |
|
|
222 |
|
|
223 |
|
|
224 ## BadLength X error in Xft when trying to render emoji |
|
|
225 |
|
|
226 Xft makes st crash when rendering color emojis with the following error: |
|
|
227 |
|
|
228 "X Error of failed request: BadLength (poly request too large or internal Xlib length error)" |
|
|
229 Major opcode of failed request: 139 (RENDER) |
|
|
230 Minor opcode of failed request: 20 (RenderAddGlyphs) |
|
|
231 Serial number of failed request: 1595 |
|
|
232 Current serial number in output stream: 1818" |
|
|
233 |
|
|
234 This is a known bug in Xft (not st) which happens on some platforms and |
|
|
235 combination of particular fonts and fontconfig settings. |
|
|
236 |
|
|
237 See also: |
|
|
238 https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6 |
|
|
239 https://bugs.freedesktop.org/show_bug.cgi?id=107534 |
|
|
240 https://bugzilla.redhat.com/show_bug.cgi?id=1498269 |
|
|
241 |
|
|
242 The solution is to remove color emoji fonts or disable this in the fontconfig |
|
|
243 XML configuration. As an ugly workaround (which may work only on newer |
|
|
244 fontconfig versions (FC_COLOR)), the following code can be used to mask color |
|
|
245 fonts: |
|
|
246 |
|
|
247 FcPatternAddBool(fcpattern, FC_COLOR, FcFalse); |
|
|
248 |
|
|
249 Please don't bother reporting this bug to st, but notify the upstream Xft |
|
|
250 developers about fixing this bug. |
|
|
251 |
|
|
252 As of 2022-09-05 this now seems to be finally fixed in libXft 2.3.5: |
|
|
253 https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/libXft-2.3.5/NEWS |
