commit cdcfb019c3769d50a6e88d7ac6f09114251820bd
parent 20ffa29a57e09f4500e86e0ded374b061608d6fa
Author: Hiltjo Posthuma <hiltjo@codemadness.org>
Date: Sat, 5 Jan 2019 16:46:10 +0100
remove "blame", linewrap
Diffstat:
4 files changed, 70 insertions(+), 44 deletions(-)
diff --git a/dwm.suckless.org/customisation/font/index.md b/dwm.suckless.org/customisation/font/index.md
@@ -1,13 +1,13 @@
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:
diff --git a/dwm.suckless.org/customisation/noapps/index.md b/dwm.suckless.org/customisation/noapps/index.md
@@ -1,10 +1,10 @@
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.
@@ -14,17 +14,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 +41,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
@@ -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,8 +38,9 @@ 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];
@@ -44,37 +50,50 @@ 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
@@ -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
@@ -34,10 +34,10 @@ Can I use any other modifier key?
---------------------------------
Yes.
-There are 5 modifiers, Mod1Mask to Mod5Mask.
-They are associated to up-to three keysyms (keycodes) from the X window server.
-To show the current association on your keyboard, run `xmodmap` with no arguments.
-It will show something like:
+There are 5 modifiers, Mod1Mask to Mod5Mask. They are associated to up-to
+three keysyms (keycodes) from the X window server. To show the current
+association on your keyboard, run `xmodmap` with no arguments. It will show
+something like:
$ xmodmap
xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
@@ -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`.
