On 17-May-2011 10:33, Marc Weber wrote: > Can't we make Vim accept custom moves then? > > then dX vX =X etc would work where X is the custom vimL code moving the > cursor? > > Something like > > :setlocal custommovement=camelcase#CamelCaseMovement
And this new setting would affect the "word-wise" movement-commands w/e/b? What's the benefit over simply remapping these? You can already implement custom motions via :omap; that's what camelcasemotion uses. > What about "regions" ? Does something like this already exist for > regions? Custom text objects can be implemented today, too. In fact, I have authored the CountJump plugin (http://www.vim.org/scripts/script.php?script_id=3130), which allows you to easily setup such custom motions and text objects, and there are other plugins like that, too. > What's the main point about "being native"? That you don't have to get > custom .vimrc ? For me, that would be: - available everywhere, and therefore: - beneficial to all users (who are more likely to find the feature in the help than in one of thousands of plugins on vim.org which need to be actively searched for) - no hassle with syncing vimrc, on colleagues' systems and servers - more robust: some corner cases are difficult to handle in Vimscript; with native code you get all the power > Or is there more about it? > > If that's the point should't we make Vim compile with curl and allow it > to source a .vimrc over http? > > eg :customvimrc FOO where FOO points to http://vim.org/FOO/.vimrc ? > > Then you get much more .. I think there are many good syncing solutions already out there, and especially non-Windows users have a need for keeping several applications' RC files in sync. I personally use Unison; others VCSs like Git(Hub), or Dropbox. -- regards, ingo -- 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
