Skip to content

Get/Set-PSReadLineOption -Colors improvements #845

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

Closed
raisin-loaf opened this issue Jan 21, 2019 · 6 comments
Closed

Get/Set-PSReadLineOption -Colors improvements #845

raisin-loaf opened this issue Jan 21, 2019 · 6 comments
Labels
Resolution-Answered Question is answered

Comments

@raisin-loaf
Copy link

I feel like I'm missing something obvious but I can't seem to change a handful of colours from their defaults. Specifically:

  • ContinuationPromptColor
  • DefaultTokenColor
  • MemberColor
  • NumberColor

Other colors like CommandColor and CommentColor seem to accept new values without issue.

This isn't the end of the world but as someone who prefers the solarized-light colour scheme the default for DefaultTokenColor (in particular) is so close to the background it renders the text invisible.

Set-PSReadLineOption -Colors @{
  ContinuationPromptColor = "`e[91m"
  DefaultTokenColor = "`e[91m"
}
Get-PSReadLineOption
.....
ContinuationPromptColor : "`e[37m"
DefaultTokenColor : "`e[37m"

Am I doing something wrong?

Though I've listed Linux below the same is true for me on Windows 10 v1709 (also PowerShell 6.1.2).

All advice very gratefully received. :)

Environment data

PS version: 6.1.2
PSReadline version: 2.0.0-beta3
os: Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
PS file version:

@lzybkr
Copy link
Contributor

lzybkr commented Jan 21, 2019

The valid keys are documented here - note that you don't specify Colors in the key.

The output of Get-PSReadLineOption is misleading here, I'll have to think about how that could be improved.

@raisin-loaf
Copy link
Author

raisin-loaf commented Jan 22, 2019

Thanks so much for the fast reply. And here I was genuinely thinking I'd read the documentation (the in-line documentation, at least). 🙂

I suspected I might've had the keys wrong cause I tested with garbage and the cmdlet didn't complain. Perhaps some form of validation would be useful? If I were a better coder I'd submit a PR.

Sorry to have troubled you with this, and thanks again! 👍

@lzybkr
Copy link
Contributor

lzybkr commented Jan 22, 2019

Oh, I think you've found a real issue - the formatting mislead you. I'm keeping the issue open to address the issues you've raised:

  • Color keys should be validated
  • Get-PSReadLineOption output should not use keys that are not valid.

@lzybkr lzybkr reopened this Jan 22, 2019
@lzybkr lzybkr changed the title Unable to Set Colors - ContinuationPromptColor, DefaultTokenColor & Others Get/Set-PSReadLineOption -Colors improvements Jan 22, 2019
@raisin-loaf
Copy link
Author

On a related note, it seems that even after setting all the colours available there are certain elements that still blend into the background (like bck-i-search: and the interactive prompt text that changes when there's a parse error). Is it possible to alter those colours too?

@lzybkr
Copy link
Contributor

lzybkr commented Jan 24, 2019

Feel free to open another issue for hard to read text like bck-i-search:. There is no setting, but it tries to use Console.ForegroundColor and Console.BackgroundColor, which return -1 on Linux and we then default to ConsoleColor.Gray.

When the prompt changes to show an error, the Error color is used.

@StevenBucher98
Copy link
Collaborator

Closing to track in #3601

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Answered Question is answered
Projects
None yet
Development

No branches or pull requests

3 participants