Color problem on Windows 7 #612
Comments
|
@sergeevabc, can you confirm that this problem happens on Windows 7 but does not happen on Windows 10 or later? Also, can you provide a sample file that demonstrates the problem when input into less? That is, I'd like a test case that doesn't involve running bat or any other program besides less itself. cc @avih |
|
Less v668 itself looks different than v643 on Windows 7. $ less --helpv668 v643 Bat can color piped input and files and then it uses Less as a pager by default to output data page by page (screen by screen), rather than as a whole. Since Bat, executed without Less by means of Bat with Less v668 (source: about.md). Bat with Less v643 or without Less (the output is colored the same way).
I have no access to Windows 10 or later, but I'm happy with Windows 7 SP1 x64, so you can count on me when testing Less on this OS. |
That is expected. The default colors were changed at b931818 to the colors you see (after v643, before v644). This is more similar to the default colors on unix and linux, with the exception (compared to unix) that underline is cyan, and I don't recall how it looks on unix if the terminal doesn't support underline.
My guess is that both of these screenshots show broken colors, just in different ways. Can you please post a screenshot of how that file looks on win10, or linux or something which supports it correctly? The issue is that in 643 there was a bug which ended up with pretty much random colors when trying to display 256 colors in win7, and this bug was fixed, so now it shows only supported colors, and anything which can't be displayed correctly is now ignored correctly, instead of producing a random color. However, 8/16 colors should work fine, because this is what win7 console supports, so you need to choose a theme (in bat) of 8/16 colors. Maybe it's called "ansi"? I don't recall. I think they had some issues with that too, that some themes which are supposed to be 8 colors ended up using the 256 colors palette, but at least you should try that first. |
|
Yes, colors were changed after v643, so the difference in the help file is expected. I'm not yet sure about the difference in the about.md file. Can you run |
|
Re avih's comment, the escape sequence for the first line is |
Right, so it's not even 256 colors. It's true colors, which just can't work on win7, and we don't currently have auto-conversion to 8 colors. True colors also had this issue of random colors, it can't be displayed correctly, so "less" just gives up and it ends up with random thing. You need to change the bat theme to ansi or something else which is 8/16 colors, which is what your win7 console supports. |
Where did you get this from? Are you running bat with default config on some system? Which system? |
And this random color in this case is the "31" there. Instead of RGB of 253;151;31 which is red-ish thing, it doesn't know what to do with 253 and 151, but it takes the value of 31 - which is red in 8/16 colors, and displays it incorrectly, while in fact it was supposed to be the blue value in that RGB triplet. It was a bug which is fixed. Choose a theme which is appropriate for win7. |
Yeah, I ran bat on Linux under the script command and extracted it from the typescript file. |
Right, so if this is indeed the same output on win7 then it's exactly what I described that it only takes the 31 from that RGB triplet. But we don't know that for a fact, yet. It's possible that it uses a different theme on win7. Though still, the symptoms fit what I know changed, so my bet so far is that my initial assessment was correct and it's an inadequate theme for this system. |
|
By default I have access to 16 colors, right. But with the help of ConEmu (wrapper that extends Windows $ less.exe -R color-test-1.txt
$ bat.exe color-test-1.txt
|
|
Next time please mention from the beginning the factors which are involved in what you're doing. Anyway, show us the bug without conemu and with 16 color theme in bat, and then we can assess that. 643 was buggy with 256/true colors. It just didn't do the right thing, and it was broken in sort of random ways. Even if it looked like it worked, it didn't. Later versions improved and currently only 8/16 colors can work on win7, which is the correct thing to do on win7. |
I did. You know my OS and versions of Less in question, other tools are not used until required for troubleshooting. For example, I mentioned ConEmu just to let you know there is a way for me to see more than 16 colors. And it didn't help with Less.
I did. |
|
The color-test-1.txt file contains a full-color (24-bit color) sequence, the same as bat is using with the theme you're using. The Windows 7 terminal doesn't support that. This is the first I've heard of ConEmu, but it sounds like it doesn't support 24-bit color either, just 8-bit. The only way less could support 24-bit sequences is to do a full emulation, mapping each 24-bit color to the nearest 4-bit color. There has been some discussion about it, but that has never been supported. As avih explained, older versions of less do random things with such sequences, so it looks like there is color, but the color is random and unrelated to the expected color. Newer versions of less just ignore 24-bit sequences, which is .why you see grey. This is a better and more deterministic behavior. For your use case, you should use a bat theme that uses 4-bit color. |
That was a bug. This files has the true color sequence RGB of 253;151;31 . It should not have shown anything because it can't work on win7. Interpreting only some values of a sequence which is not decoded correctly is a bug. If this is what you want to argue then it is by design that less 688 doesn't try to display true colors on win7. Maybe it will work with conemu and |
|
I don't recall exactly what it did with 643, but it either interpreted it incorrectly like I described, or it decided to give up if any value is above 49 and passthrough this sequence to the terminal until the end of the line, which might work with conemu, but will break on an actual win7 console. https://github.com/gwsw/less/blob/0b5c1e4350dd31fae74c9400f7a282622c9a62b1/output.c#L208C11-L208C20 As I said, maybe Win7 console is not expected to be able to display more than 16 colors. It's true that conemu can display more than that, but less should first work correctly on normal win7 console. It might be possible to do something about it if conemu is detected, but personally I don't want to put time into it. |
You keep saying v643 does random things with colors, but somehow it makes me happier, because elements of the screen are not grey anymore, they begin to have distinctive features, which allows me to better navigate the text. v643. Good. Elements of diff comparison are grasped at once. v643. Not that good, but still we clearly see what was removed and added. v668. Gloomy leaden set of letters that drives you into depression. v668. v668. Markdown with ansi theme. v643. Markdown without ansi theme. Much better, right? Bug, you say. I love that bug actually.
Sounds like an intellectual challenge. We need a tech-savvy hero then. |
|
You are not listening and not reading what I said. I don't recall the exact details, but one of two things happened with 643:
Win7 terminal is not supposed to know to display colors from escape sequences. less has to translate the color sequences text into colors for the console. But if due to the second option it gave up and just printed that string to the console anyway, then it's not supposed to work on win, and it will display junk. But conemu does know how to render them, so it only worked in conemu, at least somewhat. For the 3rd time, try And yes, it is probably possible to detect conemu and do one thing for conemu and another thing for the rest of the normal win7 consoles.
You can bet it won't be me. This code is complex enough. We don't need to add more complexity to support 256/true colors on win7 in conemu. |
|
Just to sum up: less versions after less-643 ignore 24-bit color sequences when running on Windows versions prior to Windows 10. It would be a non-trivial effort to enhance less to translate such sequences to something that would work and look approximately correct on pre-10 systems. Currently more than 97% of Windows computers are running Windows 10 or later, so IMHO it does not seem worthwhile to invest the effort and assume the risks of making such a change to less. |
Have you ever wondered how such statistics are collected? I started questioning it as soon as I started traveling. The masses, except for a few corners of the Earth, live quite modestly to say the least. United Nations annual reports confirm that. For example, people from Brazilian favelas cannot keep up with California golden boys who are constantly upgrading their hardware and OS. This is hardly a progress if some software calculator can no longer add 2 plus 2 until a user has Windows 3000, DirectX12-capable GPU to drive it and a fan glowing in the colors of the rainbow flag. The core idea of programming is to provide tools that solve problems. The masses are looking at you, the developers, hoping to reduce the level of mundane suffering by means of widely accessible apps. Commercial devs like Microsoft care about profit, so they can call any app obsolete and unsafe at any moment in order to force people to buy another app, thereby exploiting artificial obsolescence strategy. But enthusiast devs can do better, because even these insignificant %s are thousands and thousands of suffering souls. Well, at least you're frank, thank you. P.S. Michael Jackson — They don't care about us [ |
This was a bug. It didn't work on win7. Due to this bug, it happened to work with conemu. Now this bug is fixed so that all the normal win7 users don't see junk anymore due to this bug. A side affect was that it no longer works with 256 colors with conemu. So now show me the percentage of win7 "less" users which use conemu. Because everyone else suffered due to this bug. And now only conemu users "suffer" that now only 16 colors work. No one is objecting to making it work for everyone perfectly, but software has limitations and complexities and tradeoffs to make and the resources are never enough to do everything which everyone wants. When you pay the bill and salaries, you get to decide the priorities. When people spend their free time on a project, then they decide what they want to work on and how to ensure the project makes the best progress forward. |
The pursuit of simplicity and minimalism in the world overloaded with information has led to a resurgence of interest in the console-based environment. ConEmu was conceived exactly with console-driven users in mind and today its repository has more than 8000 stars, which is impressive, given that GitHub is quite a nerdy place, not some Facebook group where ladies come to gossip. Obviously not all ConEmu followers use Windows 7, but the abundance of settings related to the screen output eloquently indicates that this app is trying to compensate for the lack of functions in older Windows.
Sure. For example, once upon a time, not long ago, enthusiasts gathered and conceived apps such as DOSBox and ScummVM, which allow users to run “obsolete” DOS apps and games on Gigahertz CPU with Gigabyte GPU. Why would they do that in the age of ultra-realistic graphics, smartphones and Chat GPT? What % of earthlings did they try for? Do you remember Monkey Island with EGA palette? Oh, not many colors, but we were so happy after text-based quests… And now once again we can feel the joy of touching simple but heartfelt stories, stories that break the silence not with the noise of fans, but with bursts of laughter and tears. Priceless cathartic experience. P.S. Game of Thrones author George RR Martin: “Why I still use DOS”. |
|
I don't see the percentage number of win7 users which would suffer from reverting it to how it was in 643. All the rest is really very nice. Nice colors tool. Do you need me to ask you a 5th time to try |
|
@avih, no one asks to revert anything. It's about making coloring on Windows 7 more enjoyable than it is now. And it seems possible together with (popular) ConEmu. Surely it is not a must-have feature, but rather a challenge. Like, say, codegolf. Or, for example, you wake up and decide to test existing formulas for converting color images to grayscale, only to find that even Photoshop isn't accurate enough… and then you make an app that does it right. Cool, huh? Defeating dragons and saving mankind is never easy, but that's how heroes stay in history. It's OK not to be a hero, but at least don't deprive us of hope. Less vs Less -rClick to see
v668, output is aligned, barely colored.
v668, output is a bit misaligned, but it has more colors.
v643, output is aligned and colored. |
|
Thanks. Is this a 256 color theme? or true color theme? Could you please try both? I don't know how -r is implemented, and how it calculates the line length, if at all. If that's not already the case, there might be an argument to make that it should behave as if it knows how the terminal would display it, which would only work correctly if the terminal actually displays it the way less guessed it would. I would assume this calculation would be similar or identical to how -R works, only without knowing for a fact how the terminal would actually render it. But I've not touched this code, so this is for @gwsw to assess how applicable it is, and whether it's worth doing.
It is possible and it's not a challenge. It's assessing the overall value it adds against the time and complexity and maintainability of this code, which is already more complex than we'd want it to be, and it's also about who decides how the developers spend their free time. |
ConEmu's magical checkboxLessv643
v668
v668 -r
|
|
To be honest, all of them look either broken or with something wrong. None of them looks to me like good and nice highlight of an MD file. Second, there's no need for -r with 8/16 colors. All it does it pass all the strings directly to the terminal, which conemu might know how to render, but normal win7 console wouldn't. But 8-16 colors should work fine when less translates them to windows colors, so -r can only break things, and the normal -R is a lot better in this case. Third, as I noted earlier, I vaguely recall some issue with one of the themes which I thought would be 16 colors but in practice wasn't. I don't recall whether it's "ansi". If you can provide a link to the theme file in the bat repository I could check it, but if you know it's correct 16 colors then no need. Either way, IMO either -r is improved for everyone, if indeed there's something to improve and it's viable, rather than spending any more time which won't help anyone other than win7 users with conemu, or it is what it is, and you can stick to 643 if you prefer it, or use 16 colors theme with newer less. I don't want personally to spend time on adding support for this slice of users because I think it's small enough to not be of general concern. Even win7 at all is a very small slice, but I did spend time to make that better, eventhough I don't use win7 personally. I just have better things to do with my time. |
Copying from rivy/less#9 (comment)
For your information, Less v643 by @gwsw and @jftuga is the last version that colors properly on Windows 7. Subsequent versions (including, for example, v668) still run, but the coloring is broken. See sharkdp/bat#954 (comment).
The text was updated successfully, but these errors were encountered: