Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync with upstream #143

Merged
merged 19 commits into from
Mar 16, 2022
Merged

sync with upstream #143

merged 19 commits into from
Mar 16, 2022

Conversation

neeasade
Copy link
Member

@neeasade neeasade commented Mar 15, 2022

Title. We could cut a 0.8.5 then after this (although it would be just a smidge past st's 0.8.5).

fixes #142
fixes #138

note: things to consider before a new tag for xst:

  • font resize bug
  • ligatures
  • icon

John Collis and others added 19 commits October 18, 2020 11:17
Also added _NET_WM_ICON_NAME.
These are typically mapped in X11 to the side-buttons (backward/forwards) on
the mouse. A comparison of the button numbers in SGR mode (first field):

st old:
0 1 2 64 65 66 67 68 69 70

st new (it is the same as xterm now):
0 1 2 64 65 66 67 128 129 130

A script to test and reproduce it, first argument is "h" (on) or "l" (off):

	#!/bin/sh
	printf '\x1b[?1000%s\x1b[?1006%s' "$1" "$1"

	for n in 1 2 3 4 5 6 7 8 9 10; do
		printf 'button %d\n' "$n"
		xdotool click "$n"
		printf '\n\n'
	done
Only touch a few things, the main focus is to
improve code readability.
The bits of uint signal in an XKeyEvent which concern the key group (keyboard
layout) are bits 13 and 14, as documented here:
https://www.x.org/releases/X11R7.7/doc/libX11/XKB/xkblib.html#Groups_and_Shift_Levels
In the older version, only bit 13 was marked as part of XK_SWITCH_MOD, this
causes issues for users who have more than two keymaps. the 14th bit is not
in ignoremod, key sequences are not caught by match(), if they switch to a third
or fourth keyboard.
In the current implementation, the slave PTY (assigned to the variable
`s') is always closed after duplicating it to file descriptors of
standard streams (0, 1, and 2).  However, when the allocated slave PTY
`s' is already one of 0, 1, or 2, this causes unexpected closing of a
standard stream.  The same problem occurs when the file descriptor of
the master PTY (the variable `m') is one of 0, 1, or 2.

In this patch, the original master PTY (m) is closed before it would
be overwritten by duplicated slave PTYs.  The original slave PTY (s)
is closed only when it is not one of the stanrad streams.
from the XmbTextListToTextProperty(3) man page:

"If insufficient memory is available for the new value string, the functions
return XNoMemory.  If the current locale is not supported, the functions return
XLocaleNotSupported.  In both of these error cases, the functions do not set
text_prop_return."

Reported by Steffen Nurpmeso <[email protected]>, thanks!
Otherwise the message "erresc: unknown str" is printed.
According to the spec the argument is optional for 104, so p can be
NULL as can be tested with printf '\x1b]104\x07'. This is a regression
of 8e31030.
Overtyping the first half of a wide character with the
second half of a wide character results in display garbage.
This is because the trailing dummy is not cleaned up.

i.e.  ATTR_WIDE, ATTR_WDUMMY, ATTR_WDUMMY

Here is a short script for demonstrating the behavior:

	#!/bin/sh
	alias printf=/usr/bin/printf
	printf こんにちは!; sleep 2
	printf '\x1b[5D'; sleep 2
	printf へ; sleep 2
	printf ' '; sleep 2
	echo
This patch replaces the previous one I sent.

The following changes are made in this patch:
 - Fix tracking of pressed buttons. Previously, pressing two buttons and
   then releasing one would make st think no buttons are pressed, which
   in particular broke MODE_MOUSEMOTION.
 - Always send the lowest-numbered pressed button on motion events; when
   no button is pressed for a motion event in MODE_MOUSEMANY, then send
   a release. This matches the behaviour of xterm. (Previously, st sent
   the most recently pressed button in the motion report.)
 - Remove UB (?) access to potentially inactive struct member
   e->xbutton.button of XEvent union.
 - Fix (unlikely) possibility of overflow for large button numbers.

The one discrepancy I found between st and xterm is that xterm sometimes
encodes buttons with large numbers (>5) strangely. E.g., xterm reports
presses of buttons 8 and 9 as releases, whereas st properly (?) encodes
them as presses.
Build on auto-sync and only mark window dirty on palette changes and let
the event handler do the actual draw.
@neeasade
Copy link
Member Author

showerthoughts: if we're cutting a new release, it might be a good point to revisit ligatures (we only hesitated last time because it introduced a new dependency, harfbuzz)

A separate, easier get here is the icon patch.

Copy link
Collaborator

@actionless actionless left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks a lot!

@neeasade neeasade merged commit 293b895 into master Mar 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

xst is behind st. Is this project still maintained? [Request] OSC patch for easy theming?