A better syntax highlighting color scheme for Ruby code on V

Ruby
1

I’ve been migrating to Vim recently. It has impressive Ruby/Rails
support: indentation, intellisense for Ruby and Rails objects, a lot
of shortcuts for fast editing of Rails projects… you can even script
Vim in Ruby!

Vim also has good syntax-highlighting support. Unfortunately, the
color scheme applied through the syntax highlighting sucks. It lumps
together too many elements:

Methods, symbols, constants, class variables, instance variables,
global variables, block parameters, predefined constants and variables

All those are colored blue. Which completely defeats the purpose of
syntax-highlighting, to help you visually differentiate between the
various syntactical elements of the code.

Apparently, all the above (and several others) are differentiated
by the Vim Ruby syntax parser. However, the default color scheme
colors them all the same. So the problem is with the color scheme.

How do I get a nice color scheme that would do a better job of
visually differentiating the various Ruby-related syntactical
elements?

2

On 9/2/06, Paul L. [email protected] wrote:

Options:

  1. Get the Vim source and edit the syntax coloring engine datafiles.

Actually, all you need it to redefine the color definitions for each
element. No need to delve into the Vim source; it’s a pretty common
case of user customization.

  1. Change editors.

Thanks for the suggestion, but I like Vim very much. The Ruby support
is very impressive - in fact it’s the best I’ve seen so far. The
editor itself is rich and excellent, with a huge community and a vast
selection of functionality-extending scripts.

Now all I need it a few lines of decent syntax highlighting
definitions. Would take me an hour or two to do myself, but I’m sure
some hardcore Vim/Ruby fan had already done a much better job :slight_smile:

3

Alder G. wrote:

/ …

How do I get a nice color scheme that would do a better job of
visually differentiating the various Ruby-related syntactical
elements?

Options:

  1. Get the Vim source and edit the syntax coloring engine datafiles.

  2. Change editors. Kate (and KWrite) on Linux have acceptable Ruby
    syntax
    coloring. See this page for an example:

(colors exported from KWrite)

Or are these colors also too much the same for your requirements?

4

Here’s an example of what I’m looking for:

http://www.users.on.net/~markwoodward/vim/linVim/ftplugin/ruby_cols.vim

I can’t use this particular one as it is aimed at people who use black
text over white bg, whereas I use white on black.

But I’m sure there are several people here who use Vim in
light-on-dark mode to edit Ruby files, and have defined an apropriate
color set for that purpose.

-Alder

5

Alder G. wrote:

Here’s an example of what I’m looking for:

http://www.users.on.net/~markwoodward/vim/linVim/ftplugin/ruby_cols.vim

I can’t use this particular one as it is aimed at people who use black
text over white bg, whereas I use white on black.

But I’m sure there are several people here who use Vim in
light-on-dark mode to edit Ruby files, and have defined an apropriate
color set for that purpose.

-Alder

Wait, what are you looking for then? Someone who has done the work for
you and knew your personal tastes? Someone to take the time to
customize that for you?

Why not just edit it, since you already know how?

6

I think there are set of schemes in your directory version of
/usr/share/vim/vim64/colors which you can set with:
colorscheme <filename without .vim>

Also - if you like vim - you may even like it even more if you haven’t
allready disovered mru and Tlist with ctags?

Cheers,

Piers H…

7

Alder G. wrote:

I’ve been migrating to Vim recently…

How do I get a nice color scheme that would do a better job of
visually differentiating the various Ruby-related syntactical
elements?

You can just mess with the colour definitions. I use a
theme slightly modified from zenburn.vim:

http://pastie.caboo.se/11369

Looks like this:

http://img482.imageshack.us/img482/5025/zenbruezq7.png

8

Alder G. wrote:

Here’s an example of what I’m looking for:

http://www.users.on.net/~markwoodward/vim/linVim/ftplugin/ruby_cols.vim

I can’t use this particular one as it is aimed at people who use black
text over white bg, whereas I use white on black.

Yipes. Oh well, to each his own. I gave up on white text on black
background
years ago when I discovered it caused me eyestrain and headaches during
all-day programming sessions.

It should be pointed out that nearly all modern text colors presume a
white
background, now that that is the norm.

9

Alder G. wrote:

How do I get a nice color scheme that would do a better job of
visually differentiating the various Ruby-related syntactical
elements?

See if this helps:

