I think the issue of backwards compatibility should be kept as simple as possible. Nothing should change in the way that you can currently use VimL (a.k.a. Vim Script) inside you .vimrc or in any other .vim file.
For example, you can currently do map <tab> :echo "does something" *or* map <c-i> :echo "does something" to achieve the same exact thing. For the sake of simplicity, IMHO, users should be able to write exactly the same VimL (Vim Script), *but* the results would *not* achieve the same thing. The mappings would be taken literally. For example, the user can do map <tab> :echo "does something" *and* map <c-i> :echo "does something *else*" to achieve two different things. Simple. The user need not know anything about the inner implementation of vim, and there need not be anything new to learn about writing VimL (Vim Script) except that your mappings are taken literally and no mapping identifier is *ever* and alias to another identifier. Plain and simple. */#!/*JoePea On Wed, Oct 16, 2013 at 8:46 AM, Nikolay Pavlov <[email protected]> wrote: > > On Oct 16, 2013 4:43 PM, "Paul LeoNerd" <[email protected]> wrote: > > > > On Tue, 15 Oct 2013 12:03:41 -0700 (PDT) > > ZyX <[email protected]> wrote: > > > > > 2. Second problem is pure technical: someone must sit down and code > > > this. Maybe use some terminal library, maybe not. > > > > Not wanting to sound like a broken record, but this suggestion is > > basically what I keep making every few years. > > > > If the input queue internals are updated to support arbitrary key > > sequences, then it becomes trivial to attach something like my > > libtermkey to feed that input queue from the terminal. > > > > http://www.leonerd.org.uk/code/libtermkey/ > > > > The first hurdle is getting anyone sufficiently close-to-core to accept > > /that/ the problem needs fixing, and only thereafter to accept /how/. > > As far as I see discussion always stucks at discussing backward > compatibility. My suggestion is that as we cannot make an agreement > backward compatibility should be kept fully (regarding things like CTRL-I > vs TAB, not undistinguishable CTRL-L and CTRL-SHIFT-L) and code should be > written. Not continue discussing WTF we are going to do with tabs. Not > trying to push backwards incompatibility. And not writing code that will be > tricky like having something to specify "here we mean Tab", "here we mean > CTRL-I" and "here we mean any of them" which will likely mean having a > bunch of hacks in mapping processing code. All these may be written later > if needed. > > It is better to not have an agreement on what to do with Tabs and have a > patch to the input system then both not have an agreement and not have > patch. Also if you do not introduce incompatibility, but have written a > patch without Bram explicitly writing that this patch will be accepted once > written you have rather good chances to make it accepted with the support > from community. If you do introduce incompatibility this will be more > tricky. > > Also did not Bram already agree on the existence of the problem? > > > -- > > Paul "LeoNerd" Evans > > > > [email protected] > > ICQ# 4135350 | Registered Linux# 179460 > > http://www.leonerd.org.uk/ > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to a topic in the > Google Groups "vim_dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
