search

boyter / cs

command line codespelunker or code search
MIT License
514 stars 15 forks source link

Interactive TUI mode does not utilize terminal colors #23

Open m-kru opened 1 year ago

m-kru commented 1 year ago

It would be nice if cs could respect terminal colors in interactive TUI mode.

boyter commented 1 year ago

What colours are you intending? Syntax highlighted for code or some such?

Can you provide an example of what you are expecting? Do you have an example library that would be possible to use for this?

m-kru commented 1 year ago

image

image

I mean all colors.

I do not have much time at the moment, but there must be some way to read terminal colors in the application.

boyter commented 1 year ago

Ah gotcha. Yes that seems like something useful.

I have no idea how to go about doing this, but if I find anything ill post it here.

DannyBen commented 1 year ago

I am also interested in this. I don't care about terminal colors or not, but the fact that running cs switches to a dark theme makes it unusable to me. Can't it just use the standard ANSI colors - then it will work for everybody as is, in their own colors. And of course, avoid setting any background color, to retain the user's choice.

I really want to use cs, as I am searching code many times a day - but this is a hard show stopper...

boyter commented 1 year ago

@DannyBen Sorry what do you mean by switching to a dark mode? Can you provide a screenshot of what you have before to help me see what you mean.

DannyBen commented 1 year ago

This is my normal screen (in this case two tmux panels, top and bottom, to better emphasize the problem) image

This is how it looks when I start cs image

boyter commented 1 year ago

Yeah thats fairly annoying. I didn't actually tweak anything out of the box, instead using the defaults from https://github.com/rivo/tview

I might have to have a look over there and see if there is a way to respect what is being provided.

boyter commented 1 year ago

https://github.com/rivo/tview/issues/859

digitallyserviced commented 1 year ago

@boyter I am commenting here because it is probably a bit more personal then on tview's issues.

You can read my explainations on the issue you reference for a bit of detail concerning the colors.

Also see how tcell handles coloring here..

https://github.com/gdamore/tcell#24-bit-color

When using TrueColor, programs will display the colors that the programmer intended, overriding any "themes" you may have set in your terminal emulator. (For some cases, accurate color fidelity is more important than respecting themes. For other cases, such as typical text apps that only use a few colors, its more desirable to respect the themes that the user has established.)

You can disable 24-bit color by setting TCELL_TRUECOLOR=disable in your environment.

Now while this method works for respecting the defined terminal palette, it is not very helpful when you actually want to use colors outside 4/8-bit colors available with indexed palettes.

Tcell has a fix for this by using the TrueColor method.

https://github.com/gdamore/tcell/blob/47ec3a77754f83e84481fc9cdd0bc2072cd292ba/color.go#L1034

Also neighboring this method is PaletteColor which allows you to define the index of a color from the palette, (using 0-16 will pull the defined palette colors from their terminal).

When using SetDynamicColors in TextViews, always use the xterm/ansi name to ensure that the color uses the user's defined color palette as these names refer to the 0-15 colors. All of the color names, and more information can be found in the color.go I linked above. You can also see the first 16 names of colors in the lookup table for the color names to their index in the palette.

I have had a bit of experience dealing with this stuff. You can even see here where I am trying to convey the usefulness of the first 16 indexed colors in as far as how they relate to the user's custom palette settings.

https://github.com/wez/wezterm/pull/2286#issuecomment-1190759532

boyter commented 1 year ago

Thanks. Ill be going through all of this in the next few days.

Id love to get this all out of the box for people if possible, but if I have to resort to some canned themes I am prepared to do so.

digitallyserviced commented 1 year ago

@boyter I understand it can be quite daunting or more work to support/implement all the things... I agree that sometimes it's easier to just make it simpler with a hard set scheme.

The biggest problem I have come across is that the tview while it is an awesome tui/go framework, there are some things that are fixed and not customizable without hacking apart the library.

You can see in my fork how much I have changed things because of the original lacking things. I have even modified the style/theming for the color/region tags in textviews because I needed something more robust.

Since the code it comes from is unpolished it has not been published to git public... let me see if i can get you some of it

https://github.com/digitallyserviced/tview-theming

this provides a way to define styles and string formatting using a config file. As well as a way to name styles/themes when using the tags in a textview [red:black:b]text[::] can now be [redBoldText]text[::] as well as being able to modify the styles and have them refresh when the theme.toml changes (refreshing style configs doesn't cause re-render with new changes though)

sorry its a mess, but hopefully you can get something useful from it

boyter commented 1 year ago

@digitallyserviced I enjoy learning new things so while its a lot its not that much of a worry... other than time.

What you have put there is a great start for me to start playing around with. Although I am going to need assistance from a lot of people to get this right methinks... or setup a heap of styles so I can verify I get most of it right. Perhaps both.

digitallyserviced commented 1 year ago

@boyter

Although I am going to need assistance from a lot of people to get this right methinks

I dont mind answering questions or helping out with ideas, pointing you in directions, etc....

hit me up on the twitters or discord in my profile... you may even give me motivation and light a fire under my ass to clean up and polish all i've done with tview with my own app i haven't made publicly available...

It is actually specifically for customizing a user's terminal palette and color scheme...

I have animations, a better input handler, stacked views, custom primitives out the ass, a embedded femto/micro editor for writing your own JS functions... a fully supported V8 JS engine for plugins and extending ability to import/export schemes, and a host of other goodies...

Hit me up!

pickere demo-nvim-script switchview

whatisaphone commented 7 months ago

I tried TCELL_TRUECOLOR=disable, and on my setup at least it seems to fix the foreground colors, but the background is still hardcoded to black... so on a light theme you get black-on-black :sweat_smile:

I agree with previous posts--the right solution is to not set a background color at all, and use foreground colors from the 16 ANSI colors. Whatever terminal/color lib you're using seems too clever by half.

In the meantime, one workaround is setting $TERM to something that doesn't support colors at all:

TERM=vt100 cs
boyter commented 7 months ago

I may just re-implement using https://github.com/charmbracelet/bubbletea which appears to handle this a lot better.

whatisaphone commented 7 months ago

I tried running bubbletea/examples/list-default and it looks a lot better on my snowflake light theme setup!

By default it seems to use true color for some things and ANSI colors for others. And of course on my setup the ANSI colors are very readable, while the true colors are just okay. Luckily it can be configured.

boyter commented 7 months ago

That was my experience as well. I setup a few terminals with different themes to capture all the issues and it appeared to work fine. Just working though how I can get the code display in a list now and all the events.

Looks promising though.