Sublime Forum

ColorHelper 2.0.0

#11

Your mdpopups is too old. Delete it from your package folder, rerun satisfy dependencies, and restart. Hopefully that will help.

1 Like

#12

You could add an vertical_offset option, so it could be slightly adjusted per user/platform basis?

0 Likes

#13

There already is an option if you read ahead a little more. Are you requesting it to also be per user/platform?

0 Likes

#14

Prrr, i missed that :smiley:

You can’t just offset the position instead of resizing?

0 Likes

#15

I can’t tell from your video as it is a bit low res. Is there a border around your preview? You may want to update your mdpopups via Satisfy Dependencies. There shouldn’t be any padding on the image.

Anyways, Currently you can resize it either bigger or smaller. I don’t have a vertical offset. Technically I could inject CSS to some padding on top of the image. Is this really needed? Are you just unhappy with the size of the images and want to have a smaller one you can try and center?

0 Likes

#16

Now I got the change to play with it. The problem was that I still had an unpacked version of ColorHelper in the package folder, I think.

Pretty amazing and great to see what can be done with phantoms. Couple of thoughts

  • I guess on_hover doesn’t work for phantoms, right? Otherwise, the tooltip could appear on hover. Not a big difference though.
  • There seems to be two margin lines around the inline color squares. One is black and one is grey. With small font sizes, they take up a substantial portion of the inline preview. Is it possible to reduce this to one line?

  • This is a great illustration of phantoms. The problems you describe in response to @315234 also highlight some of the limitations, I guess. Maybe there is a set of things that could be improved in core ST? How are some of these issues handled in Atom’s Block Decorations?
0 Likes

#17

Probably

I don’t know. I haven’t tried. I’ve thought about switching to hovers, but I it wasn’t on my list for this release, and I haven’t decided yet if that is the direction I’m going. Maybe.

It’s possible. I do it this way to avoid having to detect the background of the place of insertion. With two borders, the images standout on any background. If I reduce to one, I have to make sure it stands out against the background it appears on. I could detect the color of the background where I am inserting the color and then calculate a border that stands out, but I chose this instead. It is possible in the future I may change this. But for the first release, this is what I did.

Maybe. There are some real issues like the fact that I can’t calculate actual font or line height (at least not in a way that translate reliably to px on all machines). Some things might be the approach I took. I can possibly reduce having to wipe all the colors when editing, but there are some situations I need to wipe all: font_size changes, syntax_change, change of ColorHelping settings, etc.

Parsing the whole file instead of on demand on scroll is a personal choice. I feel on demand is better FWIW. Could I scan ahead and parse the whole file in chunks? Sure, I could start chunking the whole file and allow file modifications to stop me and update visible colors and then return to chunking the file, but this was easier. Could I update colors on every edit, sure, but you would get some laggy typing. I’d rather not be aggressive on this event. And I might miss where to insert if I don’t block. It’s just the nature of the event.

I don’t know. Any maybe, like in Sublime, they aren’t always handled well. There may be nothing wrong with how Sublime implements phantoms vs Atom’s Block Decorations, it is more how we as plugin decorates try to abuse it.

0 Likes

#18

@iamntz, @greg_hoch, @315234

I’ve listened and released a new version 2.0.1 to address some of your concerns:

  • Less clearing of inline images (incremental updates)
  • Per os/host setting for inline_preview_offset and graphic_size. See docs for the setting in question.
  • Single border around preview that contrasts with the the theme background.

Hopefully that will improve things. If you find any bugs, please let me know.

2 Likes

#19

Awesome, thanks! It works fantastically now.

0 Likes

#20

Excellent update! I have one request about the color_scanning option. If I want to add one scope but leave the default scopes in tact, I have to copy the entire color_scanning option to the user preference file. I am also going to miss any updates to the default scopes. Why not have two options for color_scanning_default and color_scanning_user (the second one is just [] by default) so that I can add my own scopes to color_scanning_user and leave the default scopes intact?

2 Likes

#21

This is a good point. It is actually on my list, but I haven’t had a chance yet. I didn’t really know how many people were adding custom vs using only the defaults. I will make a point at doing this soon. It should be an easy quick enhancement.

0 Likes

#22

And user defined color names might also be nice… Not high priority I would say considering that I am not sure how many users would actually use this. But the idea is that some languages have their own set of named colors and the user could add them manually. For example, I am working in R and R has a lot of named colors. It would work like this:

"colors_sets": {
     "R": {
          "aquamarine3": "#....",
          "seagreen4": "#....",
          ...
     }

}

Now I have a named set of colors, which I could add to allowed_colors as part of the color_scanning option like this "allowed_colors": ["R", "hex"]

0 Likes

#23

Didn’t think about this. I will have to see how difficult this is. Please create an issue over on the GitHub repo as I will forget about this.

This one isn’t exactly trivial. Maybe this will force me to clean up the code more :).

0 Likes

#24

Looks like a broke ColorHelper on the beta branch…whoops…

Made a new release 2.0.2 which should restore functionality on the beta branch. Please report if you are on the beta branch of Sublime and ColorHelper is broken after the update.

0 Likes

#25

I am using Material Theme Dark.

  • ST ver.: 3118
  • Platform: windows
  • Arch: x64
  • Plugin ver.: 2.0.2
  • Install via PC: True
  • mdpopups ver.: 1.7.5
  • markdown ver.: 2.6.6
  • pygments ver.: 2.1a0
  • jinja2 ver.: 2.8
0 Likes

#26

This is probably because the material theme adds a ton of padding (16px to be exact) to the HTML element. That is absurd. I will update mdpopups to clear padding and margins from the HTML element by default.

0 Likes

#27

mdpopups 1.7.6 is out which should prevent crazy padding and margins. So run Satisfy Dependencies to pull the latest.

0 Likes

#28

Thank you. It’s fixed now.

0 Likes

#29

This is freakin awesome! Thank’s a lot. The Plugin is similar to Pygments in Atom and something like that was really missing for Sublime. Do you think you can also add the functionality to show colors in Sass/SCSS Variables once they are used throughout the project? Example: Definition $white: #fff is shown, but Rule color: $white; is not.

Keep up the great work.

Regards from Germany,
Leo

2 Likes

#30

Hello @facelessuser and thank you very much for releasing this plugin that I use and love since version 1. Very good work!

I totally second @legosublime request, it is definitely a killer feature (if it is possible to add it)!

Thank you again for sharing your clever work.

1 Like