I may be able to reduce when all the colors get cleared, but I will still keep the on demand load. I will play with this sometime soon.
ColorHelper 2.0.0
I restarted multiple times and also ran âSatisfy dependenciesâ again. Here are the information from Support Info
- ST ver.: 3118
- Platform: osx
- Arch: x64
- Plugin ver.: 2.0.0
- Install via PC: True
- mdpopups ver.: 1.7.0
- markdown ver.: 2.6.4
- pygments ver.: 2.1a0
- jinja2 ver.: 2.8
Your mdpopups is too old. Delete it from your package folder, rerun satisfy dependencies, and restart. Hopefully that will help.
You could add an vertical_offset
option, so it could be slightly adjusted per user/platform basis?
There already is an option if you read ahead a little more. Are you requesting it to also be per user/platform?
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?
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?
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.
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
andgraphic_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.
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?
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.
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"]
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 :).
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.
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
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.
mdpopups 1.7.6 is out which should prevent crazy padding and margins. So run Satisfy Dependencies to pull the latest.