commit 3713dbb3170a61128a1a9d0f58edb80a78951810
Author: Hiltjo Posthuma <[email protected]>
Date: Sat Jan 5 17:59:43 2019 +0100
customization page: linewrap
diff --git a/dwm.suckless.org/customisation/font/index.md
b/dwm.suckless.org/customisation/font/index.md
index 67b4ec27..70086c3f 100644
--- a/dwm.suckless.org/customisation/font/index.md
+++ b/dwm.suckless.org/customisation/font/index.md
@@ -1,15 +1,16 @@
Change font in config.h
=======================
-*blame [Filippo Erik Negroni](mailto:f dot e dot negroni at googlemail dot
com>) about this document*
-
-Towards the beginning of **config.h**, you will find a line defining the
variable
+Towards the beginning of **config.h**, you will find a line defining the
+variable
static const char font[] = "..."
-By using **xfontsel**, you can produce a font line for the font you would
like to be used by **dwm** when displaying text in the menubar.
+By using **xfontsel**, you can produce a font line for the font you would like
+to be used by **dwm** when displaying text in the menubar.
-For example, to change the font to 'fixed', you can change the value of font
to:
+For example, to change the font to 'fixed', you can change the value of font
+to:
static const char font[] =
"-misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1";
diff --git a/dwm.suckless.org/customisation/noapps/index.md
b/dwm.suckless.org/customisation/noapps/index.md
index 6bca1254..c731bc83 100644
--- a/dwm.suckless.org/customisation/noapps/index.md
+++ b/dwm.suckless.org/customisation/noapps/index.md
@@ -1,12 +1,13 @@
Remove application defaults from config.h
=========================================
-*blame [Filippo Erik Negroni](mailto:f dot e dot negroni at googlemail dot
com>) about this document*
+The rules array is initialized, by default, to treat windows of class `Gimp`
+and `Firefox` in a special way. If, like me, you don't want any application to
+be treated in a special way, you must be careful when editing the rules array
+initialization code.
-The rules array is initialized, by default, to treat windows of class `Gimp`
and `Firefox` in a special way.
-If, like me, you don't want any application to be treated in a special way,
you must be careful when editing the rules array initialization code.
-
-The original code describes what each value represents within the Rule
structure.
+The original code describes what each value represents within the Rule
+structure.
static Rule rules[] = {
/* class instance title tags mask isfloating
monitor */
@@ -14,17 +15,20 @@ The original code describes what each value represents
within the Rule structure
{ "Firefox", NULL, NULL, 1 << 8, True,
-1 },
};
-For instance, Gimp and Firefox will be labeled as floating windows, even if
the layout selected is Monocle or Tiled.
-In particular, the tag mask will attach Firefox to tag '9'.
+For instance, Gimp and Firefox will be labeled as floating windows, even if the
+layout selected is Monocle or Tiled. In particular, the tag mask will attach
+Firefox to tag '9'.
-If we don't want any window class to be treated in a special way, we need to
initialize rules with at least one element:
+If we don't want any window class to be treated in a special way, we need to
+initialize rules with at least one element:
static Rule rules[] = {
/* class instance title tags mask isfloating
monitor */
{ NULL, NULL, NULL, 0, False,
-1 },
};
-The code in dwm.c will check that the `class` element is not NULL before any
matching is done.
+The code in dwm.c will check that the `class` element is not NULL before any
+matching is done.
/* rule matching */
XGetClassHint(dpy, c->win, &ch);
@@ -38,5 +42,7 @@ The code in dwm.c will check that the `class` element is not
NULL before any mat
}
}
-This code assumes the rules array has at least one element, and that the first
rule that does not match will apply to all window classes.
-Therefore, the rule we just made, is the default rule for all new windows and
therefore it is important you set the `tags mask` and `isfloating` elements
correctly.
+This code assumes the rules array has at least one element, and that the first
+rule that does not match will apply to all window classes. Therefore, the rule
+we just made, is the default rule for all new windows and therefore it is
+important you set the `tags mask` and `isfloating` elements correctly.
diff --git a/dwm.suckless.org/customisation/tagmask/index.md
b/dwm.suckless.org/customisation/tagmask/index.md
index c286d3a9..5fd36344 100644
--- a/dwm.suckless.org/customisation/tagmask/index.md
+++ b/dwm.suckless.org/customisation/tagmask/index.md
@@ -1,8 +1,6 @@
How does a tag-mask work?
=========================
-*blame [Filippo Erik Negroni](mailto:f dot e dot negroni at googlemail dot
com) about this document*
-
There exists extensive documentation in this wiki about tags in dwm.
This article will concentrate on how to manage bit masks in default rules.
@@ -13,13 +11,20 @@ Looking at dwm's code, the tags array is defined in the
familiar way:
static const char tags[][MAXTAGLEN] = { "1", "2", "3", "4", "5", "6",
"7", "8", "9" };
-We have 9 tags, labelled numerically (but the labels are just that, labels;
they don't have any intrinsic values).
+We have 9 tags, labelled numerically (but the labels are just that, labels;
+they don't have any intrinsic values).
-Within dwm's code, each client's tag list is managed as a bit mask: given an
integer binary representation, tags are associated from the least significant
bit (rightmost) to the most significant bit (leftmost).
+Within dwm's code, each client's tag list is managed as a bit mask: given an
+integer binary representation, tags are associated from the least significant
+bit (rightmost) to the most significant bit (leftmost).
-For example, tag '1' is 000000001, while tag 9 is 100000000. Tag '3' is
000000100 (third from the right)
+For example, tag '1' is 000000001, while tag 9 is 100000000. Tag '3' is
+000000100 (third from the right)
-The code in dwm.c that uses the rules array matches the current client
properties with each rule, and when matched, it bit-ands the tags member of the
rules array element with TAGMASK, then bit-ors it with the client's current tag
mask.
+The code in dwm.c that uses the rules array matches the current client
+properties with each rule, and when matched, it bit-ands the tags member of the
+rules array element with TAGMASK, then bit-ors it with the client's current tag
+mask.
/* rule matching */
XGetClassHint(dpy, c->win, &ch);
@@ -33,49 +38,63 @@ The code in dwm.c that uses the rules array matches the
current client propertie
}
}
-The client's tags value is therefore built sequentially through the rules.
-If the tagmask in rules is 0, the currently selected tag becomes the client's
tags value.
+The client's tags value is therefore built sequentially through the rules. If
+the tagmask in rules is 0, the currently selected tag becomes the client's tags
+value.
if(!c->tags)
c->tags = tagset[seltags];
-TAGMASK is the all-one bit mask, setting to 1 all the bits corresponding to a
tag in the tags array.
-TAGMASK is defined in dwm.c as:
+TAGMASK is the all-one bit mask, setting to 1 all the bits corresponding to a
+tag in the tags array. TAGMASK is defined in dwm.c as:
#define TAGMASK ((int)((1LL << LENGTH(tags)) - 1))
-and would produce, for the standard tags array, the bit configuration
111111111 (nine 1's).
+and would produce, for the standard tags array, the bit configuration 111111111
+(nine 1's).
-The reason for using TAGMASK is that it disallows the rules array to select a
tag for which we do not have a representation in the tags array.
+The reason for using TAGMASK is that it disallows the rules array to select a
+tag for which we do not have a representation in the tags array.
-Now, this method of representing tags allows us to express our preferences
regarding tags using bit-wise operators.
+Now, this method of representing tags allows us to express our preferences
+regarding tags using bit-wise operators.
When are tagmasks used?
-----------------------
-Please note that dwm always uses tagmasks: even when one tag is selected as
the visible tag, it is actually internally managed as a tagmask.
+Please note that dwm always uses tagmasks: even when one tag is selected as the
+visible tag, it is actually internally managed as a tagmask.
-To prove this, use the command combination that allows you to bring more than
one tag into view (usually Mod1-Ctrl-tagnumber). If you select tags 1, 2 and 3,
and then open a new xterm using Mod1-Shift-Return, the new xterm will be tagged
with tags 1, 2 and 3.
+To prove this, use the command combination that allows you to bring more than
+one tag into view (usually Mod1-Ctrl-tagnumber). If you select tags 1, 2 and 3,
+and then open a new xterm using Mod1-Shift-Return, the new xterm will be tagged
+with tags 1, 2 and 3.
A very powerful feature.
What does tagmask 0 mean?
-------------------------
-It means that the current tagmask should be selected for this window: if more
than one tag are currently visible, all the currently visible tags are going to
be associated to that window.
+It means that the current tagmask should be selected for this window: if more
+than one tag are currently visible, all the currently visible tags are going to
+be associated to that window.
What does tagmask 1 << 8 mean?
------------------------------
-1 shifted to the left by eight positions generates mask 100000000, selecting
tag '9' (ninth from the right) in the the tags array.
+1 shifted to the left by eight positions generates mask 100000000, selecting
+tag '9' (ninth from the right) in the the tags array.
What does ~0 mean?
------------------
-Complement of 0 is all 1's. This indicates all tags should be selected.
-The tag mask in rules is then filtered using the TAGMASK macro to adapt the
mask to just the available tags.
+Complement of 0 is all 1's. This indicates all tags should be selected. The
+tag mask in rules is then filtered using the TAGMASK macro to adapt the mask to
+just the available tags.
What does (1 << 8) - 1 mean?
----------------------------
-1 << 8 selects tag '9' only (100000000). Subtracting 1 to that bitmask
transforms all the 0's to the right of that tagmask into 1's (011111111),
effectively selecting all tags except '9'.
+1 << 8 selects tag '9' only (100000000). Subtracting 1 to that bitmask
+transforms all the 0's to the right of that tagmask into 1's (011111111),
+effectively selecting all tags except '9'.
diff --git a/dwm.suckless.org/customisation/windows_key/index.md
b/dwm.suckless.org/customisation/windows_key/index.md
index d34bde73..debdd854 100644
--- a/dwm.suckless.org/customisation/windows_key/index.md
+++ b/dwm.suckless.org/customisation/windows_key/index.md
@@ -1,18 +1,18 @@
Change Mod1 key to the Windows key in config.h
==============================================
-*blame [Filippo Erik Negroni](mailto:f dot e dot negroni at googlemail dot
com>) about this document*
-
-dwm's documentation refers to Mod1 as the modifier key that you must press to
issue commands to it.
-On most keyboards, Mod1 is mapped to the left Alt key.
-Most new keyboards now come equipped with the *Windows* key.
-Since no known UNIX/X applications are known to use the Windows key, it is an
excellent alternative mapping to issue commands to dwm.
+dwm's documentation refers to Mod1 as the modifier key that you must press to
+issue commands to it. On most keyboards, Mod1 is mapped to the left Alt key.
+Most new keyboards now come equipped with the *Windows* key. Since no known
+UNIX/X applications are known to use the Windows key, it is an excellent
+alternative mapping to issue commands to dwm.
In config.h, under the comment `/* key definitions */`, you can find the line
#define MODKEY Mod1Mask
-In order to change dwm's modifier key to the Windows key, you can simply
change its value definition to Mod4Mask.
+In order to change dwm's modifier key to the Windows key, you can simply change
+its value definition to Mod4Mask.
#define MODKEY Mod4Mask
@@ -51,4 +51,6 @@ It will show something like:
mod4 Super_L (0x7f), Hyper_L (0x80)
mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c)
-Using `xev`, a utility to show X events, such as key presses, we can quickly
identify which keysym (keycode) combination a particular key has, and associate
that to a modifier using `xmodmap`.
+Using `xev`, a utility to show X events, such as key presses, we can quickly
+identify which keysym (keycode) combination a particular key has, and associate
+that to a modifier using `xmodmap`.
