Skip to content
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

CLI output is wonky #405

Open
elydpg opened this issue Oct 22, 2021 · 14 comments
Open

CLI output is wonky #405

elydpg opened this issue Oct 22, 2021 · 14 comments

Comments

@elydpg
Copy link
Contributor

elydpg commented Oct 22, 2021

🐞 Bug report 🐞

Description

I'll let the below image speak for itself:

Screenshot (22)

Running the REPL causes PowerShell to recolour the screen in a weird way. Running this on cmd doesn't cause any recolouring, but you still get these ←[0m and ←[36m strings appearing.

@elydpg elydpg added the bug label Oct 22, 2021
@daveyarwood
Copy link
Member

That's interesting! I thought that Powershell supported ANSI escape sequences. I found this article, for example. It looks like that's new in Powershell 7, though, and I'm not sure if the library for colored text that we're using in Alda is smart enough to recognize that environment and emit the right escape codes.

Alda does support the standard NO_COLOR environment variable, so you can remove those ANSI escape sequences by setting NO_COLOR to anything (e.g. NO_COLOR=true) in your environment variables. Can you give that a try?

@elydpg
Copy link
Contributor Author

elydpg commented Oct 25, 2021

Screenshot (24)

Seems like it gets rid of the ←[0m like markings, but it doesn't get rid of the black recolouring of the screen...

@daveyarwood
Copy link
Member

I don't know of anything that we're doing in Alda that would behave differently there than other programs. Are there color theme settings that you can change, such that you can set them to the same color, e.g. black?

@elydpg
Copy link
Contributor Author

elydpg commented Oct 25, 2021

I mean, blue is the default colour of PowerShell... Seems odd that it should overwrite the colour in this way

@daveyarwood
Copy link
Member

Do other programs behave this way in PowerShell, too?

@elydpg
Copy link
Contributor Author

elydpg commented Oct 26, 2021

Not that I know of. Alda 1 doesn't have this problem.

@daveyarwood
Copy link
Member

That's interesting! I wonder if this might be a peculiarity of Go.

alda-player isn't written in Go. Can you try running alda-player info and tell me if it has the same problem?

@elydpg
Copy link
Contributor Author

elydpg commented Oct 26, 2021

I wonder if this might be a peculiarity of Go.

Not sure. Running alda-player info and even alda --help don't seem to cause the same problem. Only with the repl it seems...

Screenshot (25)
Screenshot (26)

@daveyarwood
Copy link
Member

OK, interesting.

My suspicion is that one of the Go libraries that we're using in the client is doing something strange. I don't have much bandwidth to devote to looking into this, but if a contributor felt like tackling this (or at least investigating further), it would be very much appreciated!

@grasinski
Copy link

Hi, I'd be willing to look into this!

@KenP97
Copy link

KenP97 commented May 13, 2022

I'm guessing the issue to be with the readline part, I changed the color library to "github.com/grookit/color" and managed to fix those ANSI escape characters printing out... but when the readline part starts the problems persists, and the background changes.

And I tried running readline separately and still the issue persisted even on a new project. so I'm guessing the issue is with the readline (we might need to configure it because they did mention it works on PowerShell)... ill look more into it till then
image

@KenP97
Copy link

KenP97 commented May 16, 2022

Am I allowed to use a different library instead of readline?

@KenP97
Copy link

KenP97 commented May 16, 2022

image

@daveyarwood
Copy link
Member

I answered you on Slack already, but for visibility here:

  • Changing libraries is definitely an option.
  • Changing the log.SetOutput(...) part could be an issue. I think I added that part to make sure that log messages don't interfere with inputting lines in the REPL. So whatever library we switch to, we should just make sure that log messages don't interfere with the REPL experience.
  • If you could make a PR, I'll be happy to test on Linux!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants