> This would be easier if we actually had a solid 'new design'. We don't.
> We just have a bunch of rough ideas. One of those ideas had a drafted
> structure and suggestion that it be used only in the input queue, where
> the memory inefficiency would not be a concern. I have pointed out that
> there are many other problems to solve: right hand sides of mappings,
> feedkeys(), registers for macro recordings (which indirectly affect
> buffers, as registers must be able to be put and yanked), representation
> in strings, and more (I just thought of the :normal command, and I'm
> sure there is still more...). I pointed out that if you use the
> structure to solve all these problems, memory efficiency is most
> certainly a concern.
> My response, to both that specific proposal and that general approach is
> that I don't think it is a good way, because it is massively
> backwards-incompatible and a lot of work.
> But as a community member, I'd prefer it if it affected my code and
> plugins as little as possible, and I consider it essential that Vim
> doesn't become significantly less efficient because of this. And if it
> were me considering an implementation, I'd certainly be looking for the
> option that was the least work! YMMV.
So basically backward compatibility and memory efficiency are what
hold vim back in 1970. You made a lot of good points and reasons for
it to be so, but I'm always sad when good ideas are refused just
because of old scenarios. I mean I wouldn't care if vim went as far as
doubling its memory usage and broke backward compatibility if what I
gain in exchange is modernity, but I guess not everyone is like me. I
just think old hardware should use old software and that new hardware
should use new software, I understand backward compatibility is what
makes a software like vim able to run on my toaster, but I wouldn't
mind using an older version of vim on that toaster.
That said, I think there is a compromise. Vim has features, maybe the
new input mechanism could simply be a feature, something like
+enhanced_term_input (like we have for +python or +eval), and plugins
could simply check with stuffs like:
if has('enhanced_input') == 0
echom 'Vim wasn't compiled with +enhanced_input, the plugin's
default mappings (<C-i>, etc) were remaped'
call s:UseOldMappings()
endif
I think this would please everyone. People wanting vim not to change a
single bit can, people wanting it to evolve can. Of course there's
still all the issues discussed above to solve, but at least I think
with this proposal things we'll get less resistance ;)
Thanks,
Philippe
--
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
