Re: SDL terminal type

On Sat, 22 Aug 2026 at 18:08, Po Lu <[email protected]> wrote:

> > I have never had any problem with C-> on PGTK Emacs. Is there a bug
> > report describing how to reproduce this problem? Maybe people should
> > stop repeating this rumor, if it is not true.
>
> It is true, or there would not be an item for both of these cases in
> etc/PROBLEMS.


I find the text a bit vague. "This is known to happen", "we are told"...
Where does it happen, in which environment? Who told? With no proper bug
report containing a recipe on how to reproduce this problem I don't see
what else anybody can do but to submit to the authority of the PROBLEMS
file.

The PROBLEMS file entry from 2022 is not entirely correct. Here are the
relevant parts:

Some keys with modifiers such as Shift and Control might not be
> reported correctly due to incorrectly written GTK input method
> modules.  This is known to happen to 'C-S-u' and 'C->', which are
> misreported as 'C-u' and '>'.
>
> To disable the use of GTK input methods, evaluate:
>   (pgtk-use-im-context nil)


C-S-u is reported as C-u only if I evaluate (pgtk-use-im-context nil). If
not, the Unicode hex input method is triggered. When placed right after the
text describing the problems with the shift modifier, the advice to disable
the use of GTK input methods seems to imply that it is a fix for these
problems, but that is not the case. The Elisp code only disables the
special handling of C-S-u; the problem with the missing shift modifier is a
different issue.

With the Unicode input method disabled, describe-key reports the following
for C-S-u:

C-u (translated from C-S-u) runs the command universal-argument (found
> in global-map), which is an interactive native-comp-function in
> ‘simple.el’.


Note the "translated from C-S-u". Emacs knows about the shift modifier, but
it is only available in the raw keyboard event.

Later in 2025 the following paragraph was added to etc/PROBLEMS:

We are told that 'C-S-u' is misinterpreted due to the GTK "feature"
> whereby 'C-S-u' is used to input characters by their Unicode codepoints,
> and that this can be changed or turned off using the 'ibus-setup'
> program under the Emoji tab, or by changing the setting of the dconf key
> 'org.freedesktop.ibus.panel.emoji'.


Besides the opinionated wording ("feature"), the text blames GTK for the
handling of C-S-u. This key combination is a de facto standard for
Unix-like operating systems. From Wikipedia
<https://en.wikipedia.org/wiki/Alt_code>: "However, numeric entry of
Unicode characters is possible in most Unix or Unix-like OSs by pressing
and releasing Ctrl+⇧ Shift+U, and typing the hex number followed by the
space bar or enter key." This key combination is the Unix equivalent to the
MS-DOS/Windows Alt-numpad entry style.

The text also seems to be written for some specific desktop environment
(GNOME?), talking about the "Emoji tab" (where?) and dconf keys. As far as
I understand, the same thing can be accomplished with the
(pgtk-use-im-context nil) as above, and doing it this way restricts the
effect to Emacs and not every other application on the machine. Thus, the
old text could be clarified to explain the situation better, and the new
text could be axed.