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 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 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.

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

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 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

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 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 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

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 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.

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 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 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

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

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)

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

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

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.

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.

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 :)

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