Sublime Forum

Bug: Unindent misbehaviors

#1

There are a couple problems with the unindent (shift+tab) shortcut I have found.

The first problem happens when trying to unindent a single indented line. If you have the cursor at the beginning of the line, or you highlight only that line (neither of the newlines to either side), nothing happens when you press the unindent shortcut. If you highlight at least one character of the line above or below, then both lines will unindent, as expected. Expected behaviour: the single line should unindent if it is the only line selected.

The second problem is odd and happens only when translateTabsToSpaces is set to true. If you select multiple indented lines, where the selection begins at and is inclusive of column 1, and the line immediately above the selection is empty, pressing the unindent shortcut will unindent the selected block by tabSize x 1 spaces as expected, but the first line of the selection will be unindented by tabSize x 2. Here is a simple illustration:

[code]// tabSize 2, translateTabsToSpaces true, the line below is empty

hello
world[/code]

If you highlight the “hello world” lines, being sure to begin the selection at column 1 of the “hello” line (select the entire line), then press the unindent shortcut, the result is this:

[code]// tabSize 2, translateTabsToSpaces true, the line below is empty

hello
world[/code]
If you begin the selection at column 2, or any higher column, or the line above the selection isn’t empty, then all lines of the block will be unindented by tabSize x 1 as expected.

0 Likes

#2

The first is intentional: tab won’t indent in that circumstance, so shit+tab won’t unident. The key binding that gives this behaviour is:

	<binding key="shift+tab" command="unindent">
		<context name="newlineInSelection" value="true"/>
	</binding>

The second is a bug, I’ll fix it for the next beta.

0 Likes

#3

What+tab??? :astonished: Hehehe. I see what you did there. :wink:

[quote=“jps”]The key binding that gives this behaviour is:

<binding key="shift+tab" command="unindent"> <context name="newlineInSelection" value="true"/> </binding>[/quote]

Cool, I added “” to my user key bindings and now it works as I expect it to. I noticed that some other editors also behave like your intentional behaviour though. Can you enlighten me as to why this is? I hope I’m not shooting myself in the foot by making this change :smile:

Excellent, thanks! It’s actually been bugging me for a few weeks, but I finally broke down today and isolated how to reproduce it.

0 Likes

#4

It’s just for consistency: My preference is that for any situation where shift+tab unindents, then tab should indent. If shift+tab did unindent when no newlines were selected, then it’d be easy to accidentally overwrite the selection with a tab, when you’re expecting the line to be indented.

0 Likes

#5

Ah, I see. I added the following to my key bindings then:

<binding key="tab" command="indent"> <context name="option" value="translateTabsToSpaces"/> </binding>
When translateTabsToSpaces is true, it’s a pretty safe bet that I’m never going to use tabs for whitespace, so this way, using tab can never overwrite by accident. Works quite well, I’d say! :smile:

0 Likes

#6

This is fixed in the Feb 1st beta, thanks! :smile:

0 Likes