A better syntax highlighting color scheme for Ruby code on Vim?

A

Alder Green

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

Alder Green

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.
2. 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 :)
 
P

Piers Harding

--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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




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!
=20
Vim also has good syntax-highlighting support. Unfortunately, the
color scheme applied through the syntax highlighting sucks. It lumps
together too many elements:
=20
Methods, symbols, constants, class variables, instance variables,
global variables, block parameters, predefined constants and variables
--
=20
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.
=20
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.
=20
How do I get a nice color scheme that would do a better job of
visually differentiating the various Ruby-related syntactical
elements?
=20
--=20
-Alder

--=20
Home - http://www.piersharding.com
xmpp:p[email protected]


--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFE+V2gGETamPT/o4ARAomqAKDdgFg1ZOp2dFtYPw4o3sJhERkA1ACfaEr1
suaUo76IfFSyYTRtv2X6Ejg=
=AVpA
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--
 
W

William Crawford

Alder said:
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?
 
M

Michal Suchanek

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?

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
 
J

James Britt

M

Michal Suchanek

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.

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
 
M

M. Edward (Ed) Borasky

Michal said:
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).


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

Chad Perrin

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

John Lam

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
 
J

John Gabriele

[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][1] 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

[1]: http://www.simisen.com/jmg/notes/vim.html

---John
 
R

Robin Stocker

M. Edward (Ed) Borasky said:
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!
 
G

Gregory Seidman

]
} 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
 
C

Chad Perrin

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

s/with the shell/much at all/

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

Chad Perrin

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

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

M. Edward (Ed) Borasky

Chad said:
]
} 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.
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.
 
M

M. Edward (Ed) Borasky

Robin said:
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!
Yeah ... that is better. Still, when I edit a Ruby file, the comments
are in "cyan", the "def" keyword is in a "pale blue" that almost looks
like cyan, and the method name after the "def" is the same color as the
comments, but brighter (boldface?). It's as though the coloring was
designed not so much to flag certain syntactic elements as it was to
provide contrasting tokens.
 
G

Gregory Seidman

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

I don't think there will ever be a good, coherent message about what Debian
"stable" means. From my perspective, stable is something to run on an
internet-facing server that doesn't need to be behind a hardware firewall.
I use a mix of testing and unstable on all of my Debian machines.

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

Whatever floats your boat. I've had good success with Java on Debian, even
using IBM's Java on PowerPC. It was a pain for a while, I'll grant you, but
it's gotten better. Eventually someone scratched that itch and created
java-package, which takes the various downloadable Java installs and turns
them into .deb files.

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

Many are, true. As I said, it took a while but Debian folks realized that,
too. I've installed, for example, Azureus with apt-get. It just kind of
works now, like all the other packages always did.

Oh, and just to dig at Gentoo for kicks (and all in good fun), have you
seen http://www.funroll-loops.org/?

--Greg
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top