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

Re: Improve vim's keyboard input subsystem

Expand Messages
  • Paul LeoNerd Evans
    ... Sure. That s for real character input. ; is a printing character. What about the up arrow? The idea of terminfo may be to represent abstracted key
    Message 1 of 21 , May 2, 2008
      On Fri, Apr 18, 2008 at 10:48:48AM -0700, Gary Johnson wrote:
      > I believe the idea of terminfo is to have symbols for keys'
      > functions, not how you pressed them, i.e., to separate function from
      > mechanism. Type the ; key, getch() returns ';'. Hold the Shift key
      > and type the ; key, getch() returns ':' (on my keyboard), not some
      > code for Shift-;.

      Sure. That's for real character input. ; is a printing character.

      What about the up arrow?

      The idea of terminfo may be to represent abstracted key functions, but
      that doesn't seem to be the way people are heading now. GTK, X11,
      XTerm's new CSIs, .. the way Vim itself tries to :map keys. These all
      want to work by a {set of modifiers + base key} concept. Yes, I'm
      willing to accept that : is just Shift-;. Shift it simply the mechanism
      used to obtain the :. But what of Up arrow. Shift-Up. Ctrl-Up.
      Alt-Hyper-Ctrl-Up. ?

      > > Furthermore, explain where in termcap/terminfo I can find any hint of
      > > knowledge about modifiers?
      >
      > Again, I believe the absence of knowledge about modifiers is by
      > design. The application should care only about the key's function,
      > not what the user had to do on any particular keyboard to get that
      > function.

      Again... Note the way that everyone seems to want these modifiers.

      Terminfo's way of abstracting that out into a flat list of symbols may
      have made a lot of sense some time ago. But this is now, not then. We do
      have real Ctrl / Alt / Hyper / Super keys. People do seem to want
      modified function keys. I'm simply trying to provide them what they
      want, rather than tell them they shouldn't want it.

      > Terminfo/curses presents a higher-level abstraction of a keyboard
      > than your library does. That abstraction has some limits. Your
      > abstraction has benefits and costs, which are certainly worth
      > discussing. For the present, I just wanted to correct the notion
      > that terminfo/curses doesn't handle keyboard input well.

      OK. Then perhaps I'll change my wording.

      terminfo/curses doesn't handle the sort of keyboard input that I and a
      lot of other people seem to want. Something has to budge. Either Vim
      needs to be able to handle those, or we as users need to be told "No,
      you don't want Shift-Up. That's a stupid thing to want."

      --
      Paul "LeoNerd" Evans

      leonerd@...
      ICQ# 4135350 | Registered Linux# 179460
      http://www.leonerd.org.uk/
    • Bram Moolenaar
      ... I don t see the point. The connection between the terminal and Vim is a byte stream. Vim needs to decode the bytes somehow to extract keys that were
      Message 2 of 21 , May 2, 2008
        Paul LeoNerd Evans wrote:

        > On Fri, Apr 18, 2008 at 02:02:37AM +0200, Bram Moolenaar wrote:
        > > The idea of termcap/terminfo is that you don't force terminals to send a
        > > specific escape sequence and don't force applications to accept a
        > > certain sequence. You make a table that specifies it, so that you can
        > > use any terminal with any application.
        >
        > > The current termcap/terminfo implementation is terribly outdated,
        > > obviously, but that doesn't mean we now should drop the idea and
        > > set the escape sequences in stone.
        >
        > Sure. Then lets discuss that. There's no reason we have to take one side
        > or the other - both can be made to work together.
        >
        > After all, even libtermkey has to know -somehow- that CSI function key 2
        > is really Insert, etc... Perhaps it could know that by parsing CSIs
        > found in the terminfo database anyway?
        >
        >
        > In any event, I think my actual point got lost here. My actual point
        > was:
        >
        > Vim's core needs to deal with abstract keypresses, not sequences of
        > bytes. This will allow all sorts of nice things from the GUI and
        > similar.
        >
        > My suggestions on the terminal end of things are moreorless an
        > afterthought.
        >
        > With a nicer more abstracted core, I see no reason why 'vim' itself
        > can't stick to using prefix matching of terminfo strings, and there to
        > be a new frontend, perhaps 'tvim', which feeds key input using my
        > libtermkey, in a similar way to 'gvim' which feeds it from GTK.

        I don't see the point. The connection between the terminal and Vim is a
        byte stream. Vim needs to decode the bytes somehow to extract keys that
        were pressed. Since Vim supports many terminals, this decoding needs to
        be done by defining what each byte sequence means for each terminal. I
        don't see a way around this. Also keep in mind that mappings can be
        used to map raw byte sequences, before the decoding happens. So you
        can't filter the byte sequence before sending it to Vim.

        --
        ARTHUR: Shut up! Will you shut up!
        DENNIS: Ah, now we see the violence inherent in the system.
        ARTHUR: Shut up!
        DENNIS: Oh! Come and see the violence inherent in the system!
        HELP! HELP! I'm being repressed!
        The Quest for the Holy Grail (Monty Python)

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Paul LeoNerd Evans
        On Fri, 02 May 2008 22:23:44 +0200 Bram Moolenaar wrote:I don t see the point.In that case, I d like to hear your suggestion on how
        Message 3 of 21 , Jun 9, 2008
          On Fri, 02 May 2008 22:23:44 +0200
          Bram Moolenaar <Bram@...> wrote:

          > I don't see the point.

          In that case, I'd like to hear your suggestion on how I may use
          combinations of Shift/Ctrl/Alt with keypresses in a normal vim.

          Currently, the only way I find that works at all is to keep a giant list
          of :map and :map! commands, which recognise the sequences. See the
          attached file.

          This sortof works; it's enough to get things like Ctrl-LR to be move word
          left/right, Alt+arrow to be move focus to window, and Alt+[number] to
          be :b1 to :b10.

          It doesn't work in paste mode, and it upsets the ttytime settings.

          Also, it breaks UTF-8 input if I try to map Alt+letter.


          If you know of a better way to make all these things possible, I would
          very much like to hear it.

          --
          Paul "LeoNerd" Evans

          leonerd@...
          ICQ# 4135350 | Registered Linux# 179460
          http://www.leonerd.org.uk/
        • Bram Moolenaar
          ... Nothing special, most of them can be recognized already. Especially if you are using an xterm. Try :set term=xterm and then :set termcap . The entries
          Message 4 of 21 , Jun 9, 2008
            Paul LeoNerd Evans wrote:

            > On Fri, 02 May 2008 22:23:44 +0200
            > Bram Moolenaar <Bram@...> wrote:
            >
            > > I don't see the point.
            >
            > In that case, I'd like to hear your suggestion on how I may use
            > combinations of Shift/Ctrl/Alt with keypresses in a normal vim.

            Nothing special, most of them can be recognized already. Especially if
            you are using an xterm. Try ":set term=xterm" and then ":set termcap".
            The entries which contain ";*" recognize modifier keys. For other
            terminals you will need to add the termcap entries somehow.

            > Currently, the only way I find that works at all is to keep a giant list
            > of :map and :map! commands, which recognise the sequences. See the
            > attached file.
            >
            > This sortof works; it's enough to get things like Ctrl-LR to be move word
            > left/right, Alt+arrow to be move focus to window, and Alt+[number] to
            > be :b1 to :b10.
            >
            > It doesn't work in paste mode, and it upsets the ttytime settings.
            >
            > Also, it breaks UTF-8 input if I try to map Alt+letter.

            Alt-letter is supposed to work to get the letter with the 8th bit set.
            Then converted to whatever encoding you are using. This is how vi
            traditionally works, in combination with traditional terminals (and
            terminal emulators).

            Also note that things like <Esc>0 should never be produced by a single
            key, since it should mean <Esc> (leave Insert mode), and zero (go to
            first column). Relying on timing is not a good idea.

            > If you know of a better way to make all these things possible, I would
            > very much like to hear it.

            It appears you need to read :help xterm-modifier-keys

            --
            Anyone who is capable of getting themselves made President should on no
            account be allowed to do the job.
            -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Paul LeoNerd Evans
            On Mon, 09 Jun 2008 17:41:00 +0200 ... Yes; that works on real vim-in-xterm. But what of e.g. screen? When I m editing an email in mutt, running via screen,
            Message 5 of 21 , Jun 9, 2008
              On Mon, 09 Jun 2008 17:41:00 +0200
              Bram Moolenaar <Bram@...> wrote:

              > > In that case, I'd like to hear your suggestion on how I may use
              > > combinations of Shift/Ctrl/Alt with keypresses in a normal vim.
              >
              > Nothing special, most of them can be recognized already. Especially if
              > you are using an xterm. Try ":set term=xterm" and then ":set termcap".
              > The entries which contain ";*" recognize modifier keys. For other
              > terminals you will need to add the termcap entries somehow.

              Yes; that works on real vim-in-xterm. But what of e.g. screen? When I'm
              editing an email in mutt, running via screen, this uses vim. vim starts
              up with $TERM=screen, not xterm, so doesn't know to do that.

              Perhaps to handle this case, vim ought always to recognise the ;* entries?

              > > Currently, the only way I find that works at all is to keep a giant list
              > > of :map and :map! commands, which recognise the sequences. See the
              > > attached file.
              > >
              > > This sortof works; it's enough to get things like Ctrl-LR to be move word
              > > left/right, Alt+arrow to be move focus to window, and Alt+[number] to
              > > be :b1 to :b10.
              > >
              > > It doesn't work in paste mode, and it upsets the ttytime settings.
              > >
              > > Also, it breaks UTF-8 input if I try to map Alt+letter.
              >
              > Alt-letter is supposed to work to get the letter with the 8th bit set.
              > Then converted to whatever encoding you are using. This is how vi
              > traditionally works, in combination with traditional terminals (and
              > terminal emulators).
              >
              > Also note that things like <Esc>0 should never be produced by a single
              > key, since it should mean <Esc> (leave Insert mode), and zero (go to
              > first column). Relying on timing is not a good idea.

              I'm aware of the problems with timing :)

              Seems we're stuck though, ultimately.. we can't make all three of
              <Esc>letter, <Alt-letter> and UTF-8 work.

              > > If you know of a better way to make all these things possible, I would
              > > very much like to hear it.
              >
              > It appears you need to read :help xterm-modifier-keys

              Again, I'm aware of it. I'm aware that it doesn't apply during screen.

              How would you recommend I make vim-in-screen work, then? Just set
              TERM=xterm or some vim-specific fiddling if it notices $TERM == screen ?


              I still think ultimately a rethink of the bottom input layer is best
              here... I can make it not break anything that currently works... Read
              terminfo just as before - it'll still JustWork on your 1970s glass
              teletype that sends Weird Sequences. It'll just happen to work better on
              a modern xterm. And as a side-effect, GDK and other input layers will
              work better.

              I'm still failing to understand your hostility toward it.

              --
              Paul "LeoNerd" Evans

              leonerd@...
              ICQ# 4135350 | Registered Linux# 179460
              http://www.leonerd.org.uk/
            • Bram Moolenaar
              ... No, because only a few terminals send these codes. Instead, add the entries in the termcap/terminfo. That might break other programs though. You can
              Message 6 of 21 , Jun 9, 2008
                Paul LeoNerd Evans wrote:

                > On Mon, 09 Jun 2008 17:41:00 +0200
                > Bram Moolenaar <Bram@...> wrote:
                >
                > > > In that case, I'd like to hear your suggestion on how I may use
                > > > combinations of Shift/Ctrl/Alt with keypresses in a normal vim.
                > >
                > > Nothing special, most of them can be recognized already. Especially if
                > > you are using an xterm. Try ":set term=xterm" and then ":set termcap".
                > > The entries which contain ";*" recognize modifier keys. For other
                > > terminals you will need to add the termcap entries somehow.
                >
                > Yes; that works on real vim-in-xterm. But what of e.g. screen? When I'm
                > editing an email in mutt, running via screen, this uses vim. vim starts
                > up with $TERM=screen, not xterm, so doesn't know to do that.
                >
                > Perhaps to handle this case, vim ought always to recognise the ;* entries?

                No, because only a few terminals send these codes. Instead, add the
                entries in the termcap/terminfo. That might break other programs
                though. You can also use a Vim script to set them. Or a shell wrapper
                around Vim. All that works but isn't nice.

                > > > Currently, the only way I find that works at all is to keep a giant list
                > > > of :map and :map! commands, which recognise the sequences. See the
                > > > attached file.
                > > >
                > > > This sortof works; it's enough to get things like Ctrl-LR to be move word
                > > > left/right, Alt+arrow to be move focus to window, and Alt+[number] to
                > > > be :b1 to :b10.
                > > >
                > > > It doesn't work in paste mode, and it upsets the ttytime settings.
                > > >
                > > > Also, it breaks UTF-8 input if I try to map Alt+letter.
                > >
                > > Alt-letter is supposed to work to get the letter with the 8th bit set.
                > > Then converted to whatever encoding you are using. This is how vi
                > > traditionally works, in combination with traditional terminals (and
                > > terminal emulators).
                > >
                > > Also note that things like <Esc>0 should never be produced by a single
                > > key, since it should mean <Esc> (leave Insert mode), and zero (go to
                > > first column). Relying on timing is not a good idea.
                >
                > I'm aware of the problems with timing :)
                >
                > Seems we're stuck though, ultimately.. we can't make all three of
                > <Esc>letter, <Alt-letter> and UTF-8 work.
                >
                > > > If you know of a better way to make all these things possible, I would
                > > > very much like to hear it.
                > >
                > > It appears you need to read :help xterm-modifier-keys
                >
                > Again, I'm aware of it. I'm aware that it doesn't apply during screen.
                >
                > How would you recommend I make vim-in-screen work, then? Just set
                > TERM=xterm or some vim-specific fiddling if it notices $TERM == screen ?
                >
                >
                > I still think ultimately a rethink of the bottom input layer is best
                > here... I can make it not break anything that currently works... Read
                > terminfo just as before - it'll still JustWork on your 1970s glass
                > teletype that sends Weird Sequences. It'll just happen to work better on
                > a modern xterm. And as a side-effect, GDK and other input layers will
                > work better.
                >
                > I'm still failing to understand your hostility toward it.

                I know the current termcap/terminfo system is outdated and insufficient
                for modern terminal emulaters. The solution should be changing
                termcap/terminfo into some better library. The actual escape sequences
                used can remain the same.

                GUIs already have a way to handle arbitrary key presses. Unfortunately,
                they are very complicated to use. Especially when it comes to handling
                different keyboard layouts. Look in the Vim GUI code to see what's done
                there, it's far from nice.

                --
                Far back in the mists of ancient time, in the great and glorious days of the
                former Galactic Empire, life was wild, rich and largely tax free.
                Mighty starships plied their way between exotic suns, seeking adventure and
                reward among the furthest reaches of Galactic space. In those days, spirits
                were brave, the stakes were high, men were real men, women were real women
                and small furry creatures from Alpha Centauri were real small furry creatures
                from Alpha Centauri. And all dared to brave unknown terrors, to do mighty
                deeds, to boldly split infinitives that no man had split before -- and thus
                was the Empire forged.
                -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ download, build and distribute -- http://www.A-A-P.org ///
                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Paul LeoNerd Evans
                On Mon, 09 Jun 2008 21:04:51 +0200 ... So, do you suggest that screen s termcap/terminfo DBs ought to contain these items? ... And that is exactly what I
                Message 7 of 21 , Jun 9, 2008
                  On Mon, 09 Jun 2008 21:04:51 +0200
                  Bram Moolenaar <Bram@...> wrote:

                  > No, because only a few terminals send these codes. Instead, add the
                  > entries in the termcap/terminfo. That might break other programs
                  > though. You can also use a Vim script to set them. Or a shell wrapper
                  > around Vim. All that works but isn't nice.

                  So, do you suggest that screen's termcap/terminfo DBs ought to contain
                  these items?

                  > I know the current termcap/terminfo system is outdated and insufficient
                  > for modern terminal emulaters. The solution should be changing
                  > termcap/terminfo into some better library. The actual escape sequences
                  > used can remain the same.

                  And that is exactly what I propose.

                  My "libtermkey" library already understands the byte sequences that xterm
                  _already_ throws. I made a whole load of suggestions on how to extend
                  these byte seq.s to fix a few problems with the current encoding, but
                  that was more of a side interest... Nothing stops libtermkey from simply
                  abstracting out what termcap/terminfo already provide. It's an extension
                  of, not a replacement.

                  --
                  Paul "LeoNerd" Evans

                  leonerd@...
                  ICQ# 4135350 | Registered Linux# 179460
                  http://www.leonerd.org.uk/
                Your message has been successfully submitted and would be delivered to recipients shortly.