Inconsistent behaviour of w motion #13160
Replies: 7 comments
-
You should be able to always insert at the end of a word using |
Beta Was this translation helpful? Give feedback.
-
@CptPotato |
Beta Was this translation helpful? Give feedback.
-
Could you provide an example? I'm not sure if I undertood the issue. Have you tried with |
Beta Was this translation helpful? Give feedback.
-
Changed my whole post |
Beta Was this translation helpful? Give feedback.
-
If I understood, you start on the first character and your text looks like: I don't think it could look like: In the first case pressing Pressing The issue seems to be because a comma is treated as a separate lowercase One possible solution for you could be to try If you wanted these two blocks of text to behave the exact same for despite the added comma, I don't know if I can help in this case. Having the comma treated as a separate 'word' I believe was a deliberate choice, though I could be mistaken. Side tangent: |
Beta Was this translation helpful? Give feedback.
-
As a follow up comment and I think the better point to all of this is that w and e behave the same in every case. The comma is treated as a separate word for w and e, but all non white-space connected characters are included for W and E just like it is in vim. both dw and de do not remove the comma in vim doing df, removes the comma in vim |
Beta Was this translation helpful? Give feedback.
-
You are seeing issues becahse you are trying to use motions in isnertmode. That os out of scope and generally not something we support. Helix is a modal editor first and foremost. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
NOTE: i may be saying w or e as the opposite of what they do as i have them set to subwords and i may have set them differently and i also might be saying the _end and _start thingy as i am going off of memory
So, when doing
e
->block goes to last character of the word in that case you doa
or as i like to;a
to get rid of selectionw
->you go to the whitespace after the end of the word so you go;i
But when there is a comma at the end of word
in both
w
ande
the block goes to the last character of the wordI don't think they should behave differently in this case, it would be much more helpful in editing if it selected the comma as well
e by default is
"move_next_word_end"
w by default is
"move_next_word_start"
Also something i have is
[editor.cursor-shape]
insert = "bar"
insert mapping:
c-left = ["move_next_sub_word_end", "collapse_selection"]
or
c-left = ["move_next_sub_word_start", "collapse_selection"]
if the word doesn't have a comma at the end -> 1 puts cursor after the last character and 2 put the cursor before the last character
if the word does have a comma at the end -> 1 and 2 both do the same thing i.e, put the cursor before the last character of the word(1 should put the cursor after the last character of the word)
I think it should do what it says it does and always be consistent
c-left
that I et up is not big deal as i plan to abandon it but this also screw up key binds likekey = ["do_stuff", "insert_mode", "move_next_word_end", "do stuff"]
you have to work around it by doing
key = ["do_stuff",,"insert_mode", "do_stuff", "normal_mode", "move_next_word_end", "append", "collapase_selection", "do stuff"]
W
or"move_next_long_word_end"
doesn't work as i want it to go by sub word so what i want is to just place the block on the comma(bar after the last character of word) when doingw
ore
whichever is the correct one. Dont wanna have a seperate keybind for itIIRC neovim also does this
dw
to remove the word with the commade
to remove the wordwhich is definitely exactly what i want as it makes me much faster
Beta Was this translation helpful? Give feedback.
All reactions