Sublime Forum

Dev Build 2170

#13

Can I ask how you went about discovering this? Is it just in the .tmTheme file?

0 Likes

#14

[quote=“nick.”]

Can I ask how you went about discovering this? Is it just in the .tmTheme file?[/quote]

Elementary Watson; I used the power of deduction. :smile:

I simply opened a couple of theme files and looked for when the match_selection region changed. In the Amy.tmTheme file I noticed the color to be a purplish color that did not match the default text, so I assumed it had to be theme controlled. I used simple reason and ruled out any code defined scopes and realized it had to be one of the basic them settings in the beginning and noticed the caret was also purple. After changing the caret color in my default theme file, I noticed that the match_selection/find results changed as well. By reason and deduction, I have determined the caret to be the controlling factor.

0 Likes

#15

Easier than I imagined! There was a post (or website) around that I read in regards to plugin development and it recommended browsing through the source code to see what commands are available. Since this was a new setting, I tried a search for ‘MatchSelectionSetting’ via Find in Files, with C:\ as the directory. I’ve tried similar searches in the past, and the results are only from the Find buffer itself (cached previous searches). Are such commands/settings normally public packages (ie, Python plugins) or are they part of sublime_text.exe?

0 Likes

#16

Search box is fubared for me as well, WinXP64 on 64-bit standalone with vintage enabled.

It appears to be connected to Vintage mode, as the search window sill responds to Vintage bindings. Keys that should change to input mode (a, i) will sometimes go through into the box, but then it hops back into command mode.

0 Likes

#17

It’s awesome to see the match_selection feature get added! (I’ve found the WordHighlight package to be indespensible). Two requests fall out from this to make me move off WordHighlight though :smile:

-Don’t require the selection to be non-empty (e.g. highlight “word-like” patterns that are under the point). Having to actually have a non-empty selection (that is on an exact word boundary no less) makes this a lot less “smooth/elegant” than WordHighlight.

-Allow the resulting highlights to be themed a bit. e.g. I have WordHighlight make the highlights have no outline, with a solid faint background. This makes the highlighting non-obtrusive for readability, but visible when you want to focus on them. The outlines make things look a bit more cluttered…

The combination of the above two features makes it so you just need to point at a variable and you see all the occurrences of it on screen right away, making manual search waaaaaaay less necessary, and skimming code a lot more fluid.

In any case - keep up the awesome work!

0 Likes

#18

[quote=“jburnett”]-Don’t require the selection to be non-empty (e.g. highlight “word-like” patterns that are under the point). Having to actually have a non-empty selection (that is on an exact word boundary no less) makes this a lot less “smooth/elegant” than WordHighlight.

-Allow the resulting highlights to be themed a bit. e.g. I have WordHighlight make the highlights have no outline, with a solid faint background. This makes the highlighting non-obtrusive for readability, but visible when you want to focus on them. The outlines make things look a bit more cluttered…[/quote]

I agree with the 2nd point. The ability to better theme the selection would be nice.

I think the 1st point is good too as long as the option to disable/enable it is there as well; this way it could suite both camps. I kind of like the requirement of physically selecting the word because it only clutters my view when I ask it to, but I do understand the opposing view as well.

0 Likes

#19

With build 2170 I’ve noticed this white box on the line selection. How would I go about removing it?

0 Likes

#20

lineHighlight problem with 217x on Win 7 x64. Doesn`t highlight all line.

http://img254.imageshack.us/img254/2715/capturdeecran2012012909.png

0 Likes

#21

[quote=“oriceon”]lineHighlight problem with 217x on Win 7 x64. Doesn`t highlight all line.

http://img254.imageshack.us/img254/2715/capturdeecran2012012909.png[/quote]

what is the color theme?

0 Likes

#22

Monokai Bright but i changed lineHighlight to became more visible to do this print screen.

0 Likes

#23

I can’t exactly put my finger on it, but the fonts just look weird now (2171, Ubuntu 64 bit). They seem bigger and more “cramped”, like the anti-aliasing has gotten heavier or something. Switching between “gray_antialias” and “subpixel_antialias” didn’t really make a difference, either.

0 Likes

#24

spadgos: Can you compare vs. a regular GTK text editor, such as gedit (using similar color schemes, of course), and verify if the text rendering is different between the two?

0 Likes

#25



Looking at it now, maybe I’m just going crazy…

0 Likes

#26

Sub-pixel anti aliasing isn’t happening on the Sublime Text screenshot. Assuming you’re using the default font options, I’m not quite sure why that would be (it should be enabled out of the box).

0 Likes

#27

I also noticed with subpixel anti-aliasing on Linux, something felt off in 2170, but I haven’t taken the time to screenshot the difference. I felt like I was getting more red and blue “ghosting” on the right and left edges of characters, almost as if the rgb order was wrong for my monitor. Switching to gray antialias improved it, but I still feel like the character rendition is a bit different.

I’ll take some screenshots in 2170 and 2169 and post them shortly.

0 Likes

#28

[quote=“wbond”]

I also noticed with subpixel anti-aliasing on Linux, something felt off in 2170, but I haven’t taken the time to screenshot the difference. I felt like I was getting more red and blue “ghosting” on the right and left edges of characters, almost as if the rgb order was wrong for my monitor. Switching to gray antialias improved it, but I still feel like the character rendition is a bit different.

I’ll take some screenshots in 2170 and 2169 and post them shortly.[/quote]

Sorry to drag this thread up again. I took a couple of screenshots and determined the difference between 2169 and 217x. I found that a font_size of 11 in 2173 is a good amount bigger than 11 in 2169. The effect of this is that some strokes and spaces tend to increase in size by a half pixel or so, giving the text a different feel. I decreased the size in 2173 to 10.5 to get an appearance more like 2169.



0 Likes

#29

I noticed that too actually, when I upgraded to 2170, the font size increased, and I dropped mine to 9.5 initially (instead of 10), but I didn’t like it so I reverted back to 2169 for a bit. Sorry, I figured it was just me :frowning:

Ubuntu 10.4

0 Likes

#30

The font size changes between 2169 are likely accounted for by the removal of a floor operation after converting from points to pixels. I believe the current behavior is now correct, insofar as it matches up with gedit.

If you were using a font size of 11 previously, using 10.5 should give pixel-identical output to 2169.

If you were using a font size of 10, 9.75 should give pixel-identical output to 2169.

0 Likes

#31

Please consider making the word highlight work with just the cursor on the word, rather than requiring the word to be selected. I’ve come to depend on this feature in another editor, and having it in ST2 would seal the deal for me.

Thanks,
Ern

0 Likes

#32

@ern, just press command/control-d to select the current word quickly.

0 Likes