I've seen various editors which can parse CSS or SASS files for rgb color variables and then show the font in the same color
Is there any bundle which is able to do this for textmate?
I'm not entirely sure the bundle API is able to support such a feature. If not, could it be done with a plugin?
A bit more intrusive, but you can select a color and press CMD+SHIFT+C to display a color picker.
Also, I think displaying them in their own color could clash with theme colors and make the string invisible. Unless some border and/or background is added.
Koen
Verstuurd vanaf mijn iPhone
Op 24 mei 2016 om 05:47 heeft Carpii UK carpii.uk@gmail.com het volgende geschreven:
I've seen various editors which can parse CSS or SASS files for rgb color variables and then show the font in the same color
Is there any bundle which is able to do this for textmate?
I'm not entirely sure the bundle API is able to support such a feature. If not, could it be done with a plugin?
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
A bit more intrusive, but you can select a color and press CMD+SHIFT+C to display a color picker.
Thanks, I didn't know about this. It's a little cumbersome as you say, but it's better than nothing :-)
Also, I think displaying them in their own color could clash with theme
colors and make the string invisible. Unless some border and/or background is added.
I think you're right. I cant remember what editor I saw which uses this... maybe Atom or Sublime, and also vim with a plugin.
These plugins are also able to parse SASS includes, so they could interpret variables like $main_border_color I suspect this degree of parsing would never be possible in TM though, without quite a lot of core code changes
Koen
Verstuurd vanaf mijn iPhone
Op 24 mei 2016 om 05:47 heeft Carpii UK carpii.uk@gmail.com het
volgende geschreven:
I've seen various editors which can parse CSS or SASS files for rgb
color variables and then show the font in the same color
Is there any bundle which is able to do this for textmate?
I'm not entirely sure the bundle API is able to support such a feature. If not, could it be done with a plugin?
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
I think you're right. I cant remember what editor I saw which uses this... maybe Atom or Sublime, and also vim with a plugin. Probably you're talking about this plugin: https://github.com/abe33/atom-pigments AFAIK, there's no way to implement this without modifying TextMate source code.
On 24.05.2016, at 14:00 , Igor K me@igorkozlov.me wrote:
I think you're right. I cant remember what editor I saw which uses this... maybe Atom or Sublime, and also vim with a plugin.
Probably you're talking about this plugin: https://github.com/abe33/atom-pigments AFAIK, there's no way to implement this without modifying TextMate source code.
IntelliJ Idea displays a tiny coloured square in the gutter next to any line (not just CSS) that contains a color-value:
I think TextMate bundles could be made much more powerful by allowing to modify the gutter a bit.
API: * paint into a rectangle in the gutter (per html?) * act on click and hover there (including screen coordinates maybe)
On 24 May 2016, at 14:07, Fabian Zeindl wrote:
I think TextMate bundles could be made much more powerful by allowing to modify the gutter a bit.
There actually is API to show images in the gutter with associated tool tips.
So technically this could be done by having a bundle command generate the image and set this in the gutter, e.g. on save (this is similar to how the SCM diff markers work).
I’ve been meaning to add a “did load” hook so bundles can update the gutter once a file is opened.
On 24.05.2016, at 14:18 , Allan Odgaard mailinglist@textmate.org wrote:
There actually is API to show images in the gutter with associated tool tips.
So technically this could be done by having a bundle command generate the image and set this in the gutter, e.g. on save (this is similar to how the SCM diff markers work).
Does it have to be a file or can it be base64 data as well?
On 24 May 2016, at 14:23, Fabian Zeindl wrote:
Does it have to be a file or can it be base64 data as well?
You have to provide a path which serves as the identifier for the mark, for example from within TextMate you can press ⌃R on the following line:
"$TM_MATE" --set-mark "$TM_APP_PATH/Contents/Resources/TextMate.icns" --line 3
This shows the TextMate app icon in the gutter’s third line. You can clear it again using:
"$TM_MATE" --clear-mark "$TM_APP_PATH/Contents/Resources/TextMate.icns" --line 3
However, now that I just tested the above I realize that gutter marks are rendered as monochrome so that they match any theme.
Though should anyone provide a proof-of-concept for this, I can help out adding support for setting color marks. Could base this simply on image naming conventions to avoid needing new API.
The “difficult” part is scanning the current CSS file and generating image squares for all lines with color specifications, once we have that, it should not be a problem hooking it up to TextMate.
Thanks Allan,
Looks interesting, I will have a play around with this when I can I was hoping I might be able to call out to ImageMagick to generate a suitable ICNS icon, but from what I can see it doesn't support ICNS forma, which is a shame.
- Do 'marks' persist in any way, in projects or maybe tm settings? Ie, if I was to pass a /tmp/some_temp_file.icns, would that cause an issue later if the /tmp file was later deleted and Tm relaunched?
- I wonder how feasible it would be for TM to allow a new switch in the mark API, something like... "$TM_MATE" --set-mark-bg-color "#FF0000" --line 3
This would let us set the background color of the gutter, irrespective of the theme And also allow it to be used independantly of the current monochrome marks feature.
Just a thought anyway, not sure how easy it would be
Thanks Paul
On 24 May 2016 at 13:39, Allan Odgaard mailinglist@textmate.org wrote:
On 24 May 2016, at 14:23, Fabian Zeindl wrote:
Does it have to be a file or can it be base64 data as well?
You have to provide a path which serves as the identifier for the mark, for example from within TextMate you can press ⌃R on the following line:
"$TM_MATE" --set-mark
"$TM_APP_PATH/Contents/Resources/TextMate.icns" --line 3
This shows the TextMate app icon in the gutter’s third line. You can clear it again using:
"$TM_MATE" --clear-mark
"$TM_APP_PATH/Contents/Resources/TextMate.icns" --line 3
However, now that I just tested the above I realize that gutter marks are rendered as monochrome so that they match any theme.
Though should anyone provide a proof-of-concept for this, I can help out adding support for setting color marks. Could base this simply on image naming conventions to avoid needing new API.
The “difficult” part is scanning the current CSS file and generating image squares for all lines with color specifications, once we have that, it should not be a problem hooking it up to TextMate.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 2016-05-25 03:12, Carpii UK wrote:
Thanks Allan,
Looks interesting, I will have a play around with this when I can I was hoping I might be able to call out to ImageMagick to generate a suitable ICNS icon, but from what I can see it doesn't support ICNS forma, which is a shame.
I don't think ICNS is a requirement. The built-in icons, error and warning, use PDF, IIRC.
- Do 'marks' persist in any way, in projects or maybe tm settings?
Ie, if I was to pass a /tmp/some_temp_file.icns, would that cause an issue later if the /tmp file was later deleted and Tm relaunched?
- I wonder how feasible it would be for TM to allow a new switch in the
mark API, something like... "$TM_MATE" --set-mark-bg-color "#FF0000" --line 3
This would let us set the background color of the gutter, irrespective of the theme And also allow it to be used independantly of the current monochrome marks feature.
Just a thought anyway, not sure how easy it would be
Probably not that hard.
If mark icons are used for this I can see that this could cause conflicts with errors or warnings for something like a CSS preprocessor (Sass, LESS) or perhaps a CSS linter. I assume the mark icons for the color should be persistent, but, as far as I know, it's only possible to have one icon per line. If one runs a build command for Sass or LESS which use marks to report errors they would override the colors.
I think setting the background color as the Atom Pigments pulgin does would be pretty cool. Just make sure it's possible to turn off somehow. The Atom Pigments plugins has a couple of different ways to display the colors [1].
An additional alternative would be to have a tooltip showing the color on mouse hover. Or is it important that the color is always visible?
[1] https://github.com/abe33/atom-pigments#marker-type
I advocate for a base64 encoded bitmap.
Textmate should be easily able to display that and it would provide maximum flexibility for plugins as it's creation can be abstractes.
It only would lead to less issues with path, tmp files etc.
Clarification: a base64 string argument that encodes a bitmap.
On 25 May 2016, at 09:20, Fabian Zeindl fabian.zeindl@gmail.com wrote:
I advocate for a base64 encoded bitmap.
Textmate should be easily able to display that and it would provide maximum flexibility for plugins as it's creation can be abstractes.
It only would lead to less issues with path, tmp files etc.
-- Sent from my iPhone
On 2016-05-25 03:12, Carpii UK wrote: Thanks Allan,
Looks interesting, I will have a play around with this when I can I was hoping I might be able to call out to ImageMagick to generate a suitable ICNS icon, but from what I can see it doesn't support ICNS forma, which is a shame.
I don't think ICNS is a requirement. The built-in icons, error and warning, use PDF, IIRC.
- Do 'marks' persist in any way, in projects or maybe tm settings?
Ie, if I was to pass a /tmp/some_temp_file.icns, would that cause an issue later if the /tmp file was later deleted and Tm relaunched?
- I wonder how feasible it would be for TM to allow a new switch in the
mark API, something like... "$TM_MATE" --set-mark-bg-color "#FF0000" --line 3
This would let us set the background color of the gutter, irrespective of the theme And also allow it to be used independantly of the current monochrome marks feature.
Just a thought anyway, not sure how easy it would be
Probably not that hard.
If mark icons are used for this I can see that this could cause conflicts with errors or warnings for something like a CSS preprocessor (Sass, LESS) or perhaps a CSS linter. I assume the mark icons for the color should be persistent, but, as far as I know, it's only possible to have one icon per line. If one runs a build command for Sass or LESS which use marks to report errors they would override the colors.
I think setting the background color as the Atom Pigments pulgin does would be pretty cool. Just make sure it's possible to turn off somehow. The Atom Pigments plugins has a couple of different ways to display the colors [1].
An additional alternative would be to have a tooltip showing the color on mouse hover. Or is it important that the color is always visible?
[1] https://github.com/abe33/atom-pigments#marker-type
-- /Jacob Carlborg
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 25 May 2016, at 8:42, Jacob Carlborg wrote:
I don't think ICNS is a requirement. The built-in icons, error and warning, use PDF, IIRC.
Correct, they can be any format that is supported by NSImage (TIFF, GIF, PNG, etc.).
We use PDF for the current gutter images because that allows us to use vector images.
[…] If one runs a build command for Sass or LESS which use marks to report errors they would override the colors.
The images are “stacked” although only top one is drawn. But that means once the issue is fixed, the warning/error image should disappear and again reveal the color.
On 25 May 2016 at 09:28, Allan Odgaard mailinglist@textmate.org wrote:
On 25 May 2016, at 8:42, Jacob Carlborg wrote:
I don't think ICNS is a requirement. The built-in icons, error and
warning, use PDF, IIRC.
Correct, they can be any format that is supported by NSImage (TIFF, GIF, PNG, etc.).
Do you know if this also supports SVG?
As its nothing but a bit of xml/ascii, it wouldn't need base64 encoding. Could also generate these very efficiently, for a given color, without shelling out to some sort of image tool. Also like PDF, its a vector format so would scale for all UI sizes
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 2016-05-26 21:05, Carpii UK wrote:
Do you know if this also supports SVG?
As its nothing but a bit of xml/ascii, it wouldn't need base64 encoding. Could also generate these very efficiently, for a given color, without shelling out to some sort of image tool. Also like PDF, its a vector format so would scale for all UI sizes
According to the UTCoreTypes.h header file in the LaunchServices framework in the CoreServices framework SVG is supported since OS X 10.10.
But to be sure you should call the "imageTypes" class method on NSImage.
If you could have HTML/CSS in the tooltips you could just make a quick popover that wouldn't need any images, I already have a command that does this (as a new window) because the color selector doesn't like CSS rgb definitions.
On 27 May 2016 at 00:21, Jacob Carlborg doob@me.com wrote:
On 2016-05-26 21:05, Carpii UK wrote:
Do you know if this also supports SVG?
As its nothing but a bit of xml/ascii, it wouldn't need base64 encoding. Could also generate these very efficiently, for a given color, without shelling out to some sort of image tool. Also like PDF, its a vector format so would scale for all UI sizes
According to the UTCoreTypes.h header file in the LaunchServices framework in the CoreServices framework SVG is supported since OS X 10.10.
But to be sure you should call the "imageTypes" class method on NSImage.
-- /Jacob Carlborg
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Ability to show colored tooltips is very cool
But to be honest my original query was more to do with just seeing the colors all inline.
I prefer not to use the mouse unless necessary (but also some problems can only be seen by an overview, instead of hovering over each item in turn)
On 27 May 2016 at 15:46, Allan Odgaard mailinglist@textmate.org wrote:
On 27 May 2016, at 15:00, George McGinley Smith wrote:
If you could have HTML/CSS in the tooltips you could just make a quick popover that wouldn't need any images […]
From your command you can run this:
"$DIALOG" tooltip --html '<div style="…">…</div>'
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 26 May 2016, at 22:21, Jacob Carlborg wrote:
According to the UTCoreTypes.h header file in the LaunchServices framework in the CoreServices framework SVG is supported since OS X 10.10.
This would appear to be only as an UTI definition, i.e. NSImage can’t actually load these, although QuickLook actually can (but possibly via a WebView).
But to be sure you should call the "imageTypes" class method on NSImage.
EPS is there, which is a vector format with a textual representation, so possible to generate from any scripting language without the use of any image libraries.
But rather than read the EPS/PS standard I cheated and saved a blue square with a black border from Sketch and looked at the source and it looks like gibberish :) but a lot of it seemed to be (possibly unnecessary) boilerplate.
I did test it with mate’s `--set-mark` and it works fine (I changed `GutterView.mm` to just draw the image rather than create a mask, so that we get color). Though I wouldn’t want this change for all images, I suggest including “Color” in the image name to indicate that it is not a mask (although this is opposite of the OS where a “Template” suffix indicates that it is monochrome image, but if we make this change, we have to change all existing uses of `--set-mark`).
I also added a new `callback.document.did-open` so that colors can be added during load instead of only during save (available starting with 2.0-beta.9.3) — this also benefits the SCM Diff Gutter bundle where it has always annoyed me that the marks didn’t appear until first save.
On 2016-05-30 13:19, Allan Odgaard wrote:
This would appear to be only as an UTI definition, i.e. NSImage can’t actually load these, although QuickLook actually can (but possibly via a WebView).
That's that what I get for reading that manual for once :).
I also added a new `callback.document.did-open` so that colors can be added during load instead of only during save (available starting with 2.0-beta.9.3) — this also benefits the SCM Diff Gutter bundle where it has always annoyed me that the marks didn’t appear until first save.
Ah, that's cool.
On 30.05.2016, at 13:19 , Allan Odgaard mailinglist@textmate.org wrote:
But rather than read the EPS/PS standard I cheated and saved a blue square with a black border from Sketch and looked at the source and it looks like gibberish :) but a lot of it seemed to be (possibly unnecessary) boilerplate.
Did you check if it’s just gzipped or zipped?
I recall programming PS in university, it was common to gzip it, most viewers can read it that way.
fabian
On 30 May 2016, at 14:05, Fabian Zeindl wrote:
[…] saved a blue square with a black border from Sketch and looked at the source and it looks like gibberish :)
Did you check if it’s just gzipped or zipped?
It was ASCII, I just meant it was arcane at best and came in at 18kb for this single blue square.
And related to this thread, beta 9.3 (nightly build) has support for both a “did open” command callback and setting multi-color images in the gutter (I decided on making it so that monochrome images must have a “Template” suffix to follow the system convention).
So now someone just needs to a) create a script to find everywhere a color is specified in a CSS file and b) generate an image from a CSS color specification.
I personally do not plan to do any of this, but will gladly assist anyone who wants to undertake this task and require help.
On 30 May 2016 at 20:45, Allan Odgaard mailinglist@textmate.org wrote:
On 30 May 2016, at 14:05, Fabian Zeindl wrote:
So now someone just needs to a) create a script to find everywhere a
color is specified in a CSS file and b) generate an image from a CSS color specification.
Thanks for spending time on this. I will try to tackle to last two steps, although it won't be until the weekend
a) create a script to find everywhere a color is specified in a CSS file
How would this look? Would it require a bundle-style reg-exp which pulls them all out?
My preference would be to write it as a proper script (in the hope it could be extended to parse any extra SASS files in future), but I'm not sure what this would output? Any particular language preference?
b) generate an image from a CSS color specification.
I'll look into this too, maybe I can do something with EPS. Would each image need to be written to disk, or simply be another script which streams it to stdout, and somehow TM calls it and reads the image from there?
Thanks
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 30 May 2016, at 23:04, Carpii UK wrote:
a) create a script to find everywhere a color is specified in a CSS file
How would this look? Would it require a bundle-style reg-exp which pulls them all out?
My preference would be to write it as a proper script […]
Yes, write a regular script that reads a CSS file (preferably from stdin) and then parses this and for each color it finds, it needs to execute this:
"$TM_MATE" --line «line»[:«column»] --set-mark «/path/to/color-image.eps»
So it should track the line number and could also track the column number, but for now, the result will be the same (since we add to the gutter rather than inlined).
b) generate an image from a CSS color specification.
I'll look into this too, maybe I can do something with EPS. Would each image need to be written to disk, or simply be another script which streams it to stdout, and somehow TM calls it and reads the image from there?
It needs to be written to disk, I suggest using a location like `~/Library/Caches/com.macromates.textmate.colors/` and then you can also skip generating an image if the file already exist.
I realize a minor nuisance: currently when you set a mark you must manually clear that mark yourself by specifying the same image, e.g. to clear the mark from the above example we need to run:
"$TM_MATE" --line «line»[:«column»] --clear-mark «/path/to/color-image.eps»
We can remove the `--line` argument to remove all the marks using this image, but we still need to specify the image, so for a script that generates arbitrary images, this requires some bookkeeping.
I think one solution could be that if the path supplied to `--clear-mark` ends with a slash, it will clear all marks which are descendents of that path, so that the script only need to make one call to `--clear-mark` rather than one per image it has previously set/generated.
Yes, write a regular script that reads a CSS file (preferably from stdin)
Thanks Allan, this is a lot clearer now. Just a couple more questions..
Would you expect it to be pure shell/bashscript, or could I use node/php etc? I know some bundles use ruby or node, but with CSS being a core bundle I'm not sure if you try to reduce runtime dependencies?
So it should track the line number and could also track the column number, but for now, the result will be the same (since we add to the gutter rather than inlined).
Ok, I will output column offset anyway, and then TM can just ignore it
What are your thoughts when a line has more than one color.... border-color: #F00 #0F0 #00F #FF0;
I could either just output the first color and discard the rest Or I could output them all, in reverse order (maybe for future use somehow?) This would mean they are all included, but the first color ends up overwriting the latter ones in the gutter.
It needs to be written to disk, I suggest using a location like `~/Library/Caches/com.macromates.textmate.colors/` and then you can also skip generating an image if the file already exist.
Safe to just hardcode this path relative to ~/ ? Or should I be basing it on some $TM_ENV_VAR ?
I think one solution could be that if the path supplied to `--clear-mark` ends with a slash, it will clear all marks which are descendents of that path, so that the script only need to make one call to `--clear-mark` rather than one per image it has previously set/generated.
This seems like a good solution. Should I namespace my 'colors' dir to include a bundle name subdir?
~/Library/Caches/com.macromates.textmate.colors/css/*.eps
Im thinking if another bundle was ever to use this gutter color api, my bundle can call
--clear-mark ~/Library/Caches/com.macromates.textmate.colors/css/
and it would avoid clearing any color marks other bundles might have set? Not sure, perhaps I'm overthinking it :-)
Thanks
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 2016-05-31 00:31, Carpii UK wrote:
Would you expect it to be pure shell/bashscript, or could I use node/php etc? I know some bundles use ruby or node, but with CSS being a core bundle I'm not sure if you try to reduce runtime dependencies?
Ruby has been shipping with OS X since 10.4. TextMate also ships Ruby 1.8.
I would suggest not requiring any additional dependencies, i.e. dependencies that are not shipped with OS X or TextMate. Especially if you're going to use the new did-open callback. You don't want things to break just because you open a CSS file ;). It's different with a bundle command/snippet, because that's optional to invoke.
On 2016-05-30 21:45, Allan Odgaard wrote:
And related to this thread, beta 9.3 (nightly build) has support for both a “did open” command callback and setting multi-color images in the gutter (I decided on making it so that monochrome images must have a “Template” suffix to follow the system convention).
So now someone just needs to a) create a script to find everywhere a color is specified in a CSS file and b) generate an image from a CSS color specification.
I'm a bit worried about the this "did open" callback in combination with TextMate's synchronous way of executing bundle commands.
If a command that uses "did open" takes some time to execute, TextMate will block/freeze until the command completes. If the user at the same time tries to use the application it kind of queues up the actions and when the command completes TextMate acts really weird [1].
If this CSS command is going to read and parse files and generating images that needs to be written to disk I'm starting to get concerned.
[1] The behavior of a blocking command taking long time to execute is easy to simulate by creating a new command (or use the existing "SCM Diff Gutter" bundle) with the semantic class "callback.document.did-open". For the actual code, add this:
#!/usr/bin/env ruby sleep 5
That simulates a command taking five seconds to execute.
On 30.05.2016, at 23:04 , Carpii UK carpii.uk@gmail.com wrote:
I'll look into this too, maybe I can do something with EPS. Would each image need to be written to disk, or simply be another script which streams it to stdout, and somehow TM calls it and reads the image from there?
EPS is a simpler form of postscript, which is just a programming language:
http://www.physics.emory.edu/faculty/weeks//graphics/howtops1.html http://www.tcm.phy.cam.ac.uk/~mjr/eps.pdf
On 31 May 2016, at 8:52, Jacob Carlborg wrote:
If this CSS command is going to read and parse files and generating images that needs to be written to disk I'm starting to get concerned.
The command can fork and do the work in the background (without stalling TextMate), since it is not a “filter”.
On 31 May 2016, at 08:35, Allan Odgaard mailinglist@textmate.org wrote:
On 31 May 2016, at 8:52, Jacob Carlborg wrote:
If this CSS command is going to read and parse files and generating images that needs to be written to disk I'm starting to get concerned.
The command can fork and do the work in the background (without stalling TextMate), since it is not a “filter”.
What will happen when a user edits their CSS file? Can there be a trigger to re-run the image generation, say, on save? Otherwise it could lead to a fair bit of confusion when a user updates their file and the colours remain as previously.
On 31 May 2016, at 10:08, Justin Catterall wrote:
What will happen when a user edits their CSS file? Can there be a trigger to re-run the image generation, say, on save? Otherwise it could lead to a fair bit of confusion when a user updates their file and the colours remain as previously.
Yes, command will be set to run on open and save.
This is similar to the SCM Diff Gutter bundle which use the gutter to indicate which lines are changed, but only update on save (and now also first load of a document).
I actually have a local branch which allow commands to run on “document changed” which is designed for live HTML/Markdown preview, but could also be used for updating the gutter. Though there are some minor issues that need fixing before I can push this to master.
On 31 May 2016, at 0:31, Carpii UK wrote:
I know some bundles use ruby or node, but with CSS being a core bundle I'm not sure if you try to reduce runtime dependencies?
Yes, we prefer to have things work out-of-the-box. So you could use PHP, but node is not feasible.
What are your thoughts when a line has more than one color.... border-color: #F00 #0F0 #00F #FF0;
I could either just output the first color and discard the rest Or I could output them all, in reverse order (maybe for future use somehow?) This would mean they are all included, but the first color ends up overwriting the latter ones in the gutter.
If you obtain the column offset then just set all of them and let TextMate figure it out :)
Right now I think it’ll show the one with the lowest column offset.
I’m not against an API to embed things into the editor, so good to keep an open mind toward future adaptation of the command.
Safe to just hardcode this path relative to ~/ ? Or should I be basing it on some $TM_ENV_VAR ?
I would “hardcode” it, since ~/Library/Caches is the system cache directory and `com.macromates.textmate.colors` would be our “key” under which we store our images in this cache.
Should I namespace my 'colors' dir to include a bundle name subdir?
I think using `com.macromates.textmate.colors` is enough. You can make the last component `css-colors` but I’m thinking the same command might handle multiple formats, or if we have different commands for CSS, SCSS, etc. then they benefit from using the same cache, and there is no issue with the SCSS command clearing colors in the CSS namespace, since one file will only be operated on by one of the commands.
I realise it's not what you were after, but as a quick fix I think it works quite well. Especially now it runs as a tooltip (thanks Allan).
Here's my command: https://gist.github.com/gdsmith/a87f38ee40e09de6e5a71afa487403a6
I have it bound to the same keyboard shortcut as CSS color insert (⌘+⇧+C) so I get to choose, and there's no mousing involved. You can even select the whole doc and run it to get all colours in your current file.
On 28 May 2016 at 06:41, Carpii UK carpii.uk@gmail.com wrote:
Ability to show colored tooltips is very cool
But to be honest my original query was more to do with just seeing the colors all inline.
I prefer not to use the mouse unless necessary (but also some problems can only be seen by an overview, instead of hovering over each item in turn)
On 27 May 2016 at 15:46, Allan Odgaard mailinglist@textmate.org wrote:
On 27 May 2016, at 15:00, George McGinley Smith wrote:
If you could have HTML/CSS in the tooltips you could just make a quick popover that wouldn't need any images […]
From your command you can run this:
"$DIALOG" tooltip --html '<div style="…">…</div>'
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 2016-05-31 10:15, Allan Odgaard wrote:
I actually have a local branch which allow commands to run on “document changed” which is designed for live HTML/Markdown preview, but could also be used for updating the gutter. Though there are some minor issues that need fixing before I can push this to master.
This is getting better and better. I absolutely love that idea :). Will there be a delay, or an option for delay, for when the command is executed? It doesn't always make sense to immediately run a command on "document changed".
That feature would go really well with inline marks, if TextMate would have that feature [1]. It can be a bit too much "in your face" to open a new window with information just by typing in the document. The current gutter marks require one to click on the mark to display the message.
I actually implemented something similar to on "document changed" directly in TextMate. It was hardcoded to run Rubocop. Worked really well together with the inline marks. The only problem was that I had no way to hide an inline mark, and when basically all lines have a violation it got a bit too much. It's also a bit annoying to have a fork to keep up to date.
[1] https://github.com/textmate/textmate/pull/1297
On 2016-05-31 09:35, Allan Odgaard wrote:
The command can fork and do the work in the background (without stalling TextMate), since it is not a “filter”.
I tried using fork and sleep in the "SCM Diff Gutter" command, didn't help. Do you have a code example on how fork should be used?
On 31 May 2016, at 14:57, Jacob Carlborg wrote:
I tried using fork and sleep in the "SCM Diff Gutter" command, didn't help. Do you have a code example on how fork should be used?
You need to also close stdout/err, example:
pid = fork do STDOUT.reopen(open('/dev/null', 'w')) STDERR.reopen(open('/dev/null', 'w'))
sleep 5 end Process.detach(pid)
On 31 May 2016, at 14:07, Jacob Carlborg wrote:
This is getting better and better. I absolutely love that idea :). Will there be a delay, or an option for delay, for when the command is executed? It doesn't always make sense to immediately run a command on "document changed".
Yes, it is “document changed and user idle for n seconds” like the old live preview worked.
This is a nice addition. While at it, what about CSS gradients? I understand this would require a webrenderer, and could cause some overhead. Although George's tooltip solution could work.
On May 31 2016, at 3:14 pm, Allan Odgaard <mailinglist@textmate.org> wrote:
On 31 May 2016, at 14:07, Jacob Carlborg wrote:
> This is getting better and better. I absolutely love that idea :).
> Will there be a delay, or an option for delay, for when the command is > executed? It doesn't always make sense to immediately run a command on > "document changed".
Yes, it is “document changed and user idle for n seconds” like the
old live preview worked.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Had a couple of hours spare today, so set about trying to see how I could generate an eps file from script (bash/PHP)
Saving a 10*10 flat color eps from Illustrator resulted in a 400k file. As Allan says, much of it will be boilerplate and error handling, but either way, its not practical to strip that down to a barebone vector eps.
Looking at the other software tools I had available, it seems many of them don't actually create a true vector image, but simply embed a rasterised bitmap inside an EPS wrapper (in which case it offers none of the advantages of EPS, as we may aswell revert to PNG).
Can anyone recommend some tools which are able to produce small eps files, but are still actually vectors?
Playing with ImageMagick at the moment, but Im not yet convinced thats not rasterising the end result also
On 31 May 2016 at 15:56, Jacob Carlborg doob@me.com wrote:
On 2016-05-31 15:12, Allan Odgaard wrote:
You need to also close stdout/err, example:
pid = fork do STDOUT.reopen(open('/dev/null', 'w')) STDERR.reopen(open('/dev/null', 'w')) sleep 5 end Process.detach(pid)
Ah, that worked. Thanks.
-- /Jacob Carlborg
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
%!PS-Adobe-3.1 EPSF-3.0 %%BoundingBox: 0 0 10 10 newpath 0 0 moveto 0 10 rlineto 10 0 rlineto 0 -10 rlineto closepath 0.1 0.4 0.7 setrgbcolor fill
On May 31, 2016, at 21:20, Carpii UK carpii.uk@gmail.com wrote:
Had a couple of hours spare today, so set about trying to see how I could generate an eps file from script (bash/PHP)
Saving a 10*10 flat color eps from Illustrator resulted in a 400k file. As Allan says, much of it will be boilerplate and error handling, but either way, its not practical to strip that down to a barebone vector eps.
Looking at the other software tools I had available, it seems many of them don't actually create a true vector image, but simply embed a rasterised bitmap inside an EPS wrapper (in which case it offers none of the advantages of EPS, as we may aswell revert to PNG).
Can anyone recommend some tools which are able to produce small eps files, but are still actually vectors?
Playing with ImageMagick at the moment, but Im not yet convinced thats not rasterising the end result also
On 31 May 2016 at 15:56, Jacob Carlborg <doob@me.com mailto:doob@me.com> wrote: On 2016-05-31 15:12, Allan Odgaard wrote:
You need to also close stdout/err, example:
pid = fork do STDOUT.reopen(open('/dev/null', 'w')) STDERR.reopen(open('/dev/null', 'w')) sleep 5 end Process.detach(pid)
Ah, that worked. Thanks.
-- /Jacob Carlborg
textmate mailing list textmate@lists.macromates.com mailto:textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Thats beautiful :-)
thankyou
On 1 June 2016 at 03:56, Gerd Knops gerti-textmate@bitart.com wrote:
%!PS-Adobe-3.1 EPSF-3.0 %%BoundingBox: 0 0 10 10 newpath 0 0 moveto 0 10 rlineto 10 0 rlineto 0 -10 rlineto closepath 0.1 0.4 0.7 setrgbcolor fill
On May 31, 2016, at 21:20, Carpii UK carpii.uk@gmail.com wrote:
Had a couple of hours spare today, so set about trying to see how I could generate an eps file from script (bash/PHP)
Saving a 10*10 flat color eps from Illustrator resulted in a 400k file. As Allan says, much of it will be boilerplate and error handling, but either way, its not practical to strip that down to a barebone vector eps.
Looking at the other software tools I had available, it seems many of them don't actually create a true vector image, but simply embed a rasterised bitmap inside an EPS wrapper (in which case it offers none of the advantages of EPS, as we may aswell revert to PNG).
Can anyone recommend some tools which are able to produce small eps files, but are still actually vectors?
Playing with ImageMagick at the moment, but Im not yet convinced thats not rasterising the end result also
On 31 May 2016 at 15:56, Jacob Carlborg doob@me.com wrote:
On 2016-05-31 15:12, Allan Odgaard wrote:
You need to also close stdout/err, example:
pid = fork do STDOUT.reopen(open('/dev/null', 'w')) STDERR.reopen(open('/dev/null', 'w')) sleep 5 end Process.detach(pid)
Ah, that worked. Thanks.
-- /Jacob Carlborg
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
I have a command that's working, but it's slow – the method for clearing marks is definitely a bottleneck. So, yeah, it needs something simpler to clear all the marks and probably some feedback on improving the speed (I'm not a ruby dev). Also, clearing without the line number seems to clear the marks for all open docs every time, rather than just the one you're looking at. Perhaps saving a copy of the current files marks to a temp file would help, then you could read that in and remove them all.
https://gist.github.com/gdsmith/10b7eefa413af7d1ba914fc5dffe44e9
On 1 June 2016 at 07:35, Carpii UK carpii.uk@gmail.com wrote:
Thats beautiful :-)
thankyou
On 1 June 2016 at 03:56, Gerd Knops gerti-textmate@bitart.com wrote:
%!PS-Adobe-3.1 EPSF-3.0 %%BoundingBox: 0 0 10 10 newpath 0 0 moveto 0 10 rlineto 10 0 rlineto 0 -10 rlineto closepath 0.1 0.4 0.7 setrgbcolor fill
On May 31, 2016, at 21:20, Carpii UK carpii.uk@gmail.com wrote:
Had a couple of hours spare today, so set about trying to see how I could generate an eps file from script (bash/PHP)
Saving a 10*10 flat color eps from Illustrator resulted in a 400k file. As Allan says, much of it will be boilerplate and error handling, but either way, its not practical to strip that down to a barebone vector eps.
Looking at the other software tools I had available, it seems many of them don't actually create a true vector image, but simply embed a rasterised bitmap inside an EPS wrapper (in which case it offers none of the advantages of EPS, as we may aswell revert to PNG).
Can anyone recommend some tools which are able to produce small eps files, but are still actually vectors?
Playing with ImageMagick at the moment, but Im not yet convinced thats not rasterising the end result also
On 31 May 2016 at 15:56, Jacob Carlborg doob@me.com wrote:
On 2016-05-31 15:12, Allan Odgaard wrote:
You need to also close stdout/err, example:
pid = fork do STDOUT.reopen(open('/dev/null', 'w')) STDERR.reopen(open('/dev/null', 'w')) sleep 5 end Process.detach(pid)
Ah, that worked. Thanks.
-- /Jacob Carlborg
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 2 Jun 2016, at 9:45, George McGinley Smith wrote:
I have a command that's working, but it's slow – the method for clearing marks is definitely a bottleneck. So, yeah, it needs something simpler to clear all the marks and probably some feedback on improving the speed (I'm not a ruby dev). Also, clearing without the line number seems to clear the marks for all open docs every time, rather than just the one you're looking at.
For the latter, specify the document e.g. via `--uuid="$TM_DOCUMENT_UUID"`.
For the former, I added support for this in beta 9.4 which is available by holding option down and clicking Check Now in Preferences → Software Update.
Perhaps saving a copy of the current files marks to a temp file would help, then you could read that in and remove them all.
I collected all the calls to `mate` into a single call in this version, that way, there should be practically no flicker for the colored squares:
https://gist.github.com/sorbits/69e77ecd69efed2251be3d9bf1f1864e
Also use `shellescape` method instead of single quotes and create cache folder if it does not exist.
So awesome, thanks Allan.
On 2 June 2016 at 17:27, Allan Odgaard mailinglist@textmate.org wrote:
On 2 Jun 2016, at 9:45, George McGinley Smith wrote:
I have a command that's working, but it's slow – the method for clearing
marks is definitely a bottleneck. So, yeah, it needs something simpler to clear all the marks and probably some feedback on improving the speed (I'm not a ruby dev). Also, clearing without the line number seems to clear the marks for all open docs every time, rather than just the one you're looking at.
For the latter, specify the document e.g. via `--uuid="$TM_DOCUMENT_UUID"`.
For the former, I added support for this in beta 9.4 which is available by holding option down and clicking Check Now in Preferences → Software Update.
Perhaps saving a copy of the current files marks to a temp file would
help, then you could read that in and remove them all.
I collected all the calls to `mate` into a single call in this version, that way, there should be practically no flicker for the colored squares:
https://gist.github.com/sorbits/69e77ecd69efed2251be3d9bf1f1864e
Also use `shellescape` method instead of single quotes and create cache folder if it does not exist.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Hi all,
this is a really nice implementation!
Do you expect that this will be implemented in one of the TM-bundles so it can be improved and maintained, or do I have te create my own command (as I have done now)?
Regards, Feek
-- View this message in context: http://textmate.1073791.n5.nabble.com/showing-preview-of-css-colors-tp30012p... Sent from the textmate users mailing list archive at Nabble.com.
Allan/George,
You've done some great work on this, thankyou! I had really hoped to contribute, but found myself suddenly battling with other problems (samba corruption etc) and then kinda lost track of it
With Allan and Georges permission, I would like to create a github with a proper bundle, so its something new users can access easily (giving full credit of course, since none of it is my work). Or if this bundle already exists, please send me a link
I plan to then improve parsing support for named css colors (red etc), which appears to be missing at the moment, and possibly some sort of support for gradients
Cheers Paul
On 4 July 2016 at 09:05, feek feekdiv@gmail.com wrote:
Hi all,
this is a really nice implementation!
Do you expect that this will be implemented in one of the TM-bundles so it can be improved and maintained, or do I have te create my own command (as I have done now)?
Regards, Feek
-- View this message in context: http://textmate.1073791.n5. nabble.com/showing-preview-of-css-colors-tp30012p30143.html Sent from the textmate users mailing list archive at Nabble.com.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Thanks Allan,
I wasn't sure if you had plans in the pipeline, to publish it as an official bundle (in which case no point me getting involved) I will create a basic github shortly, so at least we have a starting point for any future dev on it
Cheers
On 20 September 2016 at 16:50, Allan Odgaard mailinglist@textmate.org wrote:
On 19 Sep 2016, at 2:43, Carpii UK wrote:
With Allan and Georges permission, I would like to create a github with a proper bundle […]
Sure, go ahead, you don’t need my permission to put code on the internet :)
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Happy for anything I contributed to be added. As a thought, would it make sense to add this to the default CSS bundle (e.g. fork that and add a pull request) rather than creating something new?
https://github.com/textmate/css.tmbundle/
On Fri, 23 Sep 2016 at 04:32 Carpii UK carpii.uk@gmail.com wrote:
Thanks Allan,
I wasn't sure if you had plans in the pipeline, to publish it as an official bundle (in which case no point me getting involved) I will create a basic github shortly, so at least we have a starting point for any future dev on it
Cheers
On 20 September 2016 at 16:50, Allan Odgaard mailinglist@textmate.org wrote:
On 19 Sep 2016, at 2:43, Carpii UK wrote:
With Allan and Georges permission, I would like to create a github with
a
proper bundle […]
Sure, go ahead, you don’t need my permission to put code on the internet :)
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 23 September 2016 at 08:36, George McGinley Smith george@gsgd.co.uk wrote:
Happy for anything I contributed to be added.
Thanks George
As a thought, would it make sense to add this to the default CSS bundle (e.g. fork that and add a pull request) rather than creating something new?
Yep, that's a much better idea. I will do that
Cheers
https://github.com/textmate/css.tmbundle/
On Fri, 23 Sep 2016 at 04:32 Carpii UK carpii.uk@gmail.com wrote:
Thanks Allan,
I wasn't sure if you had plans in the pipeline, to publish it as an official bundle (in which case no point me getting involved) I will create a basic github shortly, so at least we have a starting point for any future dev on it
Cheers
On 20 September 2016 at 16:50, Allan Odgaard mailinglist@textmate.org wrote:
On 19 Sep 2016, at 2:43, Carpii UK wrote:
With Allan and Georges permission, I would like to create a github
with a
proper bundle […]
Sure, go ahead, you don’t need my permission to put code on the internet :)
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate