gofmt

Author: BurntSushi

_examples/compress-events/main.go

@@ -9,8 +9,8 @@ MotionNotify events by displaying two windows that listen for MotionNotify
 events. The green window compresses them while the red window does not.
 Hovering over each window will print the x and y positions in each
 MotionNotify event received. You should notice that the red window
-lags behind the pointer (particularly if you moved the pointer quickly in 
-and out of the window) while the green window always keeps up, regardless 
+lags behind the pointer (particularly if you moved the pointer quickly in
+and out of the window) while the green window always keeps up, regardless
 of the speed of the pointer.
 
 In each case, we simulate work by sleeping for some amount of time. (The
@@ -33,8 +33,8 @@ compressed events in the usual way.)
 N.B. This functionality isn't included in xgbutil because event compression
 isn't something that is always desirable, and the conditions under which
 compression happens can vary. In particular, compressing ConfigureRequest
-events from the perspective of the window manager can be faulty, since 
-changes to other properties (like WM_NORMAL_HINTS) can change the semantics 
+events from the perspective of the window manager can be faulty, since
+changes to other properties (like WM_NORMAL_HINTS) can change the semantics
 of a ConfigureRequest event. (i.e., your compression would need to
 specifically look for events that could change future ConfigureRequest
 events.)
@@ -83,7 +83,7 @@ func newWindow(X *xgbutil.XUtil, color uint32) *xwindow.Window {
 // queue for any future MotionNotify events that can be received without
 // blocking. The most recent MotionNotify event is then returned.
 // Note that we need to make sure that the Event, Child, Detail, State, Root
-// and SameScreen fields are the same to ensure the same window/action is 
+// and SameScreen fields are the same to ensure the same window/action is
 // generating events. That is, we are only compressing the RootX, RootY,
 // EventX and EventY fields.
 // This function is not thread safe, since Peek returns a *copy* of the

_examples/pointer-painting/main.go

@@ -239,9 +239,9 @@ func main() {
 
 // midRect takes an (x, y) position where the pointer was clicked, along with
 // the width and height of the thing being drawn and the width and height of
-// the canvas, and returns a Rectangle whose midpoint (roughly) is (x, y) and 
-// whose width and height match the parameters when the rectangle doesn't 
-// extend past the border of the canvas. Make sure to check if the rectange is 
+// the canvas, and returns a Rectangle whose midpoint (roughly) is (x, y) and
+// whose width and height match the parameters when the rectangle doesn't
+// extend past the border of the canvas. Make sure to check if the rectange is
 // empty or not before using it!
 func midRect(x, y, width, height, canWidth, canHeight int) image.Rectangle {
 	return image.Rect(

_examples/screenshot/main.go

@@ -34,10 +34,10 @@ func main() {
 	ximg.XShowExtra("Screenshot", true)
 
 	// If you'd like to save it as a png, use:
-	// err = ximg.SavePng("screenshot.png") 
-	// if err != nil { 
-	// log.Fatal(err) 
-	// } 
+	// err = ximg.SavePng("screenshot.png")
+	// if err != nil {
+	// log.Fatal(err)
+	// }
 
 	xevent.Main(X)
 }

_examples/simple-mousebinding/main.go

@@ -44,8 +44,8 @@ func main() {
 	// See the documentation for the Connect method for more details.
 	err = cb1.Connect(X, X.RootWin(), "Mod4-1", false, true)
 
-	// A mouse binding can fail if the mouse string could not be parsed, or if 
-	// you're trying to bind a button that has already been grabbed by another 
+	// A mouse binding can fail if the mouse string could not be parsed, or if
+	// you're trying to bind a button that has already been grabbed by another
 	// client.
 	if err != nil {
 		log.Fatal(err)

_examples/window-gradient/main.go

@@ -135,7 +135,7 @@ func paintGradient(X *xgbutil.XUtil, wid xproto.Window, width, height int,
 // at which ConfigureNotify events are sent to us, thereby creating a "lag".
 // Compression works by examining the "future" of the event queue, and skipping
 // ahead to the most recent ConfigureNotify event and throwing away the rest.
-// 
+//
 // A more detailed treatment of event compression can be found in
 // xgbutil/examples/compress-events.
 func compressConfigureNotify(X *xgbutil.XUtil,

doc.go

@@ -1,18 +1,18 @@
 /*
-Package xgbutil is a utility library designed to make common tasks with the X 
-server easier. The central design choice that has driven development is to hide 
+Package xgbutil is a utility library designed to make common tasks with the X
+server easier. The central design choice that has driven development is to hide
 the complexity of X wherever possible but expose it when necessary.
 
-For example, the xevent package provides an implementation of an X event loop 
-that acts as a dispatcher to event handlers set up with the xevent, keybind and 
-mousebind packages. At the same time, the event queue is exposed and can be 
+For example, the xevent package provides an implementation of an X event loop
+that acts as a dispatcher to event handlers set up with the xevent, keybind and
+mousebind packages. At the same time, the event queue is exposed and can be
 modified using xevent.Peek and xevent.DequeueAt.
 
 Sub-packages
 
-The xgbutil package is considerably small, and only contains some type 
-definitions and the initial setup for an X connection. Much of the 
-functionality of xgbutil comes from its sub-packages. Each sub-package is 
+The xgbutil package is considerably small, and only contains some type
+definitions and the initial setup for an X connection. Much of the
+functionality of xgbutil comes from its sub-packages. Each sub-package is
 appropriately documented.
 
 Installation
@@ -34,33 +34,33 @@ A quick example to demonstrate that xgbutil is working correctly:
 	go get github.com/BurntSushi/xgbutil/examples/window-name-sizes
 	GO/PATH/bin/window-name-sizes
 
-The output will be a list of names of all top-level windows and their geometry 
-including window manager decorations. (Assuming your window manager supports 
+The output will be a list of names of all top-level windows and their geometry
+including window manager decorations. (Assuming your window manager supports
 some basic EWMH properties.)
 
 Examples
 
-The examples directory contains a sizable number of examples demonstrating 
-common tasks with X. They are intended to demonstrate a single thing each, 
+The examples directory contains a sizable number of examples demonstrating
+common tasks with X. They are intended to demonstrate a single thing each,
 although a few that require setup are necessarily long. Each example is
 heavily documented.
 
-The examples directory should be your first stop when learning how to use 
+The examples directory should be your first stop when learning how to use
 xgbutil.
 
-xgbutil is also used heavily throughout my window manager, Wingo. It may be 
+xgbutil is also used heavily throughout my window manager, Wingo. It may be
 useful reference material.
 
 Wingo project page: https://github.com/BurntSushi/wingo
 
 Thread Safety
 
-While I am fairly confident that XGB is thread safe, I am only somewhat 
-confident that xgbutil is thread safe. It simply has not been tested enough for 
+While I am fairly confident that XGB is thread safe, I am only somewhat
+confident that xgbutil is thread safe. It simply has not been tested enough for
 my confidence to be higher.
 
-Note that the xevent package's X event loop is not concurrent. Namely, 
-designing a generally concurrent X event loop is extremely complex. Instead, 
+Note that the xevent package's X event loop is not concurrent. Namely,
+designing a generally concurrent X event loop is extremely complex. Instead,
 the onus is on you, the user, to design concurrent callback functions if
 concurrency is desired.
 */

ewmh/doc.go

@@ -2,7 +2,7 @@
 Package ewmh provides a comprehensive API to get and set properties specified
 by the EWMH spec, as well as perform actions specified by the EWMH spec.
 
-Since there are so many functions and they adhere to an existing spec, 
+Since there are so many functions and they adhere to an existing spec,
 this package file does not contain much documentation. Indeed, each
 method has only a single comment associated with it: the EWMH property name.
 
@@ -14,10 +14,10 @@ Naming scheme
 
 Using "_NET_ACTIVE_WINDOW" as an example,
 functions "ActiveWindowGet" and "ActiveWindowSet" get and set the
-property, respectively. Both of these functions exist for most EWMH 
-properties. Additionally, some EWMH properties support sending a client 
-message event to request the window manager to perform some action. In the 
-case of "_NET_ACTIVE_WINDOW", this request is used to set the active 
+property, respectively. Both of these functions exist for most EWMH
+properties. Additionally, some EWMH properties support sending a client
+message event to request the window manager to perform some action. In the
+case of "_NET_ACTIVE_WINDOW", this request is used to set the active
 window.
 
 These sorts of functions end in "Req". So for "_NET_ACTIVE_WINDOW",
@@ -38,7 +38,7 @@ functions.)
 
 For properties that store more than just a simple integer, name or list
 of integers, structs have been created and exposed to organize the
-information returned in a sensible manner. For example, the 
+information returned in a sensible manner. For example, the
 "_NET_DESKTOP_GEOMETRY" property would typically return a slice of integers
 of length 2, where the first integer is the width and the second is the
 height. Xgbutil will wrap this in a struct with the obvious members. These

ewmh/ewmh.go

@@ -999,7 +999,7 @@ func WmSyncRequestExtra(xu *xgbutil.XUtil, win xproto.Window, reqNum uint64,
 		low, high)
 }
 
-// _NET_WM_SYNC_REQUEST_COUNTER get 
+// _NET_WM_SYNC_REQUEST_COUNTER get
 // I'm pretty sure this needs 64 bit integers, but I'm not quite sure
 // how to go about that yet. Any ideas?
 func WmSyncRequestCounter(xu *xgbutil.XUtil, win xproto.Window) (uint, error) {

icccm/doc.go

@@ -1,22 +1,22 @@
 /*
 Package icccm provides an API for a portion of the ICCCM, namely, getters
-and setters for many of the properties specified in the ICCCM. There is also a 
-smattering of support for other protocols specified by ICCCM. For example, to 
+and setters for many of the properties specified in the ICCCM. There is also a
+smattering of support for other protocols specified by ICCCM. For example, to
 satisfy the WM_DELETE_WINDOW protocol, package icccm provides 'IsDeleteProtocol'
 which returns whether a ClientMessage event satisfies the WM_DELETE_WINDOW
 protocol.
 
-If a property has values that aren't simple strings or integers, struct types 
+If a property has values that aren't simple strings or integers, struct types
 are provided to organize the data. In particular, WM_NORMAL_HINTS and WM_HINTS.
 
 Also note that properties like WM_NORMAL_HINTS and WM_HINTS contain a 'Flags'
-field (a bit mask) that specifies which values are "active". This is of 
-importance when setting and reading WM_NORMAL_HINTS and WM_HINTS; one must make 
+field (a bit mask) that specifies which values are "active". This is of
+importance when setting and reading WM_NORMAL_HINTS and WM_HINTS; one must make
 sure the appropriate bit is set in Flags.
 
-For example, you might want to check if a window has specified a resize 
+For example, you might want to check if a window has specified a resize
 increment in the WM_NORMAL_HINTS property. The values in the corresponding
-NormalHints struct are WidthInc and HeightInc. So to check if such values exist 
+NormalHints struct are WidthInc and HeightInc. So to check if such values exist
 *and* should be used:
 
 	normalHints, err := icccm.WmNormalHintsGet(XUtilValue, window-id)
@@ -29,13 +29,13 @@ NormalHints struct are WidthInc and HeightInc. So to check if such values exist
 
 When you should use icccm
 
-Although the ICCCM is extremely old, a lot of it is still used. In fact, the 
-EWMH spec itself specifically states that the ICCCM should still be used unless 
-otherwise noted by the EWMH. For example, WM_HINTS and WM_NORMAL_HINTS are 
+Although the ICCCM is extremely old, a lot of it is still used. In fact, the
+EWMH spec itself specifically states that the ICCCM should still be used unless
+otherwise noted by the EWMH. For example, WM_HINTS and WM_NORMAL_HINTS are
 still used, but _NET_WM_NAME replaces WM_NAME.
 
-With that said, many applications (like xterm or LibreOffice) have not been 
-updated to be fully EWMH compliant. Therefore, code that finds a window's name 
+With that said, many applications (like xterm or LibreOffice) have not been
+updated to be fully EWMH compliant. Therefore, code that finds a window's name
 often looks like this:
 
 	winName, err := ewmh.WmNameGet(XUtilValue, window-id)
@@ -53,8 +53,8 @@ Naming scheme
 
 The naming scheme is precisely the same as the one found in the ewmh package.
 The documentation for the ewmh package describes the naming scheme in more
-detail. The only difference (currently) is that the icccm package only contains 
-functions ending in "Get" and "Set". It is planned to add "Req" functions. (An 
+detail. The only difference (currently) is that the icccm package only contains
+functions ending in "Get" and "Set". It is planned to add "Req" functions. (An
 example of a Req function would be to send a ClientMessage implementing the
 WM_DELETE_WINDOW protocol to a client window.)
 */

keybind/doc.go

@@ -2,7 +2,7 @@
 Package keybind provides an easy to use interface to assign callback functions
 to human readable key sequences.
 
-Working with the X keyboard encoding is not an easy task, and the keybind 
+Working with the X keyboard encoding is not an easy task, and the keybind
 package attempts to encapsulate much of the complexity. Namely, the keybind
 package exports two function types: KeyPressFun and KeyReleaseFun. Values of
 these types are functions, and have a method called 'Connect' that attaches
@@ -44,30 +44,30 @@ shift---are pressed along with the 't' key.
 
 When to issue a passive grab
 
-One of the parameters of the 'Connect' method is whether to issue a passive 
+One of the parameters of the 'Connect' method is whether to issue a passive
 grab or not. A passive grab is useful when you need to respond to a key press
-on some parent window (like the root window) without actually focusing that 
-window. Not using a passive grab is useful when you only need to read key 
+on some parent window (like the root window) without actually focusing that
+window. Not using a passive grab is useful when you only need to read key
 presses when the window is focused.
 
 For more information on the semantics of passive grabs, please see
 http://tronche.com/gui/x/xlib/input/XGrabKey.html.
 
-Also, by default, when issuing a grab on a particular (modifiers, keycode) 
-tuple, several grabs are actually made. In particular, for each grab requested, 
+Also, by default, when issuing a grab on a particular (modifiers, keycode)
+tuple, several grabs are actually made. In particular, for each grab requested,
 another grab is made with the "num lock" mask, another grab is made with the
-"caps lock" mask, and another grab is made with both the "num lock" and "caps 
+"caps lock" mask, and another grab is made with both the "num lock" and "caps
 locks" masks. This allows key events to be reported regardless of whether
 caps lock or num lock is enabled.
 
-The extra masks added can be modified by changing the xevent.IgnoreMods slice. 
-If you modify xevent.IgnoreMods, it should be modified once on program startup 
-(i.e., before any key or mouse bindings are established) and never modified 
+The extra masks added can be modified by changing the xevent.IgnoreMods slice.
+If you modify xevent.IgnoreMods, it should be modified once on program startup
+(i.e., before any key or mouse bindings are established) and never modified
 again.
 
 Key bindings on the root window example
 
-To run a particular function whenever the 'Mod4-Control-Shift-t' key 
+To run a particular function whenever the 'Mod4-Control-Shift-t' key
 combination is pressed (mod4 is typically the 'super' or 'windows' key, but can
 vary based on your system), use something like:
 
@@ -83,8 +83,8 @@ window will only be reported when the root window has focus if no grab exists.
 
 Key bindings on a window you create example
 
-This code snippet attaches an event handler to some window you've created 
-without using a grab. Thus, the function will only be activated when the key 
+This code snippet attaches an event handler to some window you've created
+without using a grab. Thus, the function will only be activated when the key
 sequence is pressed and your window has focus.
 
 	keybind.Initialize(XUtilValue) // call once before using keybind package
@@ -95,23 +95,23 @@ sequence is pressed and your window has focus.
 
 Run a function on all key press events example
 
-This code snippet actually does *not* use the keybind package, but illustrates 
-how the Key{Press,Release} event handlers in the xevent package can still be 
-useful. Namely, the keybind package discriminates among events depending upon 
-the key sequences pressed, whereas the xevent package is more general: it can 
+This code snippet actually does *not* use the keybind package, but illustrates
+how the Key{Press,Release} event handlers in the xevent package can still be
+useful. Namely, the keybind package discriminates among events depending upon
+the key sequences pressed, whereas the xevent package is more general: it can
 only discriminate at the event level.
 
 	xevent.KeyPressFun(
 		func(X *xgbutil.XUtil, ev xevent.KeyPressEvent) {
 			// do something when any key is pressed
 		}).Connect(XUtilValue, your-window-id)
 
-This is the kind of handler you might use to capture all key press events. 
-(i.e., if you have a text box for a user to type in.) Additionally, if you're 
-using this sort of event handler, keybind.LookupString will probably be of some 
-use. Its contract is that given a (modifiers, keycode) tuple 
-(information found in all Key{Press,Release} events) it will return a string 
-representation of the key pressed. We can modify the above example slightly to 
+This is the kind of handler you might use to capture all key press events.
+(i.e., if you have a text box for a user to type in.) Additionally, if you're
+using this sort of event handler, keybind.LookupString will probably be of some
+use. Its contract is that given a (modifiers, keycode) tuple
+(information found in all Key{Press,Release} events) it will return a string
+representation of the key pressed. We can modify the above example slightly to
 echo the key pressed:
 
 	xevent.KeyPressFun(
@@ -122,7 +122,7 @@ echo the key pressed:
 
 More examples
 
-Complete working examples can be found in the examples directory of xgbutil. Of 
+Complete working examples can be found in the examples directory of xgbutil. Of
 particular interest are probably 'keypress-english' and 'simple-keybinding'.
 
 */

keybind/encoding.go

@@ -70,7 +70,7 @@ func ModifierString(mods uint16) string {
 }
 
 // KeyMatch returns true if a string representation of a key can
-// be matched (case insensitive) to the (modifiers, keycode) tuple provided. 
+// be matched (case insensitive) to the (modifiers, keycode) tuple provided.
 // String representations can be found in keybind/keysymdef.go
 func KeyMatch(xu *xgbutil.XUtil,
 	keyStr string, mods uint16, keycode xproto.Keycode) bool {