http://www.cs.cmu.edu/~maverick/VimColorSchemeTest/index-java.html

–
James B.

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

10

On 9/2/06, Alder G. [email protected] wrote:

global variables, block parameters, predefined constants and variables
How do I get a nice color scheme that would do a better job of
visually differentiating the various Ruby-related syntactical
elements?

Hello

I use the default vim syntax highlighting which links all language
specific elements to the generic elements (ie it would link
rubyComment to comment or somesuch), and wit darkgreen background the
vim theme elflord works quite well for me. It could use some tweaking
but I am too lazy to do that.

Thanks

Michal

11

On 9/2/06, Paul L. [email protected] wrote:

years ago when I discovered it caused me eyestrain and headaches during
all-day programming sessions.

I guess white on black used to be very useful on the old screens that
had low contrast and refresh rate. Any background other than black
causes more flickering, any foreground other than white causes the
text to be harder to read because it is too dim.

But I find it much better to use dark background with lighter text.
Black is not good, I think it causes me to lose focus because there is
virtually nothing visible on most of the screen (such state also did
not exist on old screens).

It should be pointed out that nearly all modern text colors presume a white
background, now that that is the norm.

I suspect this came from word processing where black on white
resembles paper. But for screens that actually emit light I like dark
backgrounds better. I wonder how reflective screens will change this.

Thanks

Michal

12

Michal S. wrote:

Yipes. Oh well, to each his own. I gave up on white text on black
Black is not good, I think it causes me to lose focus because there is
backgrounds better. I wonder how reflective screens will change this.

Thanks

Michal

I’ve found the typical “xterm/konsole” window on Linux systems is often
unreadable with a white background and the typical Linux text color
scheme. The pastel backgrounds are quite a bit better than white, but it
really works best for me on a black background, so that’s what I use.

One thing I do find myself changing often is when I’m editing a (Gentoo)
config file in Vim. The comments tend to be user instructions on how to
set the parameters. On a black background, Vim colors the comments a
dark-ish blue that’s almost unreadable, so I go “:syn off” to read them.

Actually, as long as I’ve been programming, I never found language
syntax coloring all that useful. It’s certainly not necessary.

13

The impression I get is that he just doesn’t want to have to reinvent
the wheel if someone else has already done a good job of it and is
willing to share. Fiddling and fine-tuning a color scheme can be kind
of a pain in the butt sometimes, regardless of the application and the
configuration mechanism.

Here’s what I use, and it’s based off of the TextMate Vibrant Ink theme:

highlight Normal guifg=White guibg=Black
highlight Cursor guifg=Black guibg=Yellow
highlight Keyword guifg=#FF6600
highlight Define guifg=#FF6600
highlight Comment guifg=#9933CC
highlight Type guifg=White gui=NONE
highlight rubySymbol guifg=#339999 gui=NONE
highlight Identifier guifg=White gui=NONE
highlight rubyStringDelimiter guifg=#66FF00
highlight rubyInterpolation guifg=White
highlight rubyPseudoVariable guifg=#339999
highlight Constant guifg=#FFEE98
highlight Function guifg=#FFCC00 gui=NONE
highlight Include guifg=#FFCC00 gui=NONE
highlight Statement guifg=#FF6600 gui=NONE
highlight String guifg=#66FF00
highlight Search guibg=White

14

On 9/2/06, Alder G. [email protected] wrote:

[snip]

How do I get a nice color scheme that would do a better job of
visually differentiating the various Ruby-related syntactical
elements?

I assume you’re using gvim (which is GTK-based, rather than plain vim).

As James B. recommended:
http://www.cs.cmu.edu/~maverick/VimColorSchemeTest/

“zenburn” is very nice if you like dark backgrounds.

As the install instructions indicate, to install colorschemes, create
a ~/.vim/colors directory and put the .vim files in there. Then add

colorscheme zenburn

to your ~/.vimrc file. Finally, restart gvim.

I don’t use vim anymore (switched to Emacs recently), but my
notes indicate that I preferred zenburn with the following change:

hi LineNr guifg=#4f4f4f guibg=#3a3a3a
hi Normal guifg=#dcdccc guibg=#4f4f4f
hi Statement guifg=#e3ceab guibg=#4f4f4f gui=none

—John

15

M. Edward (Ed) Borasky wrote:

