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

ruby-talk
21

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.

···

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

Alder Green 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.

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?

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham

22

Michal Suchanek wrote:

Alder Green 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.

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

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.

···

On 9/2/06, Paul Lutus <nospam@nosite.zzz> wrote:

23

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

24

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!

25

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

···

On Sun, Sep 03, 2006 at 02:47:39AM +0900, M. Edward (Ed) Borasky wrote:

26

s/with the shell/much at all/

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

···

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

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.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."

27

Robin Stocker wrote:

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!

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.

28

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

···

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

On Sun, Sep 03, 2006 at 08:30:59AM +0900, Gregory Seidman wrote:
> 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.

s/with the shell/much at all/

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

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors. A program
is what you give the audience." - Larry Wall

29

Chad Perrin 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.

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.

···

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

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

On Sun, Sep 03, 2006 at 02:47:39AM +0900, M. Edward (Ed) Borasky wrote:

30

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

···

On Sun, Sep 03, 2006 at 09:27:05AM +0900, M. Edward (Ed) Borasky wrote: