Add current-twitch-chat binding
Add more status colors
Write col_red and col_white in lowercase hex like the rest
Apply dwm-statuscolors-20220322-bece862.diff

Open ncmpcpp with Alt+M, not cmus
Use new mymusic script instead of mycmus
Merge branch 'suckless' into smlss
Reformat smlss README.md header
ba56fe9f — Hiltjo Posthuma 7 months ago suckless
Revert "Remove dmenumon variable"

This reverts commit c2b748e7931e5f28984efc236f9b1a212dbc65e8.

Revert back this change. It seems to not be an edge-case anymore since
multiple users have asked about this new behaviour now.
50ad171e — Hiltjo Posthuma 7 months ago
bump version to 6.4
970f3769 — Hiltjo Posthuma 8 months ago
remove workaround for a crash with color emojis on some systems, now fixed in libXft 2.3.5

Remove dmenumon variable

Reasoning: Since 2011 dmenu has been capable of working out which
monitor currently has focus in a Xinerama setup, making the use
of the -m flag more or less redundant.

This is easily demonstrated by using dmenu in any other window

There used to be a nodmenu patch that provided these changes:

but this was removed on the basis that it was very easy to work
out and apply manually if needed.

The proposal here is to remove this dependency from dwm. The
mechanism of the dmenumon variable could be provided via a patch
if need be.

The edge case scenario that dmenu does not handle on its own, and
the effect of removing this mechanism, is that if the user trigger
focusmon via keybindings to change focus to another monitor that
has no clients, then dmenu will open on the monitor containing the
window with input focus (or the monitor with the mouse cursor if
no windows have input focus).

If this edge case is important to cover then this can be addressed
by setting input focus to selmon->barwin in the focus function if
there is no client to give focus to (rather than giving focus back
to the root window).
Merge branch 'suckless' into smlss
Merge commit 'd93ff48803f04f1363bf303af1d7e6ccc5cb8d3f' into smlss

Fixed merge conflict because of attachBelow(c) patch
config.def.h: make keys and buttons const

pretty much all other variables are declared as const when they're not
Remove blw variable in favour of calculating the value when needed

The purpose and reasoning behind the bar layout width (blw) variable
in dwm the way it is today may not be immediately obvious.

The use of the variable makes more sense when looking at commit
2ce37bc from 2009 where blw was initialised in the setup function
and it represented the maximum of all available layout symbols.

	for(blw = i = 0; LENGTH(layouts) > 1 && i < LENGTH(layouts); i++) {
		w = TEXTW(layouts[i].symbol);
		blw = MAX(blw, w);

As such the layout symbol back then was fixed in size and both drawbar
and buttonpress depended on this variable.

The the way the blw variable is set today in drawbar means that it
merely caches the size of the layout symbol for the last bar drawn.

While unlikely to happen in practice it is possible that the last bar
drawn is not that of the currently selected monitor, which can result
in misaligned button clicks if there is a difference in layout symbol
width between monitors.
Make floating windows spawn within the monitor's window area

This is a follow-up on this thread:

The orginal code had constraints such that if a window's starting
attributes (position and size) were to place the window outside of
the edges of the monitor, then the window would be moved into view
at the closest monitor edge.

There was an exception to this where if a top bar is used then the
window should not obscure the bar if present, which meant to place
the window within the window area instead.

The proposed change here makes it the general rule that floating
windows should spawn within the window area rather than within the
monitor area. This makes it simple and consistent with no
exceptions and it makes the intention of the code clear.

This has the benefit of making the behaviour consistent regardless
of whether the user is using a top bar or a bottom bar.

Additionally this will have an effect on patches that modify the
size of the window area. For example if the insets patch is used to
reserve space on the left hand side of the monitor for a dock or a
vertical bar then new floating clients will not obscure that area.
Simplify client y-offset correction

The reasoning behind the original line may be lost to time as
it does not make much sense checking the position on the x-axis
to determine how to position the client on the y-axis.

In the context of multi-monitor setups the monitor y position
(m->my) may be greater than 0 (say 500), in which case the window
could be placed out of view if:
   - the window attributes have a 0 value for the y position and
   - we end up using the y position of bh (e.g. 22)

If the aim is to avoid a new floating client covering the bar then
restricting y position to be at least that of the window area
(m->wy) should cover the two cases of using a top bar and using a
bottom bar.