The current situation A major goal of all the scoping standardizationstuff we do in the syntaxes is to make it really easy so make a single theme that can be used for any language. Unfortunately, the reality is that languages are really complex and it takes work to make a theme look good in more than a few languages. And then more work to keep that theme looking good as the languages syntaxes are updated and improved.
So, what do we have? We have a handful of deep themes and a whole hugh mess of really good looking shallow themes. the deep themes are constantly updated and work in most every language. The shallow themes are usually never updated and only work in a few languages and break on most edge cases like deeply nested embedded source.
The future Themes are going to be even more important in the next major release of TextMate. Themes will be more than just style, they will really start making inroads into real functionality. We'll be able to color things like the current selection, the current line, merge conflicts, tab triggers, placeholders, etc... probably even more. [see http://pastie.textmate.org/39665]
This means that themes are going to become much more important to the way you use the application than ever before. Which means that it's going to become that much more difficult to make a theme that really works for more than a few people and keep it updated.
Tweaked Theme Versions instead of new Themes! I think we need to move away from a Theme-as-style type of mentality and more to a Theme-as-functionality type of thinking. I've put a lot of work into my Brilliance Black theme, but frankly a lot of people think it's really ugly. Why is it so ugly? Mostly just my color choices. People all have different tastes. Also, it's totally unusable on a dark CRT or LCD.
I've made a few versions of my Brilliance Black theme. Brilliance Dull, Brilliance White, Brilliance BBS, etc… The advantage of doing a version of an existing deep theme is that you get a new style without having to do all the coding of the random edge cases. It looks pretty without losing any theme-based functionality.
ShapeShifter Have you ever user ShapeShifter? There are all these OS themes that you can use to change the look of the chrome on all the windows and dock and whatever else on your system. There's also a new tool you can use to make a tweaked version of an existing theme. You can apply core image tweaks to all of the images in the theme and save out a tweaked version of a theme.
I think TextMate should do the same thing. Start with a good deep base theme like Twilight and tweak the colors. Then save the recipe of how you tweaked that theme. The advantage is that when Twilight is updated, all of your tweaked themes based off of it are also updated since they're just recipes instead of actually different themes. And you can make really creative new versions of themes without having to do all the work of figuring out all the crazy edge cases and junk.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
On Mon, 12 Feb 2007, subtleGradient / Thomas Aylott wrote:
I think TextMate should do the same thing. Start with a good deep base theme like Twilight and tweak the colors. Then save the recipe of how you tweaked that theme. The advantage is that when Twilight is updated, all of your tweaked themes based off of it are also updated since they're just recipes instead of actually different themes. And you can make really creative new versions of themes without having to do all the work of figuring out all the crazy edge cases and junk.
While this is a very good suggestion, it is certainly hindered by the fact that there is no comprehensive deep theme at the moment. E.g. the Brilliance themes are indeed well loaded with goodies, but they contain little in the way of coloring for OCaml constructs: nothing for modules, method calls, variant types, floating point numbers and operators, and so on -- these aren't even edge cases, they're core parts of the language, and I'm not sure their addition could be considered "tweaking". Now, I do 90% of my coding in OCaml, so this is what I've noticed, but I'd guess that there are other less-common languages in the bundles that are similarly unsupported by these deep themes.
This is, of course, fully understandible. If you don't code in OCaml, how the heck are you going to know what bits to add and highlight. That's why I haven't added anything for, say, HTML or CSS to any of my themes, because I touch a CSS file maybe four times a year. I wouldn't know what's missing in the theme...
So, what am I saying here? I suppose it's that if this idea of starting with a deep theme and tweaking is to get off the ground, we should probably put together an actual deep theme that has better coverage. Or something along those lines. Now, I'd be happy to add my bits to some reference theme that the other, existing themes can be retrofitted to match. I'm just wondering what the best way to do this is -- should we use one of the Brilliance themes and add to it (a Brilliance Reference if you will)? Or is there a better way? Does anyone have any good suggestions here?
William D. Neumann
---
"There's just so many extra children, we could just feed the children to these tigers. We don't need them, we're not doing anything with them.
Tigers are noble and sleek; children are loud and messy."
-- Neko Case
Life is unfair. Kill yourself or get over it. -- Black Box Recorder
I almost think that themes (after a certain set of core elements) need to be specialized to be good. Dawn is highly motivated by the fact that I code largely in OCaml (for instance), and it uglies up HTML something fierce. Maybe the right solution is a core theme with overlays that are activated based on the current base scope - so you would have Dawn base that included an HTML, OCaml, ruby, etc overlay.
-David
On 2/12/07, William D. Neumann wneumann@cs.unm.edu wrote:
On Mon, 12 Feb 2007, subtleGradient / Thomas Aylott wrote:
I think TextMate should do the same thing. Start with a good deep base theme like Twilight and tweak the colors. Then save the recipe of how you tweaked that theme. The advantage is that when Twilight is updated, all of your tweaked themes based off of it are also updated since they're just recipes instead of actually different themes. And you can make really creative new versions of themes without having to do all the work of figuring out all the crazy edge cases and junk.
While this is a very good suggestion, it is certainly hindered by the fact that there is no comprehensive deep theme at the moment. E.g. the Brilliance themes are indeed well loaded with goodies, but they contain little in the way of coloring for OCaml constructs: nothing for modules, method calls, variant types, floating point numbers and operators, and so on -- these aren't even edge cases, they're core parts of the language, and I'm not sure their addition could be considered "tweaking". Now, I do 90% of my coding in OCaml, so this is what I've noticed, but I'd guess that there are other less-common languages in the bundles that are similarly unsupported by these deep themes.
This is, of course, fully understandible. If you don't code in OCaml, how the heck are you going to know what bits to add and highlight. That's why I haven't added anything for, say, HTML or CSS to any of my themes, because I touch a CSS file maybe four times a year. I wouldn't know what's missing in the theme...
So, what am I saying here? I suppose it's that if this idea of starting with a deep theme and tweaking is to get off the ground, we should probably put together an actual deep theme that has better coverage. Or something along those lines. Now, I'd be happy to add my bits to some reference theme that the other, existing themes can be retrofitted to match. I'm just wondering what the best way to do this is -- should we use one of the Brilliance themes and add to it (a Brilliance Reference if you will)? Or is there a better way? Does anyone have any good suggestions here?
William D. Neumann
"There's just so many extra children, we could just feed the children to these tigers. We don't need them, we're not doing anything with them.
Tigers are noble and sleek; children are loud and messy."
-- Neko CaseLife is unfair. Kill yourself or get over it. -- Black Box Recorder
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On Feb 12, 2007, at 3:05 PM, David Powers wrote:
I almost think that themes (after a certain set of core elements) need to be specialized to be good. Dawn is highly motivated by the fact that I code largely in OCaml (for instance), and it uglies up HTML something fierce. Maybe the right solution is a core theme with overlays that are activated based on the current base scope - so you would have Dawn base that included an HTML, OCaml, ruby, etc overlay.
-David
There's another excellent idea. The ability to have separate themes per file or per window. I'd like to add onto that the ability to specify a separate theme per scope.
Then you could have one theme for html, one theme for embedded ruby, another theme for embedded javascript and another theme for embedded css. Add onto that an easy way to do theme variations with core image filters or something and you're good to go.
Then each language would look it's absolute best and still be able to have a unified style.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
On Feb 12, 2007, at 2:05 PM, David Powers wrote:
I almost think that themes (after a certain set of core elements) need to be specialized to be good. Dawn is highly motivated by the fact that I code largely in OCaml (for instance), and it uglies up HTML something fierce. Maybe the right solution is a core theme with overlays that are activated based on the current base scope - so you would have Dawn base that included an HTML, OCaml, ruby, etc overlay.
I'm not quite following how this can work. If you overlay for instance an OCaml specific theme on top of Twilight wouldn't it make parts of it look rather odd? For instance variables in Twilight are blue, if they are suddenly green in Ocaml I don't really see how this is a good thing.
-- On Feb 12, 2007, at 6:22 PM, subtleGradient / Thomas Aylott wrote:
There's another excellent idea. The ability to have separate themes per file or per window. I'd like to add onto that the ability to specify a separate theme per scope.
I can see the themes per scope being a good thing, but only the root scope. I can see someone wanting for instance their text based languages in a bright theme while leaving their coding in a dark theme. Different themes in one window though just seem like an unnecessary complexity.
Then each language would look it's absolute best and still be able to have a unified style.
How can mushing together different themes in one window ever look unified?
On Feb 13, 2007, at 5:06 AM, Michael Sheets wrote:
On Feb 12, 2007, at 2:05 PM, David Powers wrote:
I almost think that themes (after a certain set of core elements) need to be specialized to be good. Dawn is highly motivated by the fact that I code largely in OCaml (for instance), and it uglies up HTML something fierce. Maybe the right solution is a core theme with overlays that are activated based on the current base scope - so you would have Dawn base that included an HTML, OCaml, ruby, etc overlay.
I'm not quite following how this can work. If you overlay for instance an OCaml specific theme on top of Twilight wouldn't it make parts of it look rather odd? For instance variables in Twilight are blue, if they are suddenly green in Ocaml I don't really see how this is a good thing.
-- On Feb 12, 2007, at 6:22 PM, subtleGradient / Thomas Aylott wrote:
There's another excellent idea. The ability to have separate themes per file or per window. I'd like to add onto that the ability to specify a separate theme per scope.
I can see the themes per scope being a good thing, but only the root scope. I can see someone wanting for instance their text based languages in a bright theme while leaving their coding in a dark theme. Different themes in one window though just seem like an unnecessary complexity.
Then each language would look it's absolute best and still be able to have a unified style.
How can mushing together different themes in one window ever look unified?
This is assuming that you'd be able to use some sort of theme tweaking thing like in shapeshifter.
An HTML document gets one theme embedded javascript gets another embedded css gets another embedded ruby / php / asp /etc gets another Then you could apply a theme tweak to each of these themes to massage them into harmony
Currently, every theme is applied to every scope in the document. Which means that every theme must look good in every language. Which means that creating themes is work. Which means that "deep" themes that cover more than a single language either covers them poorly or not at all.
If you could apply a theme per scope instead of just per window.… You could create a really specialized theme for a language. You wouldn't have to make that theme work in every other language. Rare languages would actually look good. etc…
Don't get me wrong, i think all this isn't necessary ideal. I'm all for massaging the current scope system to make languages line up a lot better. But! Languages like html, css & yaml,etc... are kindof specialized. CSS doesn't have most of the scopes that programming languages use. HTML uses a lot of the same scopes as programming languages, but looks way ugly if you actually use them without modification. etc… It makes good sense to me to just focus on a theme for a language you know well and ignore the rest. It's way better than creating a single theme that is just a whole bunch of language specific themes stapled together.
If I could do that, I'd split Brilliance Black up into a dozen or so language specific themes, all inheriting from a main theme. Then I'd just have to add a new language specific theme for some new language instead of having to add it to that single massive theme.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
On Feb 12, 2007, at 1:33 PM, William D. Neumann wrote:
On Mon, 12 Feb 2007, subtleGradient / Thomas Aylott wrote:
I think TextMate should do the same thing. Start with a good deep base theme like Twilight and tweak the colors. Then save the recipe of how you tweaked that theme. The advantage is that when Twilight is updated, all of your tweaked themes based off of it are also updated since they're just recipes instead of actually different themes. And you can make really creative new versions of themes without having to do all the work of figuring out all the crazy edge cases and junk.
While this is a very good suggestion, it is certainly hindered by the fact that there is no comprehensive deep theme at the moment. E.g. the Brilliance themes are indeed well loaded with goodies, but they contain little in the way of coloring for OCaml constructs: nothing for modules, method calls, variant types, floating point numbers and operators, and so on -- these aren't even edge cases, they're core parts of the language, and I'm not sure their addition could be considered "tweaking". Now, I do 90% of my coding in OCaml, so this is what I've noticed, but I'd guess that there are other less-common languages in the bundles that are similarly unsupported by these deep themes.
This is, of course, fully understandible. If you don't code in OCaml, how the heck are you going to know what bits to add and highlight. That's why I haven't added anything for, say, HTML or CSS to any of my themes, because I touch a CSS file maybe four times a year. I wouldn't know what's missing in the theme...
So, what am I saying here? I suppose it's that if this idea of starting with a deep theme and tweaking is to get off the ground, we should probably put together an actual deep theme that has better coverage. Or something along those lines. Now, I'd be happy to add my bits to some reference theme that the other, existing themes can be retrofitted to match. I'm just wondering what the best way to do this is -- should we use one of the Brilliance themes and add to it (a Brilliance Reference if you will)? Or is there a better way? Does anyone have any good suggestions here?
William D. Neumann
"There's just so many extra children, we could just feed the children to these tigers. We don't need them, we're not doing anything with them.
Tigers are noble and sleek; children are loud and messy."
-- Neko CaseLife is unfair. Kill yourself or get over it. -- Black Box Recorder
That is exactly my point. We need a single theme that works in all languages and then multiple style version of that theme.
The original intent of Brilliance Black was to be a theme that looked good in every language. It is now my goal to make Brilliance Black a deep base theme and to make multiple stylistic versions of it. Maybe I'll make a real Brilliance Reference theme too and then make brilliance black the first version of that theme.
Give me a few reference OCAML files and I'll do my best to make it look good with Brilliance Black. I have no clue what OCAML is at this point.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
On Feb 12, 2007, at 12:33 PM, William D. Neumann wrote:
While this is a very good suggestion, it is certainly hindered by the fact that there is no comprehensive deep theme at the moment. E.g. the Brilliance themes are indeed well loaded with goodies, but they contain little in the way of coloring for OCaml constructs: nothing for modules, method calls, variant types, floating point numbers and operators, and so on -- these aren't even edge cases, they're core parts of the language, and I'm not sure their addition could be considered "tweaking". Now, I do 90% of my coding in OCaml, so this is what I've noticed, but I'd guess that there are other less-common languages in the bundles that are similarly unsupported by these deep themes.
::Glances over at Brilliance Black::
It has like over 150 rules, you want to add more and make it a template for new themes? Are you trying to scare off the competition? ;) If we seriously recommend to people that to make a theme they need to edit a list that long you'd never get any new themes.
Don't misunderstand me I'm not trying to belittle the work Subtle has done, I think the time taken to make the theme work in so many languages is commendable, but to say you need to have that huge a theme before it can work well… that's kinda scary no?
On Feb 12, 2007, at 10:44 AM, subtleGradient / Thomas Aylott wrote:
A major goal of all the scoping standardizationstuff we do in the syntaxes is to make it really easy so make a single theme that can be used for any language. Unfortunately, the reality is that languages are really complex and it takes work to make a theme look good in more than a few languages. And then more work to keep that theme looking good as the languages syntaxes are updated and improved.
I've got to disagree here, I think now that we have standardized scopes it should definitely be possible. Perhaps you can make a 'perfect' theme for a language sure, but I think this is the wrong approach. The whole concept in TextMate has been to make this generic whenever possible to allow reuse. The language grammars are a good example of this. Sure there are a few things you can't do quite right in some languages, but in the long run we're better off with a generic format than lots of special rules thought up for specific languages.
There are exceptions to this, I think some groups of languages take special handling. Markup languages can need special rules for instance, and I think regular expressions as a whole can use a lot of special cases. But I don't think any language is by itself unique enough to need it's own rules for the most part. My intent is to make Twilight much better than it is now while lessening the special rules it has, I don't think I'll have many problems doing so. (Of course we'll see when I get further along. ;)
The advantage of doing a version of an existing deep theme is that you get a new style without having to do all the coding of the random edge cases. It looks pretty without losing any theme-based functionality.
I agree here, re-using a theme is massively helpful. It's the main reason a light version of Twilight doesn't exist, I don't want to keep them in sync until I'm happy with Twilight.
Have you ever user ShapeShifter? There are all these OS themes that you can use to change the look of the chrome on all the windows and dock and whatever else on your system. There's also a new tool you can use to make a tweaked version of an existing theme. You can apply core image tweaks to all of the images in the theme and save out a tweaked version of a theme.
I think there are three kinds of theme editors…
1. Minor editors: The person who edits just the few things they don't like, or adds a rule or two. 2. Theme recyclers: The person that takes another theme and leaves the structure wholly the same, changing only the colors/weight/etc. 3. From scratch.
For the minor editors I think some way similar to the bundle editor would be nice, so they don't lose other updates to the theme as they add/change the few things.
For the theme recyclers I could foresee some help, because keeping a theme in sync once you've branched it off is near impossible. I'd be nice if there was a way to have a master 'structure' file of some sort and any changes make to it would apply to the 'child themes' below, so we could keep the versions in sync. The problem I see with this is how to really make it all work and worst of all it's ui.
Ideally I think most people don't understand enough about the way various scopes interact to make a theme structure that works well except for the languages they use. So I think good templates are going to be important. Being able to make a theme from a template and then it receive structural changes later on would be quite sweet.
-
David Powers -
Michael Sheets -
subtleGradient / Thomas Aylott -
Thomas Aylott (subtleGradient)
-
William D. Neumann