One thing I do find myself changing often is when I’m editing a (Gentoo)
config file in Vim. The comments tend to be user instructions on how to
set the parameters. On a black background, Vim colors the comments a
dark-ish blue that’s almost unreadable, so I go “:syn off” to read them.

That’s because Vim assumes that there is a bright background. I also had
the very same problem until I discovered this option:

set background=dark

That makes the comments a bright blue, something like cyan. Try it!

16

On Sat, Sep 02, 2006 at 07:54:10PM +0900, William C. wrote:

color set for that purpose.

Wait, what are you looking for then? Someone who has done the work for
you and knew your personal tastes? Someone to take the time to
customize that for you?

Why not just edit it, since you already know how?

The impression I get is that he just doesn’t want to have to reinvent
the wheel if someone else has already done a good job of it and is
willing to share. Fiddling and fine-tuning a color scheme can be kind
of a pain in the butt sometimes, regardless of the application and the
configuration mechanism.

17

On Sun, Sep 03, 2006 at 02:47:39AM +0900, M. Edward (Ed) Borasky wrote:
[…]
} I’ve found the typical “xterm/konsole” window on Linux systems is
often
} unreadable with a white background and the typical Linux text color
} scheme. The pastel backgrounds are quite a bit better than white, but
it
} really works best for me on a black background, so that’s what I use.

s/Linux/some Linux distributions/

Thankfully, Debian does not seem to do foolish things with the shell
prompt, as many others do.

} One thing I do find myself changing often is when I’m editing a
(Gentoo)
} config file in Vim. The comments tend to be user instructions on how
to
} set the parameters. On a black background, Vim colors the comments a
} dark-ish blue that’s almost unreadable, so I go “:syn off” to read
them.

Someone already pointed out that you need to :set bg=dark

} Actually, as long as I’ve been programming, I never found language
} syntax coloring all that useful. It’s certainly not necessary.

For a good long time I thought the proponents of syntax coloring were
just
wimps leaning on a crutch, or the sorts of fools who used Enlightenment
(well before GNOME or KDE, there was the godawful eyecandy known as
Enlightenment).

Then I decided to try it for myself to see what all the fuss was about.
Yes, I can still program effectively in plain black and white without so
much as an underline. For that matter, I could write code in ed if I had
to. Just as a visual editor is an improvement over a line editor like
ed,
syntax coloring is an improvement over plain visual editing.

Once you’ve used it long enough for the colors to be meaningful to you,
it’s faster and easier to read code. Comments can be closer to the code
they refer to since they don’t need as much whitespace to bring
attention
to them. Certain typos are easier to notice when they change the color
of
the word.

On a different note, I’ll mention that I use a light beige background
for
my shell and editor windows, but a nearly black background for reading
email. Why? It’s just more comfortable for me that way.

–Greg

18

On Sun, Sep 03, 2006 at 09:00:50AM +0900, Chad P. wrote:

Thankfully, Debian does not seem to do foolish things with the shell
prompt, as many others do.

s/with the shell/much at all/

Yea, verily, I’m a fan of Debian defaults in general.

Y’know, that would look much smarter if I remembered to include the word
“prompt” in the matching part of my substitution expression.

19

On Sun, Sep 03, 2006 at 08:30:59AM +0900, Gregory S. wrote:

prompt, as many others do.
s/with the shell/much at all/

Yea, verily, I’m a fan of Debian defaults in general.

20

Chad P. wrote:

Thankfully, Debian does not seem to do foolish things with the shell
prompt, as many others do.
s/with the shell/much at all/

Yea, verily, I’m a fan of Debian defaults in general.

Y’know, that would look much smarter if I remembered to include the word
“prompt” in the matching part of my substitution expression.

Curiously enough, when Red Hat dropped Red Hat 10 in favor of Fedora and
some expensive “enterprise” distros, I switched to Debian. I really
liked Debian, although it took them a long time to come out with “sarge”
as a stable product. And I really liked being able to bring up “dselect”
and be a kid in a candy store. Darn near anything I could use or wanted
to learn how to use was in there.

The fly in Debian’s ointment was their disdain for Java. A lot of the
things I wanted to run were written in Java. So I went looking around
for another distro and settled on Gentoo, about six months after
switching from Red Hat to Debian.

I don’t personally code in Java, nor do I hack on the open-source tools
I use that are written in Java. But in certain application areas
(workstation, not server, in my case) the really good packages are
written in Java.