-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardcoded Xterm defaults #1
Comments
...
Yes, this is very interesting. I have been content with the standard At first glance, I suppose what I will do is detect whether the user's Should they have perl support and your Term-ExtendedColor-Xresources Does that sound good to you?
Ah, this one is easier to answer. I did not come up with those names; Cheers, |
If you can come up with a working solution using Term::ExtendedColor::Xresources it'd be awesome. Otherwise you might be able to send the raw escape sequences to the underlying tty, however, I'm afraid there'll be a blocking problem. But I dont know much of viml or what it's capable of. On the subject; I saw you had done some work on rxvt-unicode; I recently added a repo that adds support for redefining all of them colors using X resources, if you want to try it out. Thanks for the link. Cheers |
If the match is executed based on the hard coded color (which should not be hard coded in the first place, mentioned in issue guns#1), a color code can have multiple matches if the hex code is used for multiple colors. This commit changes the matching as: ' \d+ #[0-9af]+', containing the xterm256 index of the color, so that the highlight class is independant from the used RGB code.
If the match is executed based on the hard coded color (which should not be hard coded in the first place, mentioned in issue #1), a color code can have multiple matches if the hex code is used for multiple colors. This commit changes the matching as: ' \d+ #[0-9af]+', containing the xterm256 index of the color, so that the highlight class is independant from the used RGB code.
Hello,
I just want to make you aware of the fact that the Xterm colors are not static.
You can change all of them, and since your script uses hardcoded values, it'll get them wrong if they're modified.
Now, I don't know if it's possible for vim to somehow query the underlying terminal and get response back in a sensible way.
There's escape sequences that ought to be used, but it's a bit tricky getting at the responses without blocking.
I've written a library [1] that provides two functions; set_xterm_color() for changing arbitary color indexes, and get_xterm_color() for getting at the values.
I've also written an application [2] that allows the user to manipulate the full colormap in interesting ways, as well as another simple application [3] that does nothing more but to give you the real color values for every color index back.
Perhaps looking at these might give some inspiration.
Furthermore, I was wondering if you'd allow me to use the Xorg color <=> Xterm color index mappings as listed here [4] in my Term::ExtendedColor [5] library? It's really, really hard to come up with meaningful names for all of these colors, and I'd like to offer your mappings as another way of getting at them.
You would of course be credited as appropriate.
1: https://github.com/trapd00r/Term-ExtendedColor-Xresources
2: https://github.com/trapd00r/colorcoke
3: https://github.com/trapd00r/rgbterm
4: http://vim.wikia.com/wiki/Xterm256_color_names_for_console_Vim
5: https://github.com/trapd00r/Term-ExtendedColor
The text was updated successfully, but these errors were encountered: