Sublime Forum

Nightly Build 2204

#6

[quote=“jps”]

The only way I’ve seen to replicate that is by dragging the tab to the very top of the screen, and releasing the mouse button there. That would create the titlebar off screen, however this no longer happens as of 2199 (or 2204 for multi monitor systems).[/quote]

I use the nightly ones and I have this issue all the time. I just drop and release somewhere in the middle. It doesn’t happen all the time, but frequent enough to cause a lot of frustration.

0 Likes

#7

Do you have multiple monitors?

0 Likes

#8

Indeed it is, thanks! :smile:

0 Likes

#9

[quote=“jps”]

Do you have multiple monitors?[/quote]

Yes. And this issue occurs when dragging tab to a different monitor.

0 Likes

#10

Another regression in 2205:

  1. Open up the python console.
  2. Drag the view/console separator up to half the height of the Sublime Text 2 window.
  3. Set the cursor on the last visible line in the view, not necessarily the last line in the buffer, just the last visible line so that the autocompletion box will extend out over the python console.
  4. Hit ctrl+space. The autocompletion window closes immediately.
0 Likes

#11

Install and relaunch still not working on mac after update (2205). And old versions are in the Trash, undeletable.

0 Likes

#12

Thanks for the word wrap home and end button enhancement. :smiley:

But how above the full disk empty out file bug (viewtopic.php?f=2&t=7645&start=0) ?

And why don’t add an alert popup to confirm before reloading an external edited file?

0 Likes

#13

One more thing:

Can the auto-completion list show the words that are within the current file first then the snippet later? That is, the current file’s words have the most top priority. It seems more convenient.

0 Likes

#14

Just found a odd behaviour,
when the current line contains only a tab char, after pressed enter key to make a new line, pressing up key to go back to the previous line (which originally contains a tab char), the tab char will be gone.
This is an very odd and annoying behaviour.

0 Likes

#15

quarnster: thanks for the report, will fix for the next build.

facelessuser: I’ve still not been able to repro this. I’ll put in a change for the next build that may have some effect, but it is unlikely to change anything.

handycam: I’m aware of the issue, but don’t know what’s causing it, and I’m not planning to investigate any further before 2.0.

singw: The trim_automatic_white_space setting controls this.

0 Likes

#16

2206 is out now, with a fix for the auto complete issue.

Python initialisation has also changed, to try and better insulate the application from any env vars meant for the system version of Python.

0 Likes

#17

Could make the “Goto”->“Jump to Matching Bracket” function also work on the bracket pair inside string (ideally, in all situation) ?

0 Likes

#18

singw: feature requests are better placed on UserEcho or in the appropriate forum

0 Likes

#19

I’m wondering if the key shortcuts that are currently overlapping with Mission Control on OSX Lion will be changed from their current default ?

These are some examples of keys not working out of the box:

{ "keys": "ctrl+shift+up"], "command": "select_lines", "args": {"forward": false} },
{ "keys": "ctrl+shift+down"], "command": "select_lines", "args": {"forward": true} },

{ "keys": "ctrl+left"], "command": "move", "args": {"by": "subwords", "forward": false} },
{ "keys": "ctrl+right"], "command": "move", "args": {"by": "subword_ends", "forward": true} },

If not, at least the documentation should be updated to let people know that they are not working in Lion (I know that I’ve spent some time looking for this).

Just remember an issue that it’s still here: column selection will not automatically scroll the view when it reaches top or bottom (like the regular selection).

Thanks.

0 Likes

#20

Moving by subwords on OS X is also possible via ctrl+alt+left/right, which isn’t a default mission control key binding.

select_lines suffers from a few issues, and I’d like to revisit it, but it can wait until after 2.0

0 Likes

#21

If there is anything I can do to help, I am willing. I was just testing 2206, and this issue is very reproducible on my system. I literally can drop a tab on any monitor (I have three) anywhere, and it will be rendered off screen. It is bad enough that I try to avoid doing this at all.

I know this is not related to this computer or installation of ST2 because I had this issue for months on my old computer, and work upgraded my computer a couple of weeks ago, and with a fresh install of ST2 on a brand new computer I have this issue still.

0 Likes

#22

This still happens to me too on my work machine, Win7, two monitors, build 2206. In case it matters, my primary screen is 1920x1080, and my second screen is 1440x900.

If I drag a tab off of the ST2 window and on to the desktop, the new window seems to always be created at the same X position where I dropped it, but at a Y position well below the screen.

With that new window as the active one, I press Alt+Space to bring up its system menu, then M to select Move, then I hold the Up arrow until the window is brought up. The top of the new window is a ways below the bottom of the screen. I have to hold down the Up arrow for a second or two before it appears.

I just put together a little AutoHotKey script that shows the position of the active window. When I drop the tab at the very top of either screen, the Y position of the new window will be about 1265. If I drop it lower on the screen, the offset seems to be about the same. I just dropped it at the very bottom of my screen, giving a Y coordinate of 2346, which minus 1080 is 1266.

Dropping it at the bottom of my second monitor gives a Y position of 2165, minus 900 is 1265.

I don’t know what that 1265 number comes from but hopefully this helps you find it.

Todd

0 Likes

#23

This should illustrate how ridiculously off ST2 calculates the position for the dragged and drop tab on my screen.

Screen Size: 1680 X 1050
Mouse Position at Drop: Left: 295 Top: 147
Window Created at: Left: 227 Top: 32767

As stated above the X position seems to be calculated just fine, but the Y position is way, way, way off.

0 Likes

#24

Love the new create_window_at_startup: false option, but unfortunately it will still create an empty window if I try to directly open a project file that is already open. :frowning:

0 Likes

#25

[quote=“facelessuser”]This should illustrate how ridiculously off ST2 calculates the position for the dragged and drop tab on my screen.

Screen Size: 1680 X 1050
Mouse Position at Drop: Left: 295 Top: 147
Window Created at: Left: 227 Top: 32767

As stated above the X position seems to be calculated just fine, but the Y position is way, way, way off.[/quote]

I don’t think it’s “off”. The 32767 definitely tends to point to a bug…

0 Likes