4 ms·
Solarized color theme for Emacs 24
- michaelty 15y agoThe author also has Zenburn for Emacs 24. https://github.com/bbatsov/zenburn-emacs https://github.com/bbatsov/zenburn-emacs
- jpeterson 15y agoCan someone fill me in on why the regular solarized theme is not proper for Emacs 24? I've been using it for a few weeks, and it seems to work fine.
- wx77 15y agoI may be wrong but I believe it is because emacs now supports color theming without color-theme.el
- jrockway 15y agoEmacs color theming is an epic failure. There are too many modes that define their own colors, and the colors are not defined in any semantic way: they are simply colors that the author of the mode likes. That means that if you switch to a color theme like Solarized (or anything), some mode is going to have fucked up and unusable colors. Most of the time, things appear to work because everyone writes their font-lock modes in terms of meaningful colors, like "font-lock-builtin-face", but as soon as you venture outside of what font-lock provides, you're fucked if the color theme author doesn't use the modes you do. And since pretty much everyone uses different modes, color themes simply do not work. (I usually define my colors in terms of the font-lock faces to make sure that color themes work. But sometimes you have more information than a normal font-lock mode does, and then you have to manually select a new color. Hashes and arrays in cperl-mode are a specific example.) I also have some specific complaints about how the mode is written. Why is the color theme definer burdened with quasiquoting and color classes when a macro could make it possible to sanely extend the color theme without extra work? Something like: (define-color-theme solarized :base-colors-for light foo "#abcdef" bar "#fedcba" baz "#coffee" :mode-colors-for light background foo font-lock-builtin-face bar ...) As it stands, there is too much boilerplate and I would never be motivated enough to type everything needed to get the modes I use to work. Also, while I'm whining, why do people name their own fucked-up Emacs config things like "Emacs Prelude" instead of "my .emacs"? I agree that many of Emacs' defaults are stupid, but the solution is education, not a random .emacs that invalidates the Emacs documentation. When you change all the defaults, you'd better provide a new user manual, or people are just going to be confused. Sorry if this sounds harsh, but I got my wisdom teeth out yesterday and the painkillers are not doing much for me. :)
- technomancy 15y ago> Emacs color theming is an epic failure. That's why they threw out color-theme.el and reimplemented it from scratch in Emacs 24.
- jrockway 15y agoI haven't paid much attention to emacs-devel in recent months, but it doesn't look like deftheme has solved the problem of "too many mode authors setting their own colors". None of the linked themes appear to, for example, support rcirc. They support erc instead. A good example of the color proliferation problem is egg; it defines its own diff-added and diff-removed colors, which means if you've already fixed the colors for diff-mode, you have to do the same fix again for egg. So while, yes, color-theme didn't actually work as documented and the new stuff does, it's still practically impossible to try out various color themes.
- travisjeffery 15y agoWhy do you care what people name their Emacs config? One advantage right of the bat with a unique name is for referencing a configuration to new users to get up and running on Emacs quickly, instead of: 1: "Hey try this configuration until you're up to writing your own." 2: "Which one?" 1: "my .emacs" Rather than being able to Google: "Emacs Prelude" or "Emacs Starter Kit". As for educating new users, most people simply don't have the time or regard to build an Emacs configuration that they can be productive with right away from day 1. There's just too much to know all at once. Emacs configurations such as the Emacs Starter Kit and Prelude provide a centralized place for new users to learn. I see how configurations can do anything to increase the confusion they already have. They either don't care and just like how it works better than without the configuration, or they're interested and use THE manual by doing the C-h's, or browsing the configurations files learning new things incrementally, when they feel like it.
- jrockway 15y agoI care because I think it's a stupid idea and it's confusing to new users. Yes, anything Emacs is going to be confusing to new users. But having to debug some third-party "prelude" or "starter kit" that they read about on Reddit is just going to complicate learning Emacs. They will spend their time fighting with colors and keybindings instead of learning how to explore Emacs. It trains users to depend on other people to set their preferences, when the whole point of Emacs is that everything is discoverable and customizable. (I don't mind including non-core modes like auctex or haskell-mode, but would prefer that they were bundled and maintained in core.) Ultimately, life-long Emacs users have their own set of defaults that they have learned to like over the years. This is due to muscle memory and habit rather than any objective good. I recently killed two thirds of my own .emacs and it removed many long-standing annoyances. Emacs improves, hacks on top of hacks called config files don't. If all sets of possible configurations are equally bad, why not stick to the config file that doesn't require an actual file, and then let users M-x customize as appropriate? You may not like customize, but it's pretty nice for people that are new to Emacs. (And, actually, I try to do everything via customize because I'd rather let the computer maintain my config file.)
- mad44 15y agoMy favorite color theme on MBA is infodoc. On MBP my fave was marine.