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?
Vim Colors
71–80 of 110 posts
Re: Vim Colors
#72This 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."
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
#73Earlier 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!
Re: Vim Colors
#74I'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/
Re: Vim Colors
#75Re: Vim Colors
#76Can 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
#77I 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.
Re: Vim Colors
#78I 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.
Re: Vim Colors
#79I'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/
(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.
Re: Vim Colors
#80Aside: The pages are also a good browser stress test with the large number of iframes.