Summary: | x11-libs/vte-0.16.0 breaks compatibility with inputrc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Balint Dobai-Pataky <dpblnt> |
Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, srrijkers |
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.gnome.org/show_bug.cgi?id=337252 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 181943 | ||
Attachments: | emerge --info |
Description
Balint Dobai-Pataky
2007-05-16 17:38:46 UTC
Created attachment 119458 [details]
emerge --info
forward-word and backward-work don't work for me even in bash with vte-0.16.5 :( I'll take a closer look at this when I have the rest of gnome 2.18 installed - if someone manages to figure this one out earlier, I would appreciate Seems to be a regression from http://bugzilla.gnome.org/show_bug.cgi?id=337252 and it's reopened and regression is discovered in later comments. Meanwhile alt+left/right arrow works for backwards/forwards-char in bash (readline?) but doesn't help for mcedit. (In reply to comment #3) The patch from comment #12 in that bug fixes the same issue I was having in VIM with control+cursor keys. Upstream patch added to 0.16.6-r1. This patch doesn't seem to fix ctrl+left/right arrow cursor movement in readline/bash for me, which is the most major regression in my book for 0.16. Reopening for more research on this. Will try with 0.16.7 release soon. it fixes control+left/right, shift+down/up, shift+F5 for me, thanks. (In reply to comment #7) > it fixes control+left/right, shift+down/up, shift+F5 for me, > thanks. In where does it fix control+left/right for you? I think I get it fixed in things like midnight commander that are in the mode where you can't scroll back (alternative mode I think), and it doesn't work for bash, where alt+left/right work. I'm starting to get the impression that's how it is supposed to work and it just happened to also work with ctrl+left/right in bash before by accident in gnome 2.16 or something like that. So original report seems to be handled indeed, with mcedit shift+down and ctrl+left in mcedit and vim working. fist i tested it in mcedit, now i looked at it in bash, and it's strange: control+left jumps a word backward, but control+right does not jump a word forward. indeed, alt+right/left works in bash as expected. The whole thing'd hit the stable gentoo. Solution for bash mcedit etc: put these things in your /etc/inputrc next to gnome-terminal section about (escape + arrow key) "\e[1;5C": forward-word "\e[1;5D": backward-word Hope this fix hits ebuilds soon as well (thread on this: http://forums.gentoo.org/viewtopic-p-4115692-highlight-.html) C'mon, guys, my baselayout's just gotten updated today to 1.12.9-r2, and /etc/inputrc again got dispatch-conf`ed to the one _without_ essential lines "\e[1;5C": forward-word "\e[1;5D": backward-word So when are you going to inject this thing into portage? base-system, what's your view on this? people seem to be confused about inputrc. it is merely a configuration file. it is not required whatsoever for proper behavior on a system. the *defaults* in it are there *only* as a convenience. the file is intended for modification and customization *by end users*. i could just as soon as not add any lines at all to the file and make users uncomment them *as they want*. this is exactly what many other distributions do. claiming that the existence (or lack) of any line in /etc/inputrc as a bug is incorrect. closing fixed per upstream status bug and comment from base-system. If you want customization of /etc/inputrc, please contact baselayout maintainer. Thanks for reporting. |