Sublime Forum

Dev Build 3119

#46

Thanks for the report

0 Likes

#47

@wbond On a similar note, the same thing happens when using plist files like I’m doing it here:

If you have *.tmPreferences files with windows line endings in that setup, it completely messes things up.

As @FichteFoll says there:

If there was better tmPreferences integration for variables such as these, things like SublimeText/AsciiDoc@c8ea594 could also become feasable.

Especially the support for piped lists would be nice.

0 Likes

#48

On Ubuntu 16.04, when using the Goto Anything functionality, the popup window’s entry textbox shows a black background coloured dot when you enter a space. As soon as you enter other text it is changed to the more typical transparent space. Same applies for tab, but then with a dash instead of a center dot.

Not sure if this was an intended change.

0 Likes

#49

Also, saw someone mention 3120; on Ubuntu 16.04 I have with 3119 installed, no popup for downloading the new version.

0 Likes

#50

Basically it seems to honor the "draw_white_space" preference. Also confirmed on Windows. Affects all quick panels. Not sure if/when behavior changed. IMO I like it the way it is now :slight_smile:

0 Likes

#51

I’m using the default, which is set to selection, so that would make it weird for mine to show this behaviour at least.

0 Likes

#52

I am talking about scoping character literals. In languages like C or Haskell expressions like 'a', 'b', '\0' are not strings, but rather a standalone syntaxic construct. In the doc it is not clearly described how to scope these.

By looking at an old syntax file (Pacakges/Haskell/Haskell.sublime-syntax) I see that string.quoted.single was used for character constants.

Should we stick with that? It seems to me that although the information is not lost (color schemes could target string.quoted.single.c and match only character literals), scoping a character literal as a ‘string’ is kinda wrong. Also, in my opinion, targeting language-specific scopes is wrong and is against the point of having a scope-naming standard.

0 Likes

#53

@wbond: currently the minimal scope coverage recommendations don’t include markup., is that intended?

0 Likes

#54

Not really, mostly that is the case that I’ve done minimal work with syntaxes that use markup.. I’ll put it on the list to get some recommendations in there.

1 Like

#55

I’d be interested in the markup.raw scope for inline highlighting (with background color) besides the obvious italics and bold scopes.

0 Likes

#56

Oh this is awesome!

0 Likes

#57

I you want some stats on what scopes are currently used check my tmtheme editor’s stats page
https://tmtheme-editor.herokuapp.com/#!/stats

1 Like

#58

@wbond I know we were talking earlier today about minihtml capabilities and inline background colors, but I have found a bug in inline background colors:

Here we have two examples. The first is just a line were we have two Tests and we want to highlight the 2nd. The next example has Test 3 times on separate lines, but we are trying to highlight the 2nd one.

sublime.active_window().active_view().show_popup('<p>Test <span style="background-color: #ff0000">Test</span></p><div>Test<br><span style="background-color: #ff0000">Test</span><br>Test</div>')

This is what we get.

Notice the space before Test is highlighted in the first which is incorrect. Notice the second example grabs the 3rd even though we specified the second.

1 Like

#59

I’ve also noticed this bug. I think it’s converting line breaks into a space for inline elements.

Consider this HTML:

<a href="#" class="button">Ok</a>&nbsp;<a href="#" class="button">Cancel</a>

with this css

.button {
  background-color: var(--greenish);
  color: var(--background);
  text-decoration: none;
  border-radius: 3px;
}

Renders like this:

Which is fine. but if I put the second link on a new line like this:

<a href="#" class="button">Ok</a>&nbsp;
<a href="#" class="button">Cancel</a>

Then it renders with an extra space which is wrong:

1 Like

#60

@wbond, I’ve figured out my original issue I saw in popups with images. I guess the line height in minihtml fluctuates a little from the calculated line heights gathered from view.line_height(). Bumping my line height in minihtml a little fixed the issue.

With that said, a very reproducible bug exists on Windows at least with 4K monitors as I’ve seen multiple people now with hires screen on Windows (and only Windows) having this issue. On builds 3119 - 3120 images are getting squished horizontally.

0 Likes

#61

I’ve updated the Default and Color Scheme - Default packages code, please check your email. Including:

  • updated send2trash files with source from Github
  • changed indentation to tabs for most files (to bring down file sizes)
  • changed link targets from http to https where applicable
  • removed redundant code from tmPreferences, tmTheme and tmLanguage files
  • ordered commands in sublime-commands file by appearance in main menu to complete with all missing entries from there
0 Likes

#62

At this day and age, we really shouldn’t have a space vs. tabs discussion with this argument. Especially when spaces can be used for visual indentation (which is quite popular with Python code) and tabs are discouraged

1 Like

#63

@wbond: I ran into some rendering issues with the popups. Here are two examples.

Example 1

In this case, only the FALSE and TRUE should have a red background. Not everything after the FALSE (same happens when I use span and not code tags).

content = """
<body id="my-plugin-feature">
   <style>
      code {
         background-color: red;
         border-radius: 3px;}
   </style>
   depending on whether <code>character.only</code> is <code>FALSE</code> (default) or <code>TRUE</code>).
</body>"""
view.show_popup(content)

Example 2

Maybe the same problem with the start and beginning of the background color…

content = """
	<body id="my-plugin-feature">
		<style>
			code {
				background-color: red;
				border-radius: 3px;
			}
		</style>
		<p>The default value of <code>NULL</code> corresponds to all libraries currently known to <code><a>.libPaths</a>()</code>. Non-existent library trees are silently ignored.</p>
	</body>"""
view.show_popup(content)

Edit: ST 3120, Mac OS X 10.11.6

0 Likes

#64

Thank you for the minihtml bug reports!

0 Likes

#65

I also ran over an at least unexpected behavior regarding the sizes of phantoms to show images: If the image is defined via the file path, the phantom size does not fit the image size. On the other hand if the image is directly encoded, the phantom has the same size of the image.

Example:
Generate phantom content with the absolute image path:

image_path = ...
content = '<img src="file://{0}" />'.format(image_path)

Generate phantom content with base64 encoded images:

image_path = ...
with open(image_path, "rb") as f:
    image_raw_data = f.read()
img_data = base64.b64encode(image_raw_data).decode()
content = '<img src="data:image/png;base64,{0}" />'.format(img_data)

Absolute path:

Base64 encoded images:

(I can also read the image dimensions from the image and set the width and height attributes of the img tag. Then it results in the same phantom size as Base64.)

I am using Windows with build 3120.

0 Likes