Re: [dev] [dwm] trayless workflow

> "BJ" == Bigby James writes: Hi James! Thank you for your insights, but my original concern was about missing something important when tag is hidden, and urgency hint is just right for that. I aware how tags works, but I don't like mixing programs: I'm using editor and browser often, but I

[dev] [PATCH 2/2] No need to zero-initialize global variables

--- st.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/st.c b/st.c index d03230f..431f483 100644 --- a/st.c +++ b/st.c @@ -3844,9 +3844,6 @@ main(int argc, char *argv[]) { char *titles; uint cols = 80, rows = 24; - xw.l = xw.t = 0; - xw.isfixed = False; -

[dev] [PATCH 1/2] DisplayWidth instead of DisplayHeight was used

--- st.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/st.c b/st.c index 9079834..d03230f 100644 --- a/st.c +++ b/st.c @@ -3044,7 +3044,7 @@ xinit(void) { if(xw.gm & XNegative) xw.l += DisplayWidth(xw.dpy, xw.scr) - xw.w - 2; if(xw.gm & YNegati

Re: [dev] [dwm] trayless workflow

> "MM" == Manolo Martínez writes: Hi Manolo! Thank you very much, it's exactly what I need :-) It's wonderful that dwm indicate UrgencyHint on hidden tags, it covers my needs 100%. Now I can easily get along without system tray. >> I just want to know what what is the alternative way t

[dev] [dwm] trayless workflow

Hello, I browsed suckless mailing lists and I found that system tray is discouraged in dwm and it's suggested to use tags instead. I was always using workspace separation (with other window manager) and I have instant messengers on dedicated workspace. But system tray is still very useful, withou

Re: [dev]

> "CL" == 20h <2...@r-36.net> writes: Thank you very much! From your previous post I thought you will never accept it. I was thinking about stopping using st. But now I got motivation to continue use st and contribute :-) CL>> I applied your patch with an extension. Now st has a Б─░i f

Re: [dev] [st PATCH] X geometry changes

> "CL" == Christoph Lohmann <2...@r-36.net> writes: CL>> Suckless is writing software for dwm. A specified geometry is CL>> fixed. Otherwise st is not floating by default when forcing a CL>> size. If st was designed only to support tiling window managers then I guess I made a wro

Re: [dev] [PATCH] Don't make bold text bright with default color

Hi all! I was about to patch st today, when I realized that if I define foreground and background color indexes to be _outside_ 256 color palette, behavior with the brightening of the bold face would be consistent with other terminals (st just don't know how to brighten the index which is outside

Re: [dev] [PATCH] Don't make bold text bright with default color

> "CL" == Christoph Lohmann <2...@r-36.net> writes: >> (by the way I just noticed that st is also brightening underline >> text, while other terminals don't) CL>> If you request the brightening of underline, you will get CL>> brightened un‐ derline. Ah, sure, I didn't modify

Re: [dev] [PATCH] Don't make bold text bright with default color

> "F" == FRIGN writes: F>> No, seriously. If you bring up a point, and we discuss it, we F>> prefer discussions which cut the bullshit and get to the point F>> of the problem - or - non-problem. Don't confuse this with being F>> habitutional, it's just that we have agreed on

Re: [dev] [PATCH] Don't make bold text bright with default color

> "REVC" == Roberto E Vargas Caballero writes: >> Bold colors are brightened to stand out even more. But with the >> light background and dark foreground brightening acts contrary >> making the letters less emphasized. REVC>> It is not the first time this question is discusse

Re: [dev] [PATCH] Don't make bold text bright with default color

Hi Christoph! Probably, but would it be better if I stay and continue to irritate habitues? Si fueris Romae, Romano vivito more; Si fueris alibi, vivito sicut ibi. (When at Rome, do as the Romans do.) > "CL" == Christoph Lohmann <2...@r-36.net> writes: CL>> Greetings. CL>> You gi

Re: [dev] [PATCH] Don't make bold text bright with default color

> "REVC" == Roberto E Vargas Caballero writes: >> if default color is used (with light background and black >> foreground it's looking rather ugly, brightened black font >> becomes gray and unreadable on light gray background). REVC>> If you don't like you can always change t

[dev] [PATCH] Show bold glyphs in bright color only when color is explicit

From: Yuri Karaban This makes behavior consistent with XTerm and RXVT. When default foreground color is black (implicit): echo -e "\033[1m Bold but not bright" should show bold black string, and when color is explicit (black too): echo -e "\033[30;1m Bold and bright" or e

[dev] [PATCH] Don't make bold text bright with default color

From: Yuri Karaban Hello, I found that st behavior is inconsistent with XTerm and RXVT in regard to handling bold text. XTerm and RXVT are not making bold font bright if default color is used (with light background and black foreground it's looking rather ugly, brightened black font be