Call get_window_title() at most once per terminal, even if it fails.
If ELinks is configured with X11 support, get_window_title() calls
XOpenDisplay(), which can sleep if $DISPLAY does not respond.
This delay was previously incurred every time ELinks changed the
title. Besides, if ELinks had already changed the title, setting
ditrm->orig_title = get_window_title(); did not make sense anyway.
(cherry picked from elinks-0.12 commit 5d4beadc4b)
Conflicts:
src/terminal/kbd.c:
get_window_title has a codepage parameter in 0.13.GIT.
gnome-terminal 2.30.2 expects UTF-8 in the "OSC Ps ; Pt BEL" sequence
that sets the window title. However, XGetWMName typically returns the
title in "STRING" (Latin-1) or "COMPOUND_TEXT" (escape sequences)
encoding. Recode the title to restore it correctly. This helps
especially in the fi_FI.UTF-8 locale, where gnome-terminal has "Pääte"
as the default title.
Related to bugs 885 and 336.
When ELinks runs in an X11 terminal emulator (e.g. xterm), or in GNU
Screen, it tries to update the title of the window to match the title
of the current document. To do this, ELinks sends an "OSC 1 ; Pt BEL"
sequence to the terminal. Unfortunately, xterm expects the Pt string
to be in the ISO-8859-1 charset, making it impossible to display e.g.
Cyrillic characters. In xterm patch #210 (2006-03-12) however, there
is a menu item and a resource that can make xterm take the Pt string
in UTF-8 instead, allowing characters from all around the world.
The downside is that ELinks apparently cannot ask xterm whether the
setting is on or off; so add a terminal._template_.latin1_title option
to ELinks and let the user edit that instead.
Complete list of changes:
- Add the terminal._template_.latin1_title option. But do not add
that to the terminal options window because it's already rather
crowded there.
- In set_window_title(), take a new codepage argument. Use it to
decode the title into Unicode characters, and remove only actual
control characters. For example, CP437 has graphical characters in
the 0x80...0x9F range, so don't remove those, even though ISO-8859-1
has control characters in the same range. Likewise, don't
misinterpret single bytes of UTF-8 characters as control characters.
- In set_window_title(), do not truncate the title to the width of the
window. The font is likely to be different and proportional anyway.
But do truncate before 1024 bytes, an xterm limit.
- In struct itrm, add a title_codepage member to remember which
charset the master said it was going to use in the terminal window
title. Initialize title_codepage in handle_trm(), update it in
dispatch_special() if the master sends the new request
TERM_FN_TITLE_CODEPAGE, and use it in most set_window_title() calls;
but not in the one that sets $TERM as the title, because that string
was not received from the master and should consist of ASCII
characters only.
- In set_terminal_title(), convert the caller-provided title to
ISO-8859-1 or UTF-8 if appropriate, and report the codepage to the
slave with the new TERM_FN_TITLE_CODEPAGE request. The conversion
can run out of memory, so return a success/error flag, rather than
void. In display_window_title(), check this result and don't update
caches on error.
- Add a NEWS entry for all of this.
This patch prevents handle_itrm_stdin() and clear_handlers(itrm->in.std) to be
called when -remote is set and in.std < 0.
It adds two assertions for in.std >= 0 in handle_itrm_stdin() and
unhandle_itrm_stdin().
May be a bad fix, please test and review.
[Added a NEWS entry. --KON]
When setting the tty device to raw mode, save the VERASE character.
Later, compare incoming bytes to that.
This is somewhat complicated because "stty verase undef"
sets termios.c_cc[VERASE] = _POSIX_VDISABLE, and e.g. Linux
defines _POSIX_VDISABLE as 0 but that must not cause ELinks
to treat incoming null bytes as backspaces. Furthermore,
some systems may use different VDISABLE values for different
terminal devices, in which case _POSIX_VDISABLE is undefined
and ELinks must instead read the value from fpathconf().
When returning from an external program, unblock_itrm_x in the slave process will send a resize event to the master process for the slave terminal. In handle_interlink_event, when we receive this resize event, we can check whether we need to call textarea_edit.
Added EVENT_TEXTAREA used to notify the master terminal
about end of execution of an external program on a slave terminal.
The format of data sent to the master terminal by exec_on_slave_terminal
has changed. Now after 0, fg the value of term is sent.
Therfore this release of ELinks is incompatible with previous releases.
Patch by Witold Filipczyk, taken from his witekfl branch.
Conflicts:
src/viewer/text/textarea.c
The previous version assumed the first non-digit after the CSI was the
Final Byte, for example the first semicolon in the "\E[?1;2c" report.
It then treated all subsequent bytes as typed characters.
According to Standard ECMA-48 (Fifth Edition - June 1991), there may
be any number of Parameter Bytes in the range 0x30 to 0x3F, and then
any number of Intermediate Bytes in the range 0x20 to 0x2F, between
the CSI and the Final Byte.
This version still does not support control sequences longer than
ITRM_IN_QUEUE_SIZE bytes.
Actions can now be bound to e.g. Ctrl-Alt-A. The keybinding code also
supports other combinations of modifiers, like Shift-Ctrl-Up, but the
escape sequence decoder doesn't yet.
Don't let Ctrl-Alt-letter combinations open menus.
There is no need to check whether ev->ev == EVENT_KBD;
if decode_terminal_escape_sequence called
decode_terminal_mouse_escape_sequence, then the former neither modified
kbd.key nor passed &kbd to the latter, so kbd.key remains KBD_UNDEF.
If ev->ev was not checked, then it should not be trusted either.
So reinitialize the whole *ev if a keyboard event was indeed found.
Also list the capnames with which the escape sequences could be
read from Terminfo, and the ECMA-48 interpretations of the bytes
(parenthesized if they seem unrelated to the keys). This is in
preparation for fixing bug 96.
decode_terminal_escape_sequence() used to handle both, but
there is now a separate decode_terminal_application_key()
for ESC O. I have not yet edited decode_terminal_escape_sequence();
there may be dead code in it.
If there is e.g. ESC [ in the input buffer, combine that to Alt-[.
Check the first character too; don't blindly assume it is ESC, as
it can be NUL as well. Note this means you can no longer activate
the main menu by pressing Ctrl-@ (or Ctrl-Space on some terminals).
Otherwise, the timeout could cause ELinks to resume reading from
the terminal device while another process is still using it.
This actually happened in a test.
On entry to some functions that could resume reading from the device,
assert that the terminal has not been blocked.
