Bug#1109472: xterm: display issue: dots in the bottom line due to box drawings vertical line

Control: found -1 379-1 This already occurs with an xterm on a bookworm machine (current stable). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Bug#1109472: xterm: display issue: dots in the bottom line due to box drawings vertical line

On 2025-07-18 16:43:23 +0200, Vincent Lefevre wrote: > I could eventually reproduce the issue. This is due to the characters > like > > U+2502 BOX DRAWINGS LIGHT VERTICAL > U+251C BOX DRAWINGS LIGHT VERTICAL AND RIGHT > > when put in the bottom text line. I forgot... wi

Bug#1109472: xterm: display issue: dots in the bottom line due to box drawings vertical line

Control: retitle -1 xterm: display issue: dots in the bottom line due to box drawings vertical line On 2025-07-18 16:36:34 +0200, Vincent Lefevre wrote: > I have no idea how these dots appeared. I could eventually reproduce the issue. This is due to the characters like U+2502 BOX DRAWI

Bug#1109472: xterm: display issue: dots in the bottom line

Package: xterm Version: 401-1 Severity: minor I've noticed a small display issue with xterm 401: dots in the bottom line. See attached screenshot. There are 1 dot below the q and other 2 dots on the right. I have no idea how these dots appeared. Moving to another desktop (making the xterm window

Bug#1105738: xterm: double-click can incorrectly add the preceding space to the selection

On 2025-05-14 01:59:38 +0200, Vincent Lefevre wrote: > Package: xterm > Version: 398-1 > Severity: normal > > When I double-click on a word at the beginning of a line such that > this word is preceded by spaces, one space is incorrectly included > in the selection. &g

Bug#1105738: xterm: double-click can incorrectly add the preceding space to the selection

Package: xterm Version: 398-1 Severity: normal When I double-click on a word at the beginning of a line such that this word is preceded by spaces, one space is incorrectly included in the selection. For instance, type printf "%$((COLUMNS+1))syz\n" x which gives a line full of spaces and the w

Bug#1087746: libx11-6: segfault in XkbTranslateKeyCode when using xterm

Package: libx11-6 Version: 2:1.8.10-2 Severity: important Affects: xterm That's twice xterm crashed in XkbTranslateKeyCode today. Core was generated by `/usr/bin/xterm -xrm *printFileOnXError: /home/vinc17/private/xterm-saved-173091'. Program terminated with signal SIGSEGV, Segmentation fault. #

Bug#1084794: xterm: The Greek pi letter U+03C0 is not rendered correctly in Noto Mono

On 2024-10-08 14:13:09 +0200, Vincent Lefevre wrote: > The U+03C0 GREEK SMALL LETTER PI character (π) is not rendered > correctly when the Noto Mono font is used. Note that this is > specific to xterm. There is no such issue with GNOME Terminal > and Firefox with the same font. >

Bug#1084794: xterm: The Greek pi letter U+03C0 is not rendered correctly in Noto Mono

Package: xterm Version: 394-1 Severity: normal The U+03C0 GREEK SMALL LETTER PI character (π) is not rendered correctly when the Noto Mono font is used. Note that this is specific to xterm. There is no such issue with GNOME Terminal and Firefox with the same font. To reproduce, for instance: x

Bug#1078255: xterm: segmentation fault when clicking on the right button

On 2024-08-09 15:01:17 -0400, Thomas Dickey wrote: > On Fri, Aug 09, 2024 at 02:44:46PM -0400, Thomas Dickey wrote: > > Is this something that you might reproduce, to provide test-data? I tried to reproduce it, but I couldn't. > ld could be null if there's some inconsistency in the select begin/e

Bug#1078255: xterm: segmentation fault when clicking on the right button

Package: xterm Version: 393-1 Severity: important I got a segmentation fault when clicking on the right button. Core was generated by `/usr/bin/xterm -xrm *printFileOnXError: /home/vinc17/private/xterm-saved-172316'. Program terminated with signal SIGSEGV, Segmentation fault. #0 class_of (cell=

Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1

On 2024-08-05 12:42:42 +0200, Vincent Lefevre wrote: > This bug was closed, but has not been marked as fixed in > libwayland-client0, so that the current version is still > regarded as buggy, as reported by apt-listbugs: > > serious bugs of libwayland-client0 (1.22.0-2.1+b1 →

Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1

This bug was closed, but has not been marked as fixed in libwayland-client0, so that the current version is still regarded as buggy, as reported by apt-listbugs: serious bugs of libwayland-client0 (1.22.0-2.1+b1 → 1.23.0-1) b1 - #1076729 - libwayland: breaks plasma desktop start after last upgra

Bug#1077886: xterm: spurious characters in reverse video in scrollback buffer

On 2024-08-05 04:17:16 +0200, Vincent Lefevre wrote: > Unfortunately, I can't reproduce the issue with a simple testcase. The issue might be due to the progress bar, which is kept at the bottom of the xterm window while there is scrolling output above it. This probably involves some

Bug#1077886: xterm: spurious characters in reverse video in scrollback buffer

On 2024-08-04 18:56:11 -0400, Thomas Dickey wrote: > On Sun, Aug 04, 2024 at 03:34:12AM +0200, Vincent Lefevre wrote: > > Some characters in the scrollback buffer can appear in reverse video. > > But after scrolling again, they appear as normal, even when there was > > no outp

Bug#1077886: xterm: spurious characters in reverse video in scrollback buffer

Package: xterm Version: 393-1 Severity: normal Some characters in the scrollback buffer can appear in reverse video. But after scrolling again, they appear as normal, even when there was no output. This occurred while I was upgrading packages with apt on a remote machine (via ssh in xterm), perha

Bug#1070293: xkb-data: typo in URL in the copyright file

Package: xkb-data Version: 2.41-2 Severity: minor In /usr/share/doc/xkb-data/copyright the URL https://xorg.freedesktop.orgreleases/individual/data/xkeyboard-config is incorrect. A slash is missing before "releases". A trailing slash should also be added to avoid a redirection. Correct URL:

Bug#1060108: xbase-clients: should not depend (not even recommend) xinit

Package: xbase-clients Version: 1:7.7+23 Severity: normal The xbase-clients package is there to provide only X clients, not an X server. This package currently depends on xinit, which has the effect to install an X server. The goal of xinit is to start an X server; this utility is not an X client

Bug#1055243: libinput10: invalid URL in Xorg logs due to incorrect HTTP_DOC_LINK value

Package: libinput10 Version: 1.22.1-1 Severity: minor In my Xorg logs (e.g. Keyb/var/log/Xorg.0.log), I get messages like [ 10491.518] (EE) event14 - VEN_04F3:00 04F3:311C Touchpad: kernel bug: Touch jump detected and discarded. See https://wayland.freedesktop.org/libinput/doc/1.22.1/touchpad-j

Bug#1038939: xserver-xorg-core: Xorg crashed after a Ctrl-C in an xterm

Package: xserver-xorg-core Version: 2:21.1.7-3 Severity: important In the morning, shortly after a kernel upgrade (I hadn't rebooted yet), Xorg crashed immediately after I typed Ctrl-C in an xterm (because I ran a command with lots of output). An excerpt of the journalctl output, though this is n

Bug#633849: Processed: [bts-link] source package xorg

[I should have Cc'd this to the bug. Sending a copy now.] tags 633849 wontfix - fixed-upstream thanks The upstream bug was closed because "there isn't enough maintainer time (or motivation) to ever fix this", not because it was fixed. IMHO, this limitation should be documented (probably in the m

Bug#273194: xterm: characters from paste buffer lost at roughly 4kB intervals [kernel pty bug?]

On 2023-01-23 03:11:59 +0100, Vincent Lefevre wrote: > On 2006-10-14 15:56:10 -0400, Thomas Dickey wrote: > > On Sat, Oct 14, 2006 at 08:20:14PM +0200, Andrew Moise wrote: > > > I still see this misbehavior with xterm 210-3.1 and > > > linux-image-2.6.17-2-686 2.6.17-9.

Bug#273194: xterm: characters from paste buffer lost at roughly 4kB intervals [kernel pty bug?]

On 2006-10-14 15:56:10 -0400, Thomas Dickey wrote: > On Sat, Oct 14, 2006 at 08:20:14PM +0200, Andrew Moise wrote: > > I still see this misbehavior with xterm 210-3.1 and > > linux-image-2.6.17-2-686 2.6.17-9. > > I can see it (now) with a 2.6.15 kernel (814 lines copied). > I also note that Bran

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

Control: affects -1 emacs-gtk mlterm This also affects mlterm, when I resize the terminal. In the upstream bug, someone says that it also affects xterm, but I cannot reproduce the issue with xterm. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

On 2022-12-21 14:01:53 +0100, Vincent Lefevre wrote: > Not sure about the bug severity, but if such errors are output, > this means that they are really serious. Otherwise, the end user > shouldn't be bothered. In any case, this must be fixed before > the next Debian release. I

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

Package: libx11-6 Version: 2:1.8.3-2 Severity: grave Justification: renders package unusable or possible data loss? After the upgrade to libx11-6 2:1.8.3-2, I get the following errors when running emacs: e.g. Xlib: sequence lost (0x1 > 0x473) in reply type 0x21! Xlib: sequence lost (0x1

Bug#1018005: xfonts-base: missing U+2A7D (⩽) and U+2A7E (⩾) characters in 6x13

Package: xfonts-base Version: 1:1.0.5 Severity: normal Tags: patch I'm using the 6x13 font on some machine, and the following characters are missing: U+2A7D LESS-THAN OR SLANTED EQUAL TO U+2A7E GREATER-THAN OR SLANTED EQUAL TO I could create the glyphs with fontforge, based on U+2264 (≤) and

Bug#1017726: libx11-6:amd64: inconsistency in some KeySym definitions and string lookup

Package: libx11-6 Version: 2:1.8.1-2 Severity: normal While "infinity" and "approxeq" KeySym names work correctly, e.g. xev outputs for them state 0x81, keycode 31 (keysym 0x8c2, infinity), same_screen YES, XLookupString gives 3 bytes: (e2 88 9e) "∞" XmbLookupString gives 3 bytes: (e2

Bug#1010084: x11-xkb-utils: xkbcomp outputs many warnings without "-w 0"

On 2022-04-23 23:57:24 +0200, Vincent Lefevre wrote: [...] > where .xkb/keymap/test contains > > xkb_keymap { > xkb_keycodes { include "evdev+aliases(qwerty)" }; > xkb_types { include "complete" }; >

Bug#1010084: x11-xkb-utils: xkbcomp outputs many warnings without "-w 0"

Package: x11-xkb-utils Version: 7.7+6 Severity: normal Without "-w 0", I get many warnings with xkbcomp: zira:~> xkbcomp -I$HOME/.xkb -R$HOME/.xkb keymap/test xkb.dump Keycodes above 256 (e.g. ) are not supported by X and are ignored Warning: Could not resolve keysym XF86EmojiPicker Warn

Bug#1009995: x11-xkb-utils: xkbcomp gives a warning for keysym XF86EmojiPicker from symbols/inet

Package: x11-xkb-utils Version: 7.7+6 Severity: normal Consider zira:~> cat .xkb/keymap/test xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat{ include "complete" }; xkb_symbols { includ

Bug#1009994: xkbcomp: warnings with "-w 0" due to missing warningLevel test for some WARN() occurrences

Package: x11-xkb-utils Version: 7.7+6 Severity: normal Tags: upstream Forwarded: https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/20 The the xkbcomp(1) man page says: -w lvl Controls the reporting of warnings during compilation. A warning level of 0 disables all warnings; a

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

Control: reassign -1 less Control: found -1 487-0.1 Control: found -1 590-1 Control: retitle -1 less: with option -R, the escape sequences should be sent in an atomic way so that they are not broken by stderr Control: tags -1 upstream - wontfix On 2020-01-30 21:21:03 -0500, Thomas Dickey wrote: >

Bug#699746: #699746 x11-utils: xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1

On 2022-02-13 18:44:28 -0500, Thomas Dickey wrote: > I was recently reminded of this one, and can see that it's no longer relevant: > > + The bug-report made incorrect assumptions about what xprop ought to be > doing. > So it's not relevant to xprop. Well, I initially thought that this was xpr

Bug#968093: client bug: event processing lagging behind by ..ms, your system is too slow

Control: tags -1 upstream Control: forwarded -1 https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/46 I've reported the bug upstream. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA

Bug#968093: client bug: event processing lagging behind by ..ms, your system is too slow

Control: found -1 1.19.3-1 On 2020-08-08 20:24:28 +0800, 積丹尼 Dan Jacobson wrote: > /var/log/Xorg.0.log has > (EE) event2 - Logitech USB Keyboard: client bug: event processing lagging > behind by 11ms, your system is too slow Same kind of errors on my two machines: [86.305] (EE) event5 - P

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

+0200, Vincent Lefevre wrote: > Control: reassign -1 x11-xkb-utils 7.7+5 > Control: retitle -1 x11-xkb-utils: xkbcomp gives internal errors on unknown > keysyms (e.g. some XF86* with xkb-data 2.33-1) > Control: notforwarded -1 > Control: tags -1 fixed-upstream > > On 2021-09-

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

Control: reassign -1 x11-xkb-utils 7.7+5 Control: retitle -1 x11-xkb-utils: xkbcomp gives internal errors on unknown keysyms (e.g. some XF86* with xkb-data 2.33-1) Control: notforwarded -1 Control: tags -1 fixed-upstream On 2021-09-10 19:08:59 +0200, Vincent Lefevre wrote: > This is apparen

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

Control: tags -1 upstream Control: forwarded -1 https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/282 This is apparently an upstream bug (which I have just reported), introduced in 2.33, as some commit added these unknown keysyms. -- Vincent Lefèvre - Web:

Bug#994037: xkb-data: TWO_LEVEL is not available

Control: reassign -1 x11-xkb-utils 7.7+5 Control: retitle -1 x11-xkb-utils: xkbcomp fails with "X Error of failed request: BadValue" for XkbSetMap on specific config On 2021-09-10 14:31:38 +0200, Vincent Lefevre wrote: > cventin:~> xkbcomp -w 0 -I$HOME/.xkb -R$HOME/.xkb keymap

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

On 2021-09-10 04:09:52 +0200, Vincent Lefevre wrote: > Package: xkb-data > Version: 2.33-1 > Severity: important > > The upgrade from 2.29-2 to 2.33-1 silently breaks Multi_key. > > A diff of the xkbcomp dump gives in particular: > > key { > -type= &

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

Control: retitle -1 The drop of Multi_key for gb in xkb-data 2.33 should be announced in NEWS.Debian following my comment: On 2021-09-10 15:06:40 +0200, Vincent Lefevre wrote: > This is apparently due to the following upstream change. But this is > the kind of thing that should be announ

Bug#994037: xkb-data: TWO_LEVEL is not available

Package: xkb-data Version: 2.33-1 Severity: important On one of my machines: cventin:~> cat .xkb/keymap/custom xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat{ include "complete" }; xkb_

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

Package: xkb-data Version: 2.33-1 Severity: normal On one of my machines, with a default configuration: cventin:~> cat .xkb/keymap/custom xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat{ include "com

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

Package: xkb-data Version: 2.33-1 Severity: important The upgrade from 2.29-2 to 2.33-1 silently breaks Multi_key. A diff of the xkbcomp dump gives in particular: key { -type= "TWO_LEVEL", -symbols[Group1]= [ ISO_Level3_Shift, Multi_key ] +type= "ONE_LEVEL", +

Bug#977996: xserver-xorg-input-libinput: for the middle button, reports press only when the button is released

Package: xserver-xorg-input-libinput Version: 0.30.0-1 Severity: normal On my HP ZBook 15 G2 laptop, I have a pointstick with associated mouse buttons and a touchpad with associated mouse buttons. There is no issue with the touchpad buttons, but for the middle button associated with the pointstick

Bug#914949: [bts-link] source package libx11

Control: reassign -1 libxcb1 1.14-2 Control: tags -1 - fixed-upstream Control: forwarded -1 https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/34 On 2019-02-18 17:16:25 +, debian-bts-l...@lists.debian.org wrote: > # remote status report for #914949 (http://bugs.debian.org/914949) > # Bug

Bug#732854: lightdm shows a part of my desktop screen as a part of the background of the login screen

On 2013-12-22 16:54:12 +0100, Vincent Lefevre wrote: > Package: lightdm > Version: 1.8.5-2 > Severity: grave > Tags: security > Justification: user security hole > > Here's what I did: > 1. Quit me desktop session. > 2. In lightdm (whose screen appeared corre

Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7

On 2020-01-19 00:09:13 +, Jamie Heilman wrote: > Package: xserver-xorg-core > Version: 2:1.20.7-2 > Severity: grave > > Setup is a NVIDIA GF108GL [Quadro 600] driving two monitors in > portrait orientation. Kernel 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) > > xorg.conf is: > Section "

Bug#880407: still occurs in xterm 352-1

On 2020-01-20 20:06:51 -0500, Thomas Dickey wrote: > The change that I used gave me the same result for the font which you > mentioned in the bug report. You may be using some different font. I'm using the following settings: /usr/bin/xterm -xrm "Xft.dpi: 132" -xrm "XTerm*faceName: DejaVu Sans M

Bug#880407: still occurs in xterm 352-1

s (Closes: #880407, adapted from patch by Vincent Lefevre). The bug still occurs with 352-1. Note that my patch was still working with 351-1. What has been done in fontutils.c is: @@ -2912,6 +2921,17 @@ ascent = font->ascent; descent = font->descent; if (h

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-18 00:02:46 +0100, Vincent Lefevre wrote: > On my machine, the problem is almost always reproducible with > > ll -R /run | less > > where > > zira:~> where ll > ll: aliased to ls -l > zira:~> where ls > ls: aliased to \ls -bFv --color >

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-17 23:45:20 +0100, Vincent Lefevre wrote: > This is not this issue. The problem is that xterm sets up some margin, > and the lines at the top can no longer be erased. I need to use the > "reset" command to fix things. On my machine, the problem is almost always repr

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-17 17:12:48 -0500, Thomas Dickey wrote: > https://invisible-island.net/xterm/xterm.faq.html#vt100_wrapping This is not this issue. The problem is that xterm sets up some margin, and the lines at the top can no longer be erased. I need to use the "reset" command to fix things. -- Vince

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-17 11:55:28 +0100, Vincent Lefevre wrote: > This is not reproducible only with xterm, not with other terminals, > such as rxvt and gnome-terminal (but perhaps the race occurs > differently). Grrr... I meant: "This is reproducible only with xterm, not with o

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

Package: xterm Version: 351-1 Severity: normal I've run the equivalent of ls with some options including --color piped to less with the -R option, and after quitting less, the xterm status sometimes get corrupt, apparently due to some margin set up. I've attached the xterm output log, but I can n

Bug#948516: xterm: displays incorrect text when one scrolls backward while output is ongoing

On 2020-01-10 03:22:05 +0100, Vincent Lefevre wrote: > On 2020-01-09 20:54:15 -0500, Thomas Dickey wrote: > > maybe - but without a typescript which would show me what went to the > > terminal, I'm missing most of the information needed to investigate it. > > What do y

Bug#948516: xterm: displays incorrect text when one scrolls backward while output is ongoing

On 2020-01-09 20:54:15 -0500, Thomas Dickey wrote: > maybe - but without a typescript which would show me what went to the > terminal, I'm missing most of the information needed to investigate it. What do you mean exactly? Note that the bug is reproducible with almost anything that generates outp

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Control: found -1 347-1 Control: tags -1 patch Patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880407#100 On 2019-05-20 15:54:42 +0200, Vincent Lefevre wrote: > The attached patch, which decreasing both ascent and descent by 1 when > height < ascent + descent, avoids this fo

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2019-05-20 15:54:42 +0200, Vincent Lefevre wrote: > Things have changed again with FreeType 2.9 (libfreetype6 2.9.1-3). [...] Sorry, I think that the change was just due to a different Xft.dpi value (as I did the test on a different machine): 132 instead of 88. Anyway, the problem is the s

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Control: found -1 344-1 Control: found -1 345-1 Things have changed again with FreeType 2.9 (libfreetype6 2.9.1-3). I now get with "DejaVu Sans Mono" and size 10 (-fs 10): Xft metrics screen->renderFontNorm[0] = 21 (18,5)* advance 11, actual 11 Xft metrics screen->renderFontBold[0] = 21 (18,5)* a

Bug#916349: xterm: X error (BadLength) with GNU screen

Control: retitle -1 xterm: X error (BadLength) when trying to display some glyphs On 2018-12-13 18:35:43 -0500, Thomas Dickey wrote: > On Thu, Dec 13, 2018 at 06:25:42PM -0500, Thomas Dickey wrote: > > On Thu, Dec 13, 2018 at 02:11:28PM +0100, Vincent Lefevre wrote: > > &

Bug#916349: xterm: X error (BadLength) with GNU screen

On 2018-12-13 14:51:26 +0100, Vincent Lefevre wrote: > After downgrading xterm to 337-1, then reupgrading to 338-1, I can > no longer reproduce the bug (for the moment). The error occurs again. So, it seems to occur only after some time. I don't know what triggers it. -- Vincent Lef

Bug#916349: xterm: X error (BadLength) with GNU screen

On 2018-12-13 14:17:48 +0100, Julien Cristau wrote: > Please share your xterm config. Here's the "appres XTerm" output: *tek4014*fontLarge: 9x15 *tek4014*font2: 8x13 *tek4014*font3: 6x13 *tek4014*fontSmall: 6x10 *MenuButton*borderWidth:0 *Scrollbar.thickness: 8 *Scrollbar.backgr

Bug#916349: xterm: X error (BadLength) with GNU screen

Package: xterm Version: 338-1 Severity: grave Justification: renders package unusable After upgrading xterm to 338-1, I get X errors when using GNU screen: zira% xterm -e screen -r /usr/bin/xterm: warning, error event received: X Error of failed request: BadLength (poly request too large or inte

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 14:12:32 +0100, Vincent Lefevre wrote: > I suspect a bug in doSelectionFormat() in button.c that makes xterm > think that there was a bracketed paste, whose consequence is to > generate the "ESC [ 2 0 1 ~ .". > > If I remove > > #if OPT_READLI

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 13:33:41 +0100, Vincent Lefevre wrote: > Note also that for a bracketed paste, > > > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode > > says: > > When bracketed paste mode is set, the program will receive: > E

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 11:30:03 +0100, Vincent Lefevre wrote: > On 2018-12-05 05:03:46 -0500, Thomas Dickey wrote: > > On Wed, Dec 05, 2018 at 10:13:35AM +0100, Vincent Lefevre wrote: > > > According to strace, it is xterm: > > > > sure: xterm replies to the application for

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 05:03:46 -0500, Thomas Dickey wrote: > On Wed, Dec 05, 2018 at 10:13:35AM +0100, Vincent Lefevre wrote: > > According to strace, it is xterm: > > sure: xterm replies to the application for bracketed paste. You mean that it is zsh that does the paste? Why isn

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 09:58:21 +0100, Vincent Lefevre wrote: > On 2018-12-04 21:50:47 -0500, Thomas Dickey wrote: > > That looks as expected, if you've got two different things writing to > > the terminal at the same time: > > > > https://invisible-island.net/xterm/ctlseqs

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-04 21:50:47 -0500, Thomas Dickey wrote: > That looks as expected, if you've got two different things writing to > the terminal at the same time: > > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode So, perhaps I can see something with zsh (without Ctrl-V

Bug#914949: Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"

Control: forwarded -1 https://gitlab.freedesktop.org/xorg/lib/libx11/issues/80 On 2018-11-29 01:10:06 +0100, Vincent Lefevre wrote: > 2. As seen above, the error message does not end with a newline > character. This breaks the parsing of the output (at least when > both the standard o

Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"

ollowed by a newline character On 2018-11-28 18:19:46 +0100, Vincent Lefevre wrote: > The output is actually present, but was filtered out later by > the script due to an unexpected error message without a \n. > > The tests/tversion.log starts with: > > Invalid MIT-MAGIC

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-11-26 20:38:37 -0500, Thomas Dickey wrote: > On Sun, Nov 25, 2018 at 12:08:03AM +0100, Vincent Lefevre wrote: > > With zsh, one can reproduce the issue with: > > > > $ xterm -e zsh -f > > If you added a "-l" option, that would turn on xterm's log

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-11-21 19:02:33 -0500, Thomas Dickey wrote: > I don't see how this could happen unless you combined the action with > some pasting (such as bracketed-paste). I paste nothing. > xterm's formatting of the string is shell-agnostic, and the exec'd > "browser" command would only depend on what

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

Package: xterm Version: 337-1 Severity: normal In my XTerm configuration, I have: *VT100*translations:#override \n\ Meta: exec-formatted("browser %s", PRIMARY) The problem is that when exec-formatted is invoked from zsh or emacs (when run in xterm, e.g. with "emacs -n

Bug#906934: libxcb1-dbgsym is not available for amd64

On 2018-08-22 16:32:29 +0200, Vincent Lefevre wrote: > libxcb1-dbgsym is not available for amd64, while it is available > for some other architectures: > > https://packages.debian.org/sid/libxcb1-dbgsym Hmm... It seems that this page is just for ports. But http://debug.mirror

Bug#906934: libxcb1-dbgsym is not available for amd64

Source: libxcb Version: 1.13-2 Severity: normal libxcb1-dbgsym is not available for amd64, while it is available for some other architectures: https://packages.debian.org/sid/libxcb1-dbgsym Version 1.13-1 was available. -- System Information: Debian Release: buster/sid APT prefers unstable-

Bug#892362: xserver-xorg-core: black screen when the nvidia driver fails instead of fallback to fbdev

Package: xserver-xorg-core Version: 2:1.19.6-1 Severity: normal After a major upgrade of the NVIDIA drivers and restart of the X server (e.g. package upgrade + logout, so that the display manager restart the X server), the NVIDIA drivers no longer work (which can be regarded as normal, as the mach

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2018-01-05 05:21:32 -0500, Thomas Dickey wrote: > On Fri, Jan 05, 2018 at 10:26:11AM +0100, Vincent Lefevre wrote: > > Sorry, I don't understand what you mean. Can you reproduce the problem > > with that? > > only for the case that I made xterm detect/workaround. >

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2018-01-05 04:13:56 -0500, Thomas Dickey wrote: > - Original Message - > | On 2018-01-05 03:59:42 -0500, Thomas Dickey wrote: > | > Then you should provide more information allowing this to be > | > reproduced. > | > | I can reproduce this with the default config and: > | > | xterm -

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2018-01-05 03:59:42 -0500, Thomas Dickey wrote: > Then you should provide more information allowing this to be reproduced. I can reproduce this with the default config and: xterm -fa Monospace -fs 10 -xrm "Xft.dpi: 132" (the "Xft.dpi: 132" is important). -- Vincent Lefèvre - Web:

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Control: reopen -1 Control: found -1 331-1 Control: tags -1 - fixed-upstream On 2017-12-30 14:53:27 -0500, Thomas Dickey wrote: > I investigated, found that it is a defect in FreeType. > None of the comments in > > https://savannah.nongnu.org/bugs/?52165 > > were helpful (some of the info

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

On 2017-12-30 10:24:24 -0500, Thomas Dickey wrote: > On Sun, May 07, 2017 at 07:12:44PM -0400, Thomas Dickey wrote: > > - Original Message - > > | The behavior is not what is described in this section. I would agree > > | if renderFont were "true". But the manual says: > > | > > | The de

Bug#880407: xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2017-10-31 16:21:58 -0400, Thomas Dickey wrote: > On Tue, Oct 31, 2017 at 10:39:28AM +0100, Vincent Lefevre wrote: > > Package: xterm > > Version: 330-1 > > Severity: important > > wishlist or normal. Don't soapbox, if you want to have a constructive >

Bug#880407: xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2017-10-31 10:39:28 +0100, Vincent Lefevre wrote: > FreeType 2.8 uses different rounding rules for ascender and descender, [...] Well, for TrueType fonts (as it was mentioned later). But this seems to be the most common fonts from FreeType on Debian, and the default ones. -- Vincent Lefè

Bug#880407: xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Package: xterm Version: 330-1 Severity: important FreeType 2.8 uses different rounding rules for ascender and descender, so that one can now have (src->ascent + src->descent) > src->height in CACHE_XFT from fontutils.c (only because of rounding), which yields a spurious blank line between line

Bug#855206: fixed in xorg-server 2:1.19.4-1

On 2017-10-09 21:49:53 +, Timo Aaltonen wrote: > Source: xorg-server > Source-Version: 2:1.19.4-1 > > We believe that the bug you reported is fixed in the latest version of > xorg-server, which is due to be installed in the Debian FTP archive. I confirm that the bug is fixed: I've run my scri

Bug#661295: libx11-6 based applications are confused by new xkb settings (possible crash in XkbTranslateKeyCode)

Control: found -1 327-2 On 2015-11-15 15:11:45 +0100, Vincent Lefevre wrote: > On 2012-02-26 02:54:45 +0100, Vincent Lefevre wrote: > > When changing the xkb settings with: Actually, not "changing", but "restoring" (so that the settings are the same as whe

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

On 2017-05-07 17:24:43 -0400, Thomas Dickey wrote: > Perhaps you'll see it here: > > http://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:renderFont > > Most of xterm's options work by setting resource values (there are a > handful of special cases such as "-help", "-versio

Bug#847479: xterm: display issue with double-width character like ? on the last column via ncurses

On 2017-05-07 16:30:24 -0400, Thomas Dickey wrote: > a typescript (from "script") helps. After trying again. the problem seems to occur only when one resizes the terminal window. So, a typescript doesn't help. It seems to be a problem similar to what I had already reported under other conditions:

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

On 2017-05-07 16:29:35 -0400, Thomas Dickey wrote: > - Original Message - > | From: "Vincent Lefevre" > | To: "Debian Bug Tracking System" > | Sent: Sunday, May 7, 2017 1:23:00 PM > | Subject: Bug#862042: xterm: if the faceName resource is defined, t

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

Package: xterm Version: 327-2 Severity: minor If I define the faceName resource, e.g. with XTerm*faceName: Monospace in the .Xresources file (read by xrdb), then the -fn (-font) option is ignored. For instance, xterm -fn 7x13 has no effect. Options normally override the default resources, bu

Bug#847479: xterm: display issue with double-width character like ? on the last column via ncurses

On 2017-05-07 10:53:24 -0400, Thomas Dickey wrote: > Attaching a script, for discussion. I don't see the problem, but noticed > that the character is "new", and for instance if you were running xterm > remotely so that the wcwidth wasn't known then you could get odd results. I can't reproduce the

Re: Bug#855206: When a process quits, xorg sometimes leaves a zombie window

Control: found -1 2:1.19.1-4 And the bug still occurs after just the following downgrade: -ii xserver-common 2:1.19.3-1 all common files used by various X servers -ii xserver-xephyr 2:1.19.3-1

Bug#855206: When a process quits, xorg sometimes leaves a zombie window

Control: reassign -1 xserver-xorg-core 2:1.19.3-1 On 2017-04-27 23:06:06 +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > reassign 855206 xserver-xorg > Bug #855206 [fvwm] fvwm: When an application quits, fvwm doesn't always > remove its window im

Bug#855206: Sometimes windows remain after the process has died.

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=100863 I've reported a bug upstream (I've searched among open/closed bugs containing "window" and couldn't find one already reported): https://bugs.freedesktop.org/show_bug.cgi?id=100863 -- Vincent Lefèvre - Web:

Bug#847479: xterm: display issue with double-width character like 🍸 on the last column via ncurses

Notes: The character appears in the subject of this mail, so that you can use it as a test case. :) The problem doesn't appear with a shell and printf. Thus I assume that it may be related to margins and things like that. -- Vincent Lefèvre - Web: 100% accessible vali

Bug#847479: xterm: display issue with double-width character like 🍸 on the last column via ncurses

Package: xterm Version: 327-1 Severity: minor In Mutt, when a double-width character from the subject appears on the last column (in the Mutt index menu), then the left part of the second half of the character is visible. Something like that. For instance, if the character rendering would be deno

Bug#844325: xterm: display issue after sending zero-width characters to the terminal

Note that under Debian GNU/Linux 8 (jessie), xterm 312-2 is also affected, but not with U+00AD SOFT HYPHEN, whose wcwidth is 1 there (instead of 0 in the current glibc). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: W

  1   2   3   4   5   >