Loading ...
Sorry, an error occurred while loading the content.

Re: Supporting more key modifiers (was: Re: Dear Bram)

Expand Messages
  • Paul LeoNerd Evans
    ... That s OK. For them it can be mapped. Or even made default. ... Changing terminal emulators is a done task; xterm has supported this since 2008. In fact I
    Message 1 of 112 , Mar 7, 2011
    • 0 Attachment
      On Fri, Feb 25, 2011 at 02:43:23PM +0100, Bram Moolenaar wrote:
      > So the problem is that many users expect CTRL-M to have the same effect
      > as Enter, just like people use CTRL-[ instead of Esc. And a few people
      > would make the CTRL-M act different from Enter, and CTRL-[ different
      > from Esc.

      That's OK. For them it can be mapped. Or even made default.

      > First problem is to actually detect what key was pressed, in most
      > terminal emulators this is not possible. In the GUI we can. Changing
      > terminal emulators to support this and making this work with Vim is a
      > separate issue, I'll not go into that here.

      Changing terminal emulators is a done task; xterm has supported this
      since 2008. In fact I asked Thomas Dickey to clarify this for me, and he
      informs me it's all present and working.

      > Then we need a way to make the extra information available to be used in
      > mappings, without breaking it for users relying on the current way.
      >
      > Some things that are no acceptable:
      > - Have a setting to enable "the new way".

      Really?

      Is that what we'd have said right back at the beginning of Vim? On the
      subject of the 'compatible setting:

      "Adding a setting to enable all the vim-incompatible changes, is too
      complex for users to handle."

      > This will break existing
      > stuff and make users pull their hair out because they don't know this
      > setting exists. Forget it.

      Right now we have users _all the time_ pulling their hair out _because_
      such a setting does not exist. Including myself. I would much rather
      have to support hoards of confused users in #vim by saying to them

      "Yes, sorry your vim can't recognise that keypress now, but set this
      setting and then it will"

      instead of

      "No, sorry your vim cannot recognise that keypress at all"

      If you would prefer to support people by telling them it is not
      possible, rather than telling them how to make it possible, please come
      to #vim and explain that to them. Every week.

      > - Change the input queue from a stream of bytes to some list of structs.
      > This isn't adding any functionality and breaks all kinds of mapping
      > and termcode handling, register execution, etc. Forget it.

      OK, well that's fair. It was intended as an implementation detail in any
      case. I hadn't realised it would be possible with the existing byte
      queue.

      As long as the two triplets of keypresses I suggested originally can all
      be represented uniquely, and without reference to timing information in
      the Escape vs Alt+ case, then I'm happy with whatever internal
      implementation makes it happen.

      > What we can do is extend the existing modifier byte sequence.
      <snip long description>

      That all sounds a bit long and complicated, and I'm not sure I see
      whether it's necessarily any easier to implement than the arguably
      much-neater and more forward-compatible queue-of-structures idea I had
      originally. But again, that's all internal implementation details -
      whatever makes it work, I'm happy with.

      > We also need a way to specify mappings with the new modifier, perhaps
      > using a special modifier X, thus you could do:
      > :map <X-C-[> :echo CTRL-[<CR>
      > :map <X-C-I> :echo CTRL-I<CR>

      X for "eXtended"? Could work, though would be useful to check that
      doesn't collide with any named modifiers on any existing system. Perhaps
      some non-letter punctuation symbol? Though nothing suitable comes to
      mind.

      --
      Paul "LeoNerd" Evans

      leonerd@...
      ICQ# 4135350 | Registered Linux# 179460
      http://www.leonerd.org.uk/
    • Paul "LeoNerd" Evans
      On Tue, 21 Oct 2014 20:49:40 +0200 ... pangoterm, or continue prodding at xterm until it does the right thing :) Or provoke your preferred terminal s author
      Message 112 of 112 , Nov 6, 2014
      • 0 Attachment
        On Tue, 21 Oct 2014 20:49:40 +0200
        Christian Brabandt <cblists@...> wrote:

        > > In theory, yes. In practice, last time I looked xterm didn't do it
        > > quite right yet.
        > >
        > > The setting is called modifyOtherKeys but the problem with is was
        > > that it either modifies too little (leaving such pairs as Ctrl-a and
        > > Ctrl-Shift-A indistinct), or modifies too much (using CSI u encoding
        > > for a plain Ctrl-c keypress, thus meaning termios doesn't recognise
        > > it and send a SIGTERM). I have re-raised this with Thomas just now;
        > > I'll see if we can get to a point where it's just in the middle, and
        > > therefore right.
        >
        > So what would be the preferred way to actually see those keys?
        > Installing pangoterm?

        pangoterm, or continue prodding at xterm until it does the right
        thing :)

        Or provoke your preferred terminal's author into fixing it.

        More consensus among terminals => better.

        --
        Paul "LeoNerd" Evans

        leonerd@...
        http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
      Your message has been successfully submitted and would be delivered to recipients shortly.