Although most of us agree that AI-suggested code can help us be more productive, I frequently find that I can't tell the difference between code that is actually in my buffer—because I typed it in, or it was there when I opened the file—and code that a (sometimes overzealous) AI LLM is trying to get me to accept.
Yes, if I look very very closely and carefully I might see an extremely subtle difference in the shade of gray, but I don't think such an effort should be required, since (in my opinion) there is no more important distinction for colors in a text editor to make than between code that is actually in the buffer and code that is not.
Because the code being suggested is often on the current line, any differences in coloring often appear to be caused by the highlight that goes with the current line. So my suggestion is to make the differences between (what one might call) "real" and "imaginary" code extremely dramatic and impossible to overlook. Perhaps having suggested "imaginary" code use a color scheme that looks like a photographic negative of real code is one obvious option. That might be a tad too extreme, but it is at least an example of something that makes the distinction extremely clear and impossible to overlook, at the risk of being slightly unpleasant. (I'm sure a better balance between aesthetics and clarity can be found. Whoever is handling design for Zed is obviously talented, since it's a very nice-looking editor! I would guess that they will have better ideas than I do for the details of the visual implementation.)
If you looked at the screen shot at the beginning and asked yourself "what is the point of this HTML?" or "why is there a stray
?" and you didn't think at all about the stray
being a suggestion by Copilot, then I think you'll see what I mean. I think that the fact that that is a Copilot suggestion (therefore "imaginary" code) ought to be the first thing you notice when you look at the code.
If applicable, add mockups / screenshots to help present your vision of the feature
Specifically an example like this, where "/playdate directory" is nearly indistinguishable from the text preceding it:
Could you comment on that issue and briefly rehash what I think you're trying to express here: "inline completion suggestions should be visually distinct from existing in default themes."
If I'm missing the point feel free to comment and I can reopen.
This is not a duplicate at all. The two issues have almost nothing in common, other than that they might be categorized as related to design and colors. The point of one and the point of the other are completely different.
In the other issue the person is simply requesting a greater difference in the light waves between the text color and the background color. This is relevant for people with poor vision who have trouble reading the text without high contrast.
In this issue I'm asking for specifically for a difference in every aspect of the appearance of real code versus suggested/"imaginary" code. This is dealing with the color palette and design at a higher level and is not concerned with just having greater physical contrast in the measurable characteristics of the light between foreground and background (which in every case will involve comparisons between exactly 2 colors), but a greater distinction in the entire color palettes used by these two types of code (which is more complex but also doesn't require nearly as much contrast).
To reiterate more simply: this issue has absolutely zero concern for the distinction between foreground and background, while the other issue is one hundred percent concerned with the distinction between foreground and background. The fact that they both involve colors does not make them the same issue. They have entirely different goals.
I agree that these issues are unrelated. It appears that the inline suggestion color is just a lighter color computed from editor.foreground. So if your foreground color is white, then the text you're typing will look the same as that of the inline suggestion. For example, if you use the following in your settings.json, you should get the following distinction between what you're typing (fasd) and the completion proposal (asdf):
In VSCode, it appears they just use the comment color for inline suggestions. I think this is a sensible default. It would be ideal if we could set this color in the theme, and then have a fallback value of the comment color.
@cloud303-cholden thanks for your thoughts and investigation! Knowing how to control this within a theme is valuable.
I think there is still a lot that could be done outside of the themes to fix this problem. I suspect that
many theme creators don't realize what "predictive" means, and thus don't set it;
it's far less likely to get tested (even if someone knows what it means) because it won't appear in static documents created for testing a theme;
since the theme preview (that you see after installing a theme) does not show a preview of a syntax-highlighted document (only changes to the application UI), and that non-existent preview obviously doesn't yet include "predictive" text, it's currently very unlikely that any theme creators will make changes or that any users will go to the pains necessary to check whether a theme they are choosing clearly differentiates between predictive text and other text.
Your discoveries probably mean that this particular issue should be closed, but I think it makes sense to open new ones for enhancements to Zed that will make it easier for both theme creators and regular users to factor in whether or not distinctions between predictive text and other text are clear.
@brandondrew Definitely agree. I think this is a more general issue around improving documentation. For example, I've had to do a lot of trial and error with keybindings since not all the actions are documented and some aren't obvious what they do from their name alone (e.g. editor::OpenExcerpts).
Alright, I'm going go ahead and close this issue. I appreciate the lively discussion and am looking forward to some of the feature we hope to implement, particularly those around semantic highlighting and more robust tools for identifying the sources of text (think git blame but blaming copilot/claude).
For anyone who discovers this in the future, you can override the theme color of predictive text with the following settings:
Check for existing issues
Describe the feature
Although most of us agree that AI-suggested code can help us be more productive, I frequently find that I can't tell the difference between code that is actually in my buffer—because I typed it in, or it was there when I opened the file—and code that a (sometimes overzealous) AI LLM is trying to get me to accept.
Yes, if I look very very closely and carefully I might see an extremely subtle difference in the shade of gray, but I don't think such an effort should be required, since (in my opinion) there is no more important distinction for colors in a text editor to make than between code that is actually in the buffer and code that is not.
Because the code being suggested is often on the current line, any differences in coloring often appear to be caused by the highlight that goes with the current line. So my suggestion is to make the differences between (what one might call) "real" and "imaginary" code extremely dramatic and impossible to overlook. Perhaps having suggested "imaginary" code use a color scheme that looks like a photographic negative of real code is one obvious option. That might be a tad too extreme, but it is at least an example of something that makes the distinction extremely clear and impossible to overlook, at the risk of being slightly unpleasant. (I'm sure a better balance between aesthetics and clarity can be found. Whoever is handling design for Zed is obviously talented, since it's a very nice-looking editor! I would guess that they will have better ideas than I do for the details of the visual implementation.)
If you looked at the screen shot at the beginning and asked yourself "what is the point of this HTML?" or "why is there a stray
If applicable, add mockups / screenshots to help present your vision of the feature
No response
I think this is potentially a duplicate of:
Specifically an example like this, where "/playdate directory" is nearly indistinguishable from the text preceding it:
Could you comment on that issue and briefly rehash what I think you're trying to express here: "inline completion suggestions should be visually distinct from existing in default themes."
If I'm missing the point feel free to comment and I can reopen.
This is not a duplicate at all. The two issues have almost nothing in common, other than that they might be categorized as related to design and colors. The point of one and the point of the other are completely different.
In the other issue the person is simply requesting a greater difference in the light waves between the text color and the background color. This is relevant for people with poor vision who have trouble reading the text without high contrast.
In this issue I'm asking for specifically for a difference in every aspect of the appearance of real code versus suggested/"imaginary" code. This is dealing with the color palette and design at a higher level and is not concerned with just having greater physical contrast in the measurable characteristics of the light between foreground and background (which in every case will involve comparisons between exactly 2 colors), but a greater distinction in the entire color palettes used by these two types of code (which is more complex but also doesn't require nearly as much contrast).
To reiterate more simply: this issue has absolutely zero concern for the distinction between foreground and background, while the other issue is one hundred percent concerned with the distinction between foreground and background. The fact that they both involve colors does not make them the same issue. They have entirely different goals.
I agree that these issues are unrelated. It appears that the inline suggestion color is just a lighter color computed from
editor.foreground. So if your foreground color is white, then the text you're typing will look the same as that of the inline suggestion. For example, if you use the following in yoursettings.json, you should get the following distinction between what you're typing (fasd) and the completion proposal (asdf):In VSCode, it appears they just use the comment color for inline suggestions. I think this is a sensible default. It would be ideal if we could set this color in the theme, and then have a fallback value of the comment color.
Nevermind I discovered the
predictivetheme settings which take care of this. https://github.com/zed-industries/zed/blob/7051bc00c2fe8d7407480a805e950cb73343bb45/assets/themes/one/one.json#L125-L127 Since the default theme sets these correctly, I think the onus is on theme authors and this is not a Zed issue.@cloud303-cholden thanks for your thoughts and investigation! Knowing how to control this within a theme is valuable.
I think there is still a lot that could be done outside of the themes to fix this problem. I suspect that
Your discoveries probably mean that this particular issue should be closed, but I think it makes sense to open new ones for enhancements to Zed that will make it easier for both theme creators and regular users to factor in whether or not distinctions between predictive text and other text are clear.
@brandondrew Definitely agree. I think this is a more general issue around improving documentation. For example, I've had to do a lot of trial and error with keybindings since not all the actions are documented and some aren't obvious what they do from their name alone (e.g.
editor::OpenExcerpts).Alright, I'm going go ahead and close this issue. I appreciate the lively discussion and am looking forward to some of the feature we hope to implement, particularly those around semantic highlighting and more robust tools for identifying the sources of text (think git blame but blaming copilot/claude).
For anyone who discovers this in the future, you can override the theme color of predictive text with the following settings:
Thanks all!