On 29Jun2015 11:36, Chris Angelico <ros...@gmail.com> wrote:
On Mon, Jun 29, 2015 at 4:55 AM, Steven D'Aprano <st...@pearwood.info> wrote:
Try Ctrl-TAB again, and you'll get "raise" instead of "import".
Can anyone else replicate this issue?
Is this a Python issue, a problem with the terminal I am using, or readline
in general?
Confirmed with Python 3.6 on Debian Jessie. Delving into Laura's
suggestion that it's a readline problem, I came across this:
http://stackoverflow.com/questions/12044574/getting-complete-and-menu-complete-to-work-together
Testing with "showkey -a" suggests that tab and ctrl-tab indeed send
the same bytes. I wonder if there's a way to change terminal type or
fiddle with terminfo to change this? GUI programs obviously don't have
this conflation.
Yes, this was my surmise (and expectation, frankly - what did you expect
ctrl-TAB to send?) So there is no way for the program in the terminal to
distinguish one from the other; you will always only get one of your bindings.
I would not expect terminfo to get you anything on its own - it is consulted by
the receiving program. The sending program (the terminal emulator) needs to be
configured to send different sequences for TAB and ctrl-TAB. Once that is done,
_then_ you may be able to augument your terminfo to express this behaviour and
have readline honour the change.
1: Work backward from the readline internals to find out if it consults a
terminfo property to find out what ctrl-TAB might be.
2: Decide on what you want ctrl-TAB to send instead of the TAB code.
3: Make a new terminfo clause defining that (for readline's use) and hooking
onto your old terminfo definition for the rest (tc=other_terminal in termcap,
possibly the same in terminfo).
4: Configure your terminal emulator to send that sequence.
Regarding 4, with proper old-style X11 terminals you could control all this
directly with the VT100.Translations properties. Example from my xterm
Xdefaults file; the leading F1 definition is probably what you want:
XTerm*.VT100.Translations: #override \n\
<KeyPress>F1 : string(0x1b) \n \
<KeyPress>F10 : secure() \n \
<KeyPress>KP_End : scroll-forw(100,page) \n \
<KeyPress>KP_Prior : scroll-back(1,halfpage) \n \
<KeyPress>KP_Next : scroll-forw(1,halfpage) \n\
<KeyPress>End : scroll-forw(100,page) \n \
Ctrl<KeyPress>Up : scroll-back(1,line) \n \
Ctrl<KeyPress>Down : scroll-forw(1,line) \n\
<KeyPress>Prior : scroll-back(1,halfpage) \n \
<KeyPress>Next : scroll-forw(1,halfpage) \n\
Meta<KeyPress> : string(0x1b) insert() \n\
Alt<KeyPress> : string(0x1b) insert() \n\
<KeyPress>BackSpace : string(0x08) \n \
Shift<Btn1Down> : ignore() \n\
Shift<Btn1Up> : insert-selection(PRIMARY,CUT_BUFFER0)\n\
<Btn2Down> : ignore() \n\
<Btn2Up> : insert-selection(PRIMARY,CUT_BUFFER0)\n\
Shift<Btn2Down> : ignore() \n\
Shift<Btn2Up> : string("us ") insert-selection(PRIMARY,CUT_BUFFER0)
string("\n") \n\
~Ctrl ~Meta<Btn3Down> : ignore()\n\
~Ctrl ~Meta<Btn3Up> : ignore()\n
! commented out, previous experiments
! XTerm*VT100.translations: #override Shift<Key>'F1':insert("hi guys")
! XTerm*VT100.translations: #override
Ctrl<Key>'U':uphalfscreen()\nCtrl<Key>'D'downhalfscreen()
The new fangled terminals like gnome-terminal or Konsole probably threw that
stuff out as they threw out all the other normal X11 config hooks, and
doubtless use their own arcane system. Enjoy.
Cheers,
Cameron Simpson <c...@zip.com.au>
The top three answers: Yes I *am* going to a fire!
Oh! We're using *kilometers* per hour now.
I have to go that fast to get back to my own time.
- Peter Harper <bo...@freenet.carleton.ca>
--
https://mail.python.org/mailman/listinfo/python-list
