I have customized a few things from the default Emacs color scheme, most notably getting rid of the awful red foreground for comments (ugh!) in favour of a less intrusive grey.
The other notable change that I made was the addition of syntax highlighting for symbols, including operators, parenthesis, brackets, curly braces, etc., because I believe it really helps read the code better. Emacs in fact does not natively support highlighting of symbols, but since it is highly extensible I was able to add support for it.
Anyway, my emacs color scheme for gedit can be found here. Playing a bit with gedit with this color scheme, once again I tried to get the feeling on whether I could ever switch from emacs to gedit, and the answer is sadly still no. Here's some of the reasons:
- Gedit still does not have the notion of indentation offset, and only has tab width. In emacs, you can have tab width set to 8, but if you set indentation offset to 4 then pressing tab indents with 4 spaces, not one tab. In gedit you have to change the tab width to 4, which has disastrous side effects on source files that are using real tab characters for indentation. This is a really serious problem IMHO.
- Gedit is generally not very smart about indentation. Emacs usually knows how to indent a line based on syntax analysis of the surrounding context. I guess I can leave without it, but it would be really nice to have. But, yes, I realize this is very hard to implement for only a little gain.
- Gtk's default cursor is very thin and easy to lose track of it. In contrast, Emacs' cursor is big and blocky, but at least you never lose track of it. Fortunately I was able to kind of work around with a gtkrc style file, although it's not perfect.
- I already mentioned the symbols/operators problem. Gedit does not natively support operators in most language files; at least not C/C++/Python, which is the ones I care about. I'm not sure if I can fix this easily. I can define color schemes, but I wonder if I can customize language definitions, add new information to them in a inheritance style?
- The modelines plugin needs more work; it keeps ignoring many of the modelines on my files.
2 comments:
Hey Gustavo, just got back from some days of vacation. Sorry for the delay moderating your comment on my blog.
By the way, why aren't you on planet gnome?
The color scheme looks pretty cool, the black background on the line numbers looks a bit weird... is that intentional or just a leftover of my dark tango example? Note that a better startting point is probably the 'classic' theme shipped with gtksourceview since you probably also still need to tweak some language specific colors.
That said, can you add your scheme to http://live.gnome.org/GtkSourceView/StyleSchemes ?
Let's now get to your complaints :)
(by the way, bugzilla is your friend! It's hard to track bugs on blog posts!)
For the indentation vs tab-width, you will be happy to know about bug http://bugzilla.gnome.org/show_bug.cgi?id=352847 and the fact that it has a patch attached and I definately want to get that in for 2.20 :)
Smart indenters... it's quite an hard problem, especially since you have to put in place a system that it is extensible enough to have indenters for all the languages we support... It's been discussed many times and we have some ideas about it... one day it will happen or at least so I hope.
Cursor drawing (as you surely know) it's a gtk thing, so little we ca do on gedit side.
For lang files: you can override them by placing them in ~, but what you should really do is to file bugs/patches about things that you would like to see highlighted, most of our .lang files do not take properly advantage yet of all the new syntax engine power.
Ditto for modelines: file bugs dude! :)
forgot to mention... if you find tracking the cursor hard, did you try enabling "current line highlighting" in the prefs? I find it a really pleasant way to easily locate the cursor position
Post a Comment