Adapt to current colorscheme
Closed this issue · 11 comments
It'd be nice if the plugin can adapt to the currently active colorscheme like e.g. airline without any custom modification from the user.
I didn't thought of that, but it sounds like a great default. I would leave an option to customize the highlighting (g:lengthmatters_colors) but I'll surely look into it! Thanks.
(obviously, PRs are more than welcome 👍 )
I wish I have some knowledge of vimscript to send you a PR but I haven't :)
The custom hightlighter should still be available.
I'm looking at this right now and what (as I'm understanding at least) plugins like airline (and lightline, for example) do is simply define a bunch of colorschemes to match existing colorschemes in order to have good-looking colors.
I'm guessing a good idea could be to highlight OverLength (or whatever the match name) like some other group (I'm thinking of Comment, SignColumn).
Problem is, however I do it I feel I'm going to ruin someone's colorscheme; even airline screws up my colorschemes when they're not the most used ones (solarized, tomorrow, monokai, mustang).
As soon as I'll have some idea on how to do this I'll try.
Along these lines, right now I have
highlight link OverLength CursorColumn
in my vimrc after loading the plugin, but I this link doesn't take effect until I re-source my vimrc. Any idea what might be causing this?
@justmytwospence Yep, I have :) this is a bug and I'm trying to come up with a clever way to solve it. Basically, the highlight has to be done on every colorscheme change (with the ColorScheme autocmd event) so your command gets overridden. I'll have a deeper look tomorrow, thanks for reporting!
@justmytwospence I hacked a solution to this problem in dc27b6d. Now there are two functions available that deal with highlighting, so that what you describe shouldn't happen anymore.
In order for this to work, update the plugin (:PluginUpdate, git pull with Pathogen, whatever you use to manage your plugins) and change the highlight line you posted to:
call lengthmatters#highlight_link_to('CursorColumn')I'm sorry that there was no "more elegant" solution than to recur to custom functions, but highlighting is not all flowers and roses in vim (e.g. I found no easy way of backing up/restoring the highlighting of a given group). With custom functions it becomes super easy to have controlo of these things.
Let me know if this fixed your problem! 👍
Thanks for looking into it. I get the following errors when I make that change:
Error detected while processing function lengthmatters#highlight_link_to:
line 1:
E121: Undefined variable: g:lengthmatters_match_name
E15: Invalid expression: 'highlight link ' . g:lengthmatters_match_name . ' ' . a:group
line 5:
E492: Not an editor command: LengthmattersReload
Adding let g:lengthmatters_match_name='OverLength' to my vimrc fixes the first one but not the LengthmattersReload one. I can confirm that LengthmattersReload can be run manually, however.
@justmytwospence I'm really really sorry, I didn't really have much time to look into it and hacked something that seemed to work. Well obviously it didn't 😞
I pushed an update a few seconds ago. Sorry to put you into so much trouble! Let me know if that works.
PS thanks for your time!
Works great! Thanks!
@Tbass I'm resurrecting this! In 0b6837e, I changed the default highlighting of both GUI vim and terminal vim to reverse. It should look better with about every colorscheme, even if it's "problematic" since different highlightings have different reverse colors.
For example, if you're editing a Ruby file and write something like this:
... [1, 2, 3] + ['a string']over the 80th column, pretty much eveything (strings, numbers, operators) will be highlighted differently. The alternative is messing with some default colors in order to make them always look good, but the downside is losing the syntax highlighting (which differentiates for example strings and numbers) over the 80th column.
What do you think?
@Tbass After about a week of daily usage, I changed the default highlighting again! The default highlighting (strings vs. numbers vs. comments and so on) is lost over the 80th column but it looks much better and cleaner. It also should adapt better to most colorschemes.
I'm closing this for now, feel free to reopen it.