Sublime Forum

[SOLUTION] Do not remove carets when scrolling beyond file boundaries

#1

With multiple lines selected, scrolling beyond the top of the file removes top lines of the selection, and scrolling beyond the bottom of the file removes bottom lines of the selection. The number of selected lines should not change when scrolling beyond the top or bottom of the file.

0 Likes

#2

Can you record a video of this? I can not imagine how that would look like.

0 Likes

#3

Er… what? To what purpose? I’m intrigued, do you have a user story for this?

0 Likes

#4

I suppose I could video this behavior, but all you need to do is:

  1. Start with a number of lines
  2. Ctrl-Alt-Down or -Up a few lines to create a multi-line selection
  3. Arrow up or down until the multi-line selection goes beyond the first or last line
  4. Arrow in the opposite direction. The number of selected lines shrinks.

The purpose for this suggestion is to not lose the number of lines selected.

When I select a certain number of lines and scroll around, I want the number of lines to remain constant unless I purposely change that number, but ST3 has shortcomings in doing this.

Do I have a “user story,” such as would be added in Jira?

0 Likes

#5

Ah, you mean you have multiple selections (or carets rather) and moving those toward the top or bottom causes selections (carets) to disappear.

Well, I suspect this would be hard-ish to implement just because of how fundamental this selection joining is performed. If you have 4 selections (or carets) in one line for example, what would you expect to happen when you press the end key? Exactly, the selections are joined into one.
The same happens when you ctrl+end or try to go beyond the file boundaries with up or down arrow keys.

In that sense, you feature request becomes more of something like:

Allow selecting or traversing lines beyond the file boundaries and implicitly create emtpy lines.

Well, I suppose you could do that with a plugin and an on_text_command hook.

0 Likes

#6

The above example is not what I’m referring to. I’m referring to multiple lines with only one caret per line. Whether there is one or many carets per line, the behavior should be identical when traversing lines.

No to creating empty lines, just don’t scroll beyond a file boundary when a caret is at a file boundary.

0 Likes

#7

Then I (still) don’t understand you.

0 Likes

#8

I think what @ParticleMan means is kind of that do not allow users to press if there is a cursor hits EOF.

0 Likes

#9

Partially, yes. I mean this: Do nothing if a cursor/caret is at EOF and the user hits down, and do nothing if a cursor/caret is at BOF and the user hits up. Currently, a caret is removed at each hit, and continuing to hit the cursor will remove all carets until only one is left. This behavior is undesirable.

0 Likes

#10

Maybe this, in User/DontRemoveCursorsWhenMovingByLinesListener.py (Main menubar - Tools - New Plugin ; Paste the content of the following and press Save)

class DontRemoveCursorsWhenMovingByLinesListener(sublime_plugin.EventListener):
	def on_text_command(self, view, command_name, args):
		if command_name == 'move' and 'by' in args and 'forward' in args and args['by'] == 'lines':
			if not args['forward']:
				for region in view.sel():
					row, col = view.rowcol(region.begin())
					view.show(region, False)
					if row == 0:
						return ('noop','')
			else:
				row_e, col_e = view.rowcol(view.size())
				for region in reversed(view.sel()):
					row_s, col_s = view.rowcol(region.end())
					view.show(region, False)
					if row_s == row_e:
						return ('noop','')
0 Likes

#11

That seems to do the trick, @tito. Thanks!

Now, how to get this patched into ST3?

Does anyone else find this helpful?

0 Likes

#12

There I edited the script to also solve this Scroll with the leading caret of a multi-caret, multi-line selection but is has an error by one, idk why.

I would prefer to keep the current behaviour of ST, because is easier to solve your problem than to undo it. Its also consistent with other things, as pressing home when multiple cursors are on the same line.

0 Likes

#13

Why do you feel like this scenario of selection merging where you lose carets by scrolling down is more important than, say, holding the right arrow key, or by having two tokens on the same line and hitting Home, or…

0 Likes

#14

I wouldn’t say more important, just more of what I experience. My usage includes more vertical movement than horizontal, than having multiple carets per line, etc. I primarily have a single caret per line across multiple sequential lines. Now that you mention it, I would also prefer line wrapping to not occur with multiple carets on multiple lines.

0 Likes

#15

The current behavior is obvious and easily understandable:
-Each cursor has its own life, there’s no difference of behavior working with one or hundred cursors.
-When more than one cursor are on the same position they are merged and it remains only one.

I wonder in which case you have to navigate your source with more than one cursor ?

0 Likes

#16

There are many bizzo that you didn’t found one use case does not mean that there aren’t. To be honest, even when I prefer the current ST behaviour, I understand his wish. Just imagine you want to see what is at bottom without losing the selection. Also keep in mind that when scrolling down or bottom, all cursors but the last one are hidden, so his wish even makes more sense to me.

0 Likes

#17

Well I don’t say there’s no use cases and the proposition makes some sense but I wonder if the issue here is not that the user didn’t use the correct command for what he want to do.

If you want to see something out of the current view you use the scroll view up/down (CTRL+UP/DOWN) that keep the cursors in place, navigating with multi-cursors is somewhat hazardous.

0 Likes

#18

bizoo, my objective is as tito stated:

  1. Scrolling to the top/bottom without losing the selection
  2. Seeing all cursors when scrolling instead of all but the last cursor being hidden

The current behavior may be obvious and understandable, it’s just not (always) desirable. Ctrl-Up and Ctrl-Down are almost workarounds but I want the selection to scroll.

My main use case for this is editing SQL, manipulating select clauses and where clauses. The plugins Alignment and VAlign help tremendously with formatting, and now tito’s plugin for cursors, even with its bug.

0 Likes

#19

I still don’t get when you need to keep multi-cursors and navigate with them, except in some very corner case where your file is composed by some kinds of blocks with always the same length.
Your SELECT and WHERE clauses have probably one to dozen of lines, so each editing must first expand or contract the number of cursors, no ?

However your second proposition to keep all the carets in the view is a good one, better than the current behavior and probably haven’t any side effect.
I try the plugin from tito (thanks) and found it good, I only kept the “stay carets in view” part and I’m happy with it.
IMHO this must be the in the core ST3 release.

0 Likes

#20

Regardless of whether my example use case is a corner, or edge, case is besides the point.

The point, or the principle, is this: I expect my action to remain–to not be undone–unless I act contrariwise. Is it not undesirable, and potentially annoying or worse, when something you have done willfully is undone unwillingly?

In this case, I expect every cursor to remain selected unless I deliberately change that.

0 Likes