How about in-built camelcase movement support?
hari.ra...@gmail.com
I was thinking of a simple extension: key off the 'iskeyword' option in-addition with a 'camelcase_keyword_movement' boolean option which would treat the 'iskeyword' as separate character sets.
An example:
set iskeyword = 'A-Z,a-z,0-9,_' .
set camelcase_keyword_movement = 1
The keyword list is broken up into different sets: [A-Z],[a-z],[0-9],[_]. From an implementation perspective, movement will break everytime we hit a character that is in a different set when traversing "words". All vim movement commands should implicitly derive this functionality (I hope :) ).
In the other case, where camelcase_keyword_movement = 0, it will be just default behavior.
Thoughts?
Marc Weber
> For the record, I have gone through the solutions at this wiki:
> http://vim.wikia.com/wiki/Moving_through_camel_case_words; however, I was
> still left wondering if there has been an attempt to solve the camel case
> word movement natively in Vim, as a lot of code does use this convention.
Why do it natively if you can do it with some lines of VimL?
Also am I right that those mappings jump to the next upper char only?
Eg |TryThisExample ..
If | is curser I prefer fE rather than 2<whatever mapping>
For more complicated things I always use search.
I don't expect the implementation to be complicated.
orobably the most important question is which mappings to choose.
Probably the most important question is which mappings to choose.
Do you suggest those c-left c-right mappings?
However I'd like to have a native camel case matching for completion to
speed it up. vim-addon-completion implements a regex solution.
Its not urgent enough to take action.
Marc Weber
hari.ra...@gmail.com
Vim has "word" and "WORD" movements. In a typical coding setup, there is not much of a distinction between the two (except you can remove '_' for help with unix style convention).
The definition of "word" can be changed by modifying "iskeyword" option; however, its quite limiting, you can only pick what characters can be part of a "word". What I'm proposing is that we add more definition to "word" that it can be naturally extended to camelcase through the use of multiple character sets. Moving from one character set to another is equivalent to moving between "words". The mappings remain the same, "w", "b", "e", "ge". And, implicitly, all other movement mappings move through "camelcase" words.
What should be built-in or extended through vimL is definitely a philosophical question. IMHO, I feel something like camelcase as a standard toggle-able feature would be nice.
Ingo Karkat
> For the record, I have gone through the solutions at this wiki:
> http://vim.wikia.com/wiki/Moving_through_camel_case_words; however, I
> was still left wondering if there has been an attempt to solve the
> camel case word movement natively in Vim, as a lot of code does use
> this convention.
>
> I was thinking of a simple extension: key off the 'iskeyword' option
> in-addition with a 'camelcase_keyword_movement' boolean option which
> would treat the 'iskeyword' as separate character sets.
I am the author of camelcasemotion
(http://www.vim.org/scripts/script.php?script_id=1905), which is a vimscript
implementation based off the mentioned Vim tip. The plugin supports both
CamelCaseWords and underscore_notation, which I think is a crucial requirement,
also for any native solution, because:
1. both notations complement each other, sometimes are even used together (e.g.
CamelCase_MixedNotation)
2. both overloading the default w/e/b mappings or providing additional ones (the
plugin defaults to ,w/,e/,b) covers / consumes a lot of mappings, and therefore
should be as general and applicable as possible.
The many users who have downloaded the plugin seem to be quite happy with it,
even though there are some rare corner cases where it won't work right. I agree
with you that for something so common as CamelCaseWords and underscore_notation,
a native implementation built into Vim would be beneficial. However, I would
argue that such an implementation would have to be general (i.e. covering at
least CamelCaseWords and underscore_notation), configurable (e.g. override /
additional mappings, select underscore separators [_-], stuff like 'iskeyword'),
and complete (covering motions as well as new text objects).
If someone is motivated to invest the huge effort that such a full
implementation would comprise (and Bram signals that he'd consider including
such an enhancement), I'd be happy to provide feedback and reviews.
-- regards, ingo
Marc Weber
then dX vX =X etc would work where X is the custom vimL code moving the
cursor?
Something like
:setlocal custommovement=camelcase#CamelCaseMovement
What about "regions" ? Does something like this already exist for
regions?
What's the main point about "being native"? That you don't have to get
custom .vimrc ?
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 ..
By the way: I vote for <c-e> being native which works in insert mode due
to custom mappings
Marc Weber
Ingo Karkat
> 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
Marc Weber
> uses.
> 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.
Well - having curl would be a good idea anyway :)
Marc Weber
hari.ra...@gmail.com
Ingo -- I did check out your plugin, and I might actually end up using it regularly :). There were a basic things
which caught my eye as incomplete: Is there a reason you didn't choose to implement the 'ge' operator?
o <Plug>CamelCaseMotion_ie * :<C-U>call camelcasemotion#InnerMotion('e',v:count1)<CR>
o <Plug>CamelCaseMotion_iw * :<C-U>call camelcasemotion#InnerMotion('w',v:count1)<CR>
o <Plug>CamelCaseMotion_e * :<C-U>call camelcasemotion#Motion('e',v:count1,'o')<CR>
o <Plug>CamelCaseMotion_b * :<C-U>call camelcasemotion#Motion('b',v:count1,'o')<CR>
o <Plug>CamelCaseMotion_w * :<C-U>call camelcasemotion#Motion('w',v:count1,'o')<CR>
hari.ra...@gmail.com
> What's the main point about "being native"? That you don't have to getFor me, that would be:
> custom .vimrc ?
- 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
These are excellent points. I'm sure a lot of us would agree with this.
The other question is whether a sizeable population works on camelcase code and
would like to have this solved :).
Ingo Karkat
> Ingo -- I did check out your plugin, and I might actually end up using
> it regularly :). There were a basic things which caught my eye as
> incomplete: Is there a reason you didn't choose to implement the 'ge'
> operator?
>
You're right, there's currently no "ge". First of all, I rarely use the built-in
one (I simply haven't committed this to muscle memory yet), and second, the
motions are driven by regular expressions with many different branches that
often interact in strange ways, so skipping this one case made it easier for me
to develop.
I guess eventually this will be implemented; before that happens I'd need to
invest in automated testing / verification, but then the current motions seem to
work quite well, so there's no pressing need for that. Classic hen-egg problem :-)
-- regards, ingo
Ben Schmidt
> code and would like to have this solved :).
I would like to see a camelcase and/or underscore-seperation movement
commands. But I think if done, it has to be done really carefully so it
doesn't end up using obscure keys or mashes, or hideously complicated
options, or we turn Vim into Emacs....
Ben.
Christian Brabandt
Here is a patch, that implements gc (goto next camelcase char,
inclusive) and gC (goto previous camelcase char, exclusive).
But I have only barely tested it.
regards,
Christian
--
Wie selbst jeder Bauer wei�, macht Microsoft oft gro�en Mist.
Tony Mechelynck
Use an operator-pending mapping, you can define any movement or object then.
See
:h operator
:h Operator-pending-mode
:h v:operator
etc.
Best regards,
Tony.
--
The University of California Bears announced the signing of Reggie
Philbin to a letter of intent to attend Cal next Fall. Philbin is said
to make up for no talent by cheating well. Says Philbin of his
decision to attend Cal, "I'm in it for the free ride."