next-hotspot not working on mac

[Ed Barnard]

When I start typing an if() block, I get the outlined rectangle, and I normally type Ctrl+[ to jump to the point after the opening brace of the block. I checked my mapping and this is mapped to next-hotspot. However, the keystroke appears to be ignored.

If I click the mouse so the rectangle goes away, hitting the return key does move forward to the next marked spot. That is, it moves to after the parenthesis as indicated.

v18.0.0.10, Mac OS X Mountain Lion, Project type PHP, language .php (PHP).

[Matthew]

What emulation are you using? You should also be able to use TAB to jump between the hot-spots. Is there perhaps some system-level binding for Ctrl+[ that is gobbling this up? If you active the command line and type what-is (then enter, then try Ctrl+[ at the prompt), do you see a pop-up with a message for the binding?

[Ed Barnard]

Emulation: Mac OS X
what-is (return) (key combination Ctrl+[) generates the message:
Ctrl+[ runs the command next-hotspot

I believe this key combination did work on Slickedit For Mac prior to installing the beta release. This key combination does work for me on Windows Slickedit 2012 (no beta).

Further observations:

1. This only happens inside two parentheses. That is, if I type "if(a(b" (which has expanded to an if block with braces), control-[ does nothing. However, inside just one parenthesis by typing "if(a", control-[ works as expected, i.e., jumps past the curly brace.

2. tabbing to the next hotspot works in each case. This is NOT the same behavior as control-[. Tab moves outside the parenthesis, control-[ moves to the start of the inner {} block.

3. While the outlined rectangle is present, the mouse disappears over that window. Not sure if that's intended. I have 5 floated windows, and the window in question has 5 tabs. The mouse does appear when I move it outside the current window, over other windows, etc. It then disappears when I move it back over the window with the outlined rectangle (so long as that window has focus).

Thanks!

[Matthew]

OK, now I see what is happening. These navigation markers are "stacked" meaning that when you performed the if expansion you got two hotspots, with the last one inside the brace block.
Then you typed something else, a(b) inside the if() parens that resulted in a second, slightly different type of auto-completion (a closing paren insertion), which created another type of marker. Once you press TAB (or manually type the matching closing paren) that second set of hotspots goes away, restoring the original set. So in your example you could have typed TAB (to get past the closing paren of the a(b) set), and seen the original if() completion hotspots restored, where then either TAB or Ctrl+[ would work to get inside the brace block.

Here's the kicker. The marker created by the auto-close paren ( from a(b) ) is not exactly the same animal as the hotspot created by the expansion of the if() block. That's why Ctrl+[ didn't work after typing a(b), it's not considered a hotspot. Granted this is not exactly intuitive as they look the same and (mostly) function the same. We'll have to examine how we build this stack of hotspots to see if we can get both types working together seamlessly.

[Ed Barnard]

Yes that makes sense. For the sake of feedback, what I'm looking for (as you already see) is the ability to fill in the if() clause details and then jump to the enclosed block and continue typing. I can live with a tab or two or three to get there (or return, works the same way on my setup). After typing code in the enclosed {} block, I hit the down-arrow to continue typing after the if() block.