yorukot / superfile

Pretty fancy and modern terminal file manager
https://superfile.netlify.app
MIT License
5.79k stars 126 forks source link

Theme colors look wrong on custom st build #74

Open siduck opened 6 months ago

siduck commented 6 months ago

This is gruvbox theme

image

I do have true color support in my terminal, idk why the colors show wrong :thinking:

yorukot commented 6 months ago

Do you mean background color? Can you try changing the theme to something else?

siduck commented 6 months ago

image

nord looks like that

yorukot commented 6 months ago

It looks like only the background color is wrong. Can you try using different terminals?

Thank you so much for the test!

siduck commented 6 months ago

it works on all other terminals, and even other ST builds but not mine :((

yorukot commented 6 months ago

It seems to be a terminal issue. :( What is your terminal?

siduck commented 6 months ago

https://github.com/siduck/st

this is the original terminal https://st.suckless.org/

and we add patches to add new features in it

siduck commented 6 months ago

idk how your programs sets colors, but my terminal does support true colors , i use it all the time in neovim.

@bakkeby I tried your build and it doesnt have this issue, have you added any patch for it?

bakkeby commented 6 months ago

Hi @siduck,

in the context of st yes the alpha patch is too bright.

I added these changes which makes the colours look the same as in other terminals: https://github.com/bakkeby/st-flexipatch/commit/f7730166807252159475a77976b63545f970d55f

siduck commented 6 months ago

Hi @siduck,

in the context of st yes the alpha patch is too bright.

I added these changes which makes the colours look the same as in other terminals: bakkeby/st-flexipatch@f773016

i added those, didnt work

image

bakkeby commented 6 months ago

@siduck trying your build I see that it spits out this when superfile is started:

erresc: invalid color j=258, p=?
erresc: invalid color j=259, p=?
erresc: invalid color j=258, p=?

In st.c color reset section this is what is in your build.

        case 104: /* color reset, here p = NULL */
            if (par == 10)
                j = defaultfg;
            else if (par == 11)
                j = defaultbg;
            else if (par == 12)
                j = defaultcs;
            else
                j = (narg > 1) ? atoi(strescseq.args[1]) : -1;

            if (xsetcolorname(j, p)) {
                if (par == 104 && narg <= 1)
                    return; /* color reset without parameter */
                fprintf(stderr, "erresc: invalid color j=%d, p=%s\n",
                    j, p ? p : "(null)");
            } else {
                /*
                 * TODO if defaultbg color is changed, borders
                 * are dirty
                 */
                if (j == defaultbg)
                    xclearwin();
                redraw();
            }
            return;

whereas in a bare st we have:

        case 104: /* color reset */
            j = (narg > 1) ? atoi(strescseq.args[1]) : -1;

            if (p && !strcmp(p, "?")) {
                osc_color_response(j, 0, 1);
            } else if (xsetcolorname(j, p)) {
                if (par == 104 && narg <= 1) {
                    xloadcols();
                    return; /* color reset without parameter */
                }
                fprintf(stderr, "erresc: invalid color j=%d, p=%s\n",
                        j, p ? p : "(null)");
            } else {
                /*
                 * TODO if defaultbg color is changed, borders
                 * are dirty
                 */
                tfulldirt();
            }
            return;

Looks to come from changes that NRK introduced:

https://git.suckless.org/st/commit/8629d9a1da72cc18568a8f146307b0e939b77ebf.html https://git.suckless.org/st/commit/8629d9a1da72cc18568a8f146307b0e939b77ebf.html https://git.suckless.org/st/commit/7e8050cc621f27002eaf1be8114dee2497beff91.html

Not sure if that is related though as I don't know how to reproduce your issue.

yorukot commented 5 months ago

image This problem also seems to exist in termius