[BUG] Tab indenting problem in HTML after tab completion

[Esseb]

Tab indenting in HTML is really broken after using tab completion. It seems like a really obvious bug, but I can't find an existing thread about this problem. I don't actually know if the problem is unique to HTML, but it's the only language I could think of that Sublime has this kind of tab completion for.

It's probably easier to just show an animation than to explain it:


The problem isn't isolated to the style element, it's just much more noticeable there. You get a similar problem after tab completing div and p also. I assume this is because style has 4 fields, while p and div only have 2.

This is with a clean install of beta 20100501, but I have the same problem with version 1.3 on another machine. No plug-ins installed.

[edanm]

This is something that has always been annoying to me as well.

What happens is, once you perform an auto-completion, SublimeText allows you to "tab" through to the other fields.
This is actually very useful, but there is one problem:
If you decide you *don't* want to tab through the fields (cause you moved your cursor away, for example), the fields are still there. The next time you hit "tab", it will go back to the fields you left out.

What you can do right now
First of all, you should try and actually use the tab to go through the fields. This is oftentimes convenient.

Secondly, notice that down in the statusbar (at the bottom of the screen), it says "field 1 of 4". Whenever you see that and don't want to use tab to go through the fields, just hit the "Escape" key, which will cancel the behavior.


Long term solution
I think the way Sublime should behave is like most other editors in this case. I'm pretty sure what they do is that, as soon as you move your cursor with the arrow keys, it cancels the fields. It's also possible that they only cancel the extra fields when you move the arrow keys away from the line itself, not just any movement.

[edanm]

I just messed around with Sublime a bit and came up with an even easier quick fix for you, Esseb.

Right now, Sublime does cancel the fields if you leave the "area" of the inserted snippet. Unfortunately, this doesn't help much because you'll usually be adding things *inside* the snippet area the next time you try and hit "tab", and this will have very weird behavior.

So I have a quick fix to make Sublime behave the way I talked about, which is that any time you use the up or down arrow keys, all the fields will be cancelled.
Just add the following lines to your User Key Bindings file, and that will do the trick:

Code: Select all

   <binding key="down" command="sequence 'clearFields' 'move lines 1'">
      <context name="hasPrevField" value="true"/>
   </binding>
   <binding key="up" command="sequence 'clearFields' 'move lines -1'">
      <context name="hasPrevField" value="true"/>
   </binding>
   <binding key="down" command="sequence 'clearFields' 'move lines 1'">
      <context name="hasNextField" value="true"/>
   </binding>
   <binding key="up" command="sequence 'clearFields' 'move lines -1'">
      <context name="hasNextField" value="true"/>
   </binding>


I think Sublime should do this by default.

[Esseb]

Thanks, edanm, that works great!

I did identify one problem, however. I like to use ctrl+shift+enter every now and then, but if you do this sequence of commands:

• style
• TAB
• TAB
• TAB
• ENTER
• CTRL+SHIFT+ENTER

You get the original problem when you now press tab.

I adapted your fix for ctrl+shift+enter:

Code: Select all

<binding key="ctrl+shift+enter" command="sequence 'clearFields' 'runMacroFileSilently \'Packages/Default/Add Line Before.sublime-macro\''">
   <context name="hasPrevField" value="true"/>
</binding>
<binding key="ctrl+shift+enter" command="sequence 'clearFields' 'runMacroFileSilently \'Packages/Default/Add Line Before.sublime-macro\''">
   <context name="hasNextField" value="true"/>
</binding>


There may be other shortcuts that have to be modified also, but I can't think of any at the moment.

[edanm]

Hadn't thought of that. Nice catch!
Hopefully, this issue will be resolved in some more fundamental way, so that these kinds of bindings will be unnecessary (since what's the chance we'll catch every edge case?).

By the way, has there been any thought of adding some kind of visible mark for the tab fields? That will at least make this feature more obvious.