Live data from Hacker News

Vim Colors

vimcolors.com

71–80 of 110 posts

Re: Vim Colors

#71
post #30

Earlier quoted context omitted.

Yes, neovim has an integrated terminal.

Running a terminal inside an editor inside a terminal... What is the use case for this that tmux/screen does not solve?

For me tmux requires too much configuration up-front. It's just not worth my time.

Re: Vim Colors

#72

This is great. I'd like the ability to live-filter over and above the ability to search. Also, more than 10 hits per page. It'd be wonderful to have some sort of voting or popularity metric to sort by. And, for pie-in-the-sky features it would be nice to have filters based upon contrast / hues / etc. other than just "dark" and "light."

Thanks, all great suggestions.

I've been wanting live-filter for a while but decided to launch with basic filtering.

Once I'm happy with core features I'll start looking at stuff like rating, favouriting, etc.

(I meant to post this comment earlier but it was throttling me.)

Re: Vim Colors

#73

Earlier quoted context omitted.

Nothing magical about it, but yes it will. Or rather, vim doesn't need to change its color scheme in order to be displayed in a completely different set of colors, which is what he's talking about. If you change the color mapping of your terminal and vim doesn't immediately reflect that, then your terminal is not applying those changes to that window/tab.

Fair enough, I just tried it out and it indeed works, I was a bit ignorant ;). I'll see if this will work out for me. Don't know what any pitfalls could be by setting the color scheme in the terminal. At least it's annoying if you use different terminals on different systems, you'll have to configure them separately, you can't put it in your dotfiles repos or something. Thanks anyway, will look into it!

I keep my terminal's settings in my dotfiles repo... It opens by default in what I've set as the default. I can change on a case by case basis if I want.

Re: Vim Colors

#74

I'm probably in the minority, but I've always found that anything other than constant-coloured text on a constant-coloured background with a high contrast to be more distracting than helpful. It appears I'm not the only one: http://www.linusakesson.net/programming/syntaxhighlighting/

Heh, I'd actually love to read syntax highlighted English :) To each their own.

Re: Vim Colors

#75
Can we do more than 10 per page? I hate having to click next, next, next in between scrolling. If I could just flick the scroll wheel and let my eyes pick out the ones I like it would be so much easier!

Re: Vim Colors

#76
post #75

Can we do more than 10 per page? I hate having to click next, next, next in between scrolling. If I could just flick the scroll wheel and let my eyes pick out the ones I like it would be so much easier!

I'll look into infinite scroll, thanks for the suggestion.

Re: Vim Colors

#77

I wish I could choose a language to preview the schemes with. My biggest gripe with many of these themes is that is looks great in some languages and terrible for everything else.

You can actually do quite a bit to help with that by switching around which colors are assigned to which syntax rules, if you're willing to dive into the code.

Re: Vim Colors

#78

I just use Base16 ( https://github.com/chriskempson/base16 ), so I have the same colorscheme in all relevant apps. It can emulate almost all of the popular schemes, plus has a lot of others.

base16 is so awesome that I ended up coding whole day on a idle sunday because I wanted to keep looking at the beauty of my screen.

Re: Vim Colors

#79

I'm probably in the minority, but I've always found that anything other than constant-coloured text on a constant-coloured background with a high contrast to be more distracting than helpful. It appears I'm not the only one: http://www.linusakesson.net/programming/syntaxhighlighting/

I find syntax highlighting is particularly useful in tightly-packed constructs. Consider this function returning a string interpolation in CoffeeScript:

     (d) -> "id-#{d[@id]}"
In my default color scheme, the #{} (string interpolation), @ (this pointer), and () (function parameter delimiter) are muted, since they're syntactically critical but not helpful to my understanding.

The "id-" is more subtle than code but more visible than the muted syntax, because I only sometimes care about the string literal, and the array indexer [] is about the same.

The identifiers d and id are the regular typeface, since those are the code items.

The -> which creates a closure is brightest, because creating a closure is a relatively heavy operation and it's useful to be able to pick them out at a glance.

I understand that you CAN read it without highlighting, but the signal-to-noise ratio is much worse. In particular, the hash mark and atpersand stand out much too prominently.

The linked article is concerned about breaking up the "natural flow of the text", but I think that misses a critical observation. While prose text flows from left to right, line by line, that's not how code flows. Code's flow is in its structure.

Post reply on HN