Re: Bug#903373: kitty: image rendering seems to be broken
Control: reassign -1 libxkbcommon-x11-0 0.8.0-2 Control: retitle -1 "not a valid UTF-8 string" errors creating compose table in en_IN locale On Mon, Jul 09, 2018 at 11:15:49AM +0530, Ritesh Raj Sarraf wrote: > Thank you for packaging the newer version of kitty. > > With this version, the `icat` and `diff` commands fail with the > following error: This also happens simply when starting kitty, but those go into your session error log. > rrs@priyasi:~$ kitty diff rrs-home/Data/Pictures/debian-transparent.png > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:87:34: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:88:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:89:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:90:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:91:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:92:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:93:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:94:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:95:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:96:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: too many > errors > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: failed to > parse file > [190 11:11:39.666312] [glfw error 65544]: Failed to create XKB compose table > > > Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en > (charmap=UTF-8) That error is directly from xkbcommon's code[0]. If you instead use LANG=en_IN.UTF-8, then there are no issues. It appears that xkbcommon is falling back incorrectly when there isn't an explicit codeset. [0]: https://sources.debian.org/src/libxkbcommon/0.8.0-2/src/compose/parser.c/?hl=207#L207 That being said, just "en_IN" is what "dpkg-reconfigure locales" generates when selecting that locale. Both reportbug and "locale -c charmap" are able to figure out that the codeset is UTF-8. kitty is using essentially the exact code[1] that xkbcommon's documentation suggests to use when calling xkb_compose_table_new_from_locale(). I'm reassigning to xkbcommon to see if there's something they can do to better handle this. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
On Fri, Apr 07, 2017 at 07:23:39AM -0400, G. Branden Robinson wrote: > At 2017-04-06T21:56:13-0400, James McCoy wrote: > > On Fri, Apr 07, 2017 at 12:54:19AM +0200, Francesco Poli wrote: > > > On Thu, 6 Apr 2017 15:06:17 -0400 G. Branden Robinson wrote: > > > > > > > At 2017-04-06T13:33:58-0400, James McCoy wrote: > > > > > On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote: > > > > > > The below is not a sufficient reproduction receipe for me. > > > > > > > > > > > > I'm running Debian Stretch (testing). > > > > > > > > > > > > Things do not go wrong at step #5, nor afterward. > > > > > > > > > > Make sure the terminal is sized small enough (80x24). That causes the > > > > > syntax highlighting in Vim to get a little confused and enable some > > > > > bold > > > > > highlighting, which then causes the visual bell to turn everything > > > > > bold. > > > > > > > > It was. > > > > > > Hello Branden! > > > Thanks for trying to reproduce the bug. > > > > > > Does it help to know that I have: > > > > > > xset b off > > > > > > in my ~/.xsession script? > > > > I don't think that's relevant. My bell is on. I was also able to > > reproduce it without causing the bell. > > > > I've attached an asciinema recording of me reproducing the problem. > > When I replay the recording, it causes the same problem to the xterm in > > which it is running, so hopefully this helps debug the problem. > > That's really interesing. I _still_ can't repro this, even playing back > James's demo with asciinema--a tool of which I wasn't aware, thanks! > > I'm launching xterm in GNOME with the GNOME command runner, whatever > that's called--the Alt+F2 thing. > > However, my xterms are somewhat customized. I'm attaching my > .Xresources file. Perfect! That seems to be the difference. I, and presumably Francesco, aren't using TTF fonts. If I change your Xresources to use XTerm.*.VT100.Font: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1 instead of the FaceName/FaceSize resources, then playing the recording reproduces the problem. Cheers, James
Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote: > The below is not a sufficient reproduction receipe for me. > > I'm running Debian Stretch (testing). > > Things do not go wrong at step #5, nor afterward. Make sure the terminal is sized small enough (80x24). That causes the syntax highlighting in Vim to get a little confused and enable some bold highlighting, which then causes the visual bell to turn everything bold. > At 2017-04-05T22:03:50-0400, James McCoy wrote: > > On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote: > > > I finally found a reliable way to reproduce it. > > > > > > Steps to reproduce: > > > > > > 0) open the attached test.md file: > > > > > > $ vim -u NONE test.md > > > > > > 1) enable syntax highlighting: > > > > > > :set bg=dark > > > :syn on > > > > > > 2) go to the end of the file: > > > > > > [Shift+G] > > > > > > 3) go back to the beginning of the file (line by line): > > > > > > [k].[k] ← hold the key pressed until you reach the first line > > > > > > 4) visualize file info on the status line: > > > > > > [Ctrl+G] > > > > > > 5) the syntax highlighting has gone crazy (even the status line is > > > in boldface!): see the attached screenshot > > > wrong_vim_syntaxmarkdown.png > > > > > > 6) exit from vim: > > > > > > :q > > > > > > 7) the terminal (xterm), or rather the shell (bash), has also gone > > > crazy (it now prints everything in boldface by default): see > > > the attached screenshot > > > wrong_vim_syntaxmarkdown2.png > > > > > > 8) the terminal won't come back to normal behavior until I quit it; > > > another trick to regain the normal behavior of the terminal is > > > opening test.md again, enable syntax highlighting, and exit vim > > > (steps 0, 1, and 6 above) > > Regards, > Branden -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
Control: tag -1 confirmed Control: reassign -1 xterm Control: retitle -1 Terminal stays bold after visual bell with bold text displayed On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote: > I have experienced this bug for a fairly long time, when editing > markdown documents with vim. It has been triggered in a seemingly > random manner. It's the visual bell that happens when you get to the top of the buffer and try to keep going. That causes Vim to send the BEL (Ctrl-G) to the terminal. The way the buffer is currently highlighted (some bold text) at that point is causing xterm to get stuck. You can reset it by Ctrl-RightClick -> "Escape Sequence". It works fine in at least pangoterm, but I haven't tried other more mainstream terminals. I'm reassigning to xterm for now. Rest of the context is below. > I finally found a reliable way to reproduce it. > > Steps to reproduce: > > 0) open the attached test.md file: > > $ vim -u NONE test.md > > 1) enable syntax highlighting: > > :set bg=dark > :syn on > > 2) go to the end of the file: > > [Shift+G] > > 3) go back to the beginning of the file (line by line): > > [k].[k] ← hold the key pressed until you reach the first line > > 4) visualize file info on the status line: > > [Ctrl+G] > > 5) the syntax highlighting has gone crazy (even the status line is > in boldface!): see the attached screenshot > wrong_vim_syntaxmarkdown.png > > 6) exit from vim: > > :q > > 7) the terminal (xterm), or rather the shell (bash), has also gone > crazy (it now prints everything in boldface by default): see > the attached screenshot > wrong_vim_syntaxmarkdown2.png > > 8) the terminal won't come back to normal behavior until I quit it; > another trick to regain the normal behavior of the terminal is > opening test.md again, enable syntax highlighting, and exit vim > (steps 0, 1, and 6 above) Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Bug#856156: vim-gtk: launching gvim as root from terminal crashes X server
Control: reassign -1 xserver-xorg-core 2:1.19.1-4 Control: affects -1 vim-gtk Reassigning to xserver-xorg-core. Vim's gtk2 code hasn't changed significantly in some time, so it's more likely an issue with the glamor driver. On Sat, Feb 25, 2017 at 12:54:21PM -0500, Bruno Dantas wrote: > Either command in a terminal consistently crashes the X server: > # gvim foo.txt > $ gksudo gvim foo.txt > > I upgraded from Jessie to Stretch, which is when the problem started. The > error > message in the text console that appears after the crash is this: > "glamor_largepixmap.c:1448: glamor_composite_largepixmap_region: Assertion `0' > failed. xinit: connection to X server lost" > > Interestingly, starting gvim from within the file manager running as root (via > context menu's "Open with") works fine. Also, these work fine: > > # pluma foo.txt > $ gksudo pluma foo.txt > $ gvim foo.txt > > It seems the problem is isolated to launching gvim as root from the command > line. glamor_largepixmap.c is part of the xorg-server source package. If I > should report the bug there instead/in addition to here, please let me know. I > don't want to create noise. > > These are my package versions: > vim-gtk 2:8.0.0197-2 > xorg 1:7.7+18 > > If you need any further information, please let me know. gvim is my favorite > editor and I'm in a terminal most of the time, so I'm highly motivated to > help. -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
