Sublime Forum

"Smart" horizontal cursor positioning

#7

Last year, found the idea interesting and try to implement it with the limited ST2 API, result:
A nightmare and nothing really useful.

But thinking it again last week and found a better way to do it:
Put the cursor back to the first edit position of the line BEFORE running the move command.
Still a nightmare with the actual ST2 api events, but works pretty well in most case.
And found it pretty useful.

Get it at https://github.com/bizoo/SmartCursor and add some keybindings to your user file based on the Example.sublime-keymap.

As I actually never try an editor with this behavior, feedback are welcomed.

1 Like
#8

I’m trying it out! I’ll let you know how I like it.
Thanks!

1 Like
#9

[quote=“adzenith”]I’m trying it out! I’ll let you know how I like it.
Thanks![/quote]

Thanks for trying it.

I pushed a small modification a few minutes ago.

Currently, IMHO, the only thing that doesn’t work as expected is when your starting edit point is beyond the end of the line when you move the cursor, as when you remove the end of a line using DEL key.
As this plugin put the cursor(s) back to the start edit position before moving it, there’s no way to do it with the current API.

If ST2 had virtual space (http://www.sublimetext.com/forum/viewtopic.php?f=4&t=805&start=0&hilit=virtual+space), this will not be an issue.
But it looks like virtual space potentially break most of the current API, or lot of new methods need to be added to deal with it.

1 Like
#10

Just had this thing fire for the first time while I was editing just now, and it turned out to be really awesome. Thanks!

1 Like
#11

I was going to report a bug, but then it was already fixed by that “small modification” you made. Thanks!

1 Like
#12

Bizoo, you may be able to implement this is a cleaner way using the xpos attribute of selection regions. If it’s not -1 when the caret is moved down a row, then it specifies the column (in layout coords) for the caret to be placed in.

You can see it in action by pressing end and then down: the caret will be maintained at EOL. Currently, it automatically set to -1 whenever the buffer is edited, so you’d need to find appropriate places to get and set the value.

3 Likes
How: Cursor beyond end-of-line?
Problem with xpos
Vintage mode, retain column position
Reset the move by lines target column
#13

Didn’t know about xpos, thanks for the heads-up.

But I don’t understand exactly what to do with it:
xpos() give me the ‘expected’ position for the cursor, but I don’t think there’s a way to set the xpos(), am I wrong ?

With my current implementation, I set the caret horizontal position before executing the move command.
This way the navigation are still managed by ST2 and work fine even if the next line (when move down) is smaller than the current caret position (so the xpos is correct out of the box).
The only problem is when you need the caret beyond the end of line, so when I need to set xpos.

If xpos is a read-only value, I don’t see any uses for this plugin (but could be useful for others).
Am I missing something ???

1 Like
#14

You can set the xpos by passing a 3rd argument to the Region constructor: sublime.Region(a, b, xpos)

1 Like
#15

Yeah ! Thanks for the helping hand John.

It looks like everything works fine now.
Maybe there’s still something to do to simplify the code, but I have no time right now to dig further… Maybe later.

Actually, I seriously think to replace the standard up/down cursor with these ones. But maybe jps already thought about putting something similar in the core ST2 :wink:

Grab it at https://github.com/bizoo/SmartCursor and give it a try.

1 Like
#16

For what it’s worth, I’ve replaced the standard up and down arrows with this. I did this:

[code] { “keys”: “up”], “command”: “smart_cursor”, “args”: {“cmd”: “move”, “by”: “lines”, “forward”: false}, “context”:

  { "key": "auto_complete_visible", "operator": "equal", "operand": false }
]

},
{ “keys”: “down”], “command”: “smart_cursor”, “args”: {“cmd”: “move”, “by”: “lines”, “forward”: true}, “context”:

  { "key": "auto_complete_visible", "operator": "equal", "operand": false }
]

},
[/code]

1 Like
#17

Thanks adzenith for the keybindings, will replace the examples from github with these ones.
I’ve just added it to my keybindings !

1 Like
#18

This sounds cool. I need to give this a try.

1 Like
#19

Updated github right now with the new keybindings from adzenith and the fixes for the only issues I’ve found after a day of work:
-After selecting a text from right to left and delete/modify it, caret must be placed to the starting point of the selection (so, technically, always sel.a and not sel.begin()).
-Move down after an edit at the last line of the file move the caret horizontally but, of course, not vertically, which is IMHO not what users are expecting.

1 Like
#20

[quote=“adzenith”]For what it’s worth, I’ve replaced the standard up and down arrows with this. I did this:

[code] { “keys”: “up”], “command”: “smart_cursor”, “args”: {“cmd”: “move”, “by”: “lines”, “forward”: false}, “context”:

  { "key": "auto_complete_visible", "operator": "equal", "operand": false }
]

},
{ “keys”: “down”], “command”: “smart_cursor”, “args”: {“cmd”: “move”, “by”: “lines”, “forward”: true}, “context”:

  { "key": "auto_complete_visible", "operator": "equal", "operand": false }
]

},
[/code][/quote]

@adzenith:
I used these keymaps but found a small issue:
When you go at the end of the auto complete list, press one more down close the auto complete and execute a move down command, not a smart_cursor down command.
If I remove the context, it works as expected.

Did you find an issue with enabling the smart_cursor for auto complete or did you add context ‘in case of’ ?
Thanks for your reply.

1 Like
#21

@adzenith
I know it’s a old question (previous post), but I’m still interested by the answer.

1 Like
#22

Hey, sorry, didn’t notice the question until just now! I seem to recall I added them because I couldn’t use the arrow keys to navigate autocomplete.
I just tried taking the context out, and it causes a different bug:

foo| [autocomplete window, item 0 selected]

press down

|foo [autocomplete window, item 1 selected]

The insertion point moves to the beginning of the line.

1 Like
#23

Thanks for your answer.

I couldn’t reproduce this bug, or I don’t understand it:
You mean that when changing selection in autocomplete window, the cursor move in the file view ?
I couldn’t reproduce it.
Do you have the last version of the repository https://github.com/bizoo/SmartCursor

1 Like
#24

Haha nope! Looks like I still had the second commit or so. I think I’d checked out the code using git so Package Manager stopped updating it. Whoops! Works now. :smile:

1 Like
#25

Oh wait, hold up, it’s doing it again.
Open a new buffer, set it to Python (so we get autocomplete), and type:

foo foobar f
now press down. For me, it snaps to the beginning of the line.

1 Like
#26

Yes you’re right, there’s something that goes wrong when autocomplete is triggered.
Thanks for your feedback, I’ll take a look on this issue later…

If only Jon could implement this feature in core ST3 :wink:

1 Like