diff --git a/docs/01-readme.md b/docs/01-readme.md index 38da33739..da5233f2b 100644 --- a/docs/01-readme.md +++ b/docs/01-readme.md @@ -118,7 +118,7 @@ You can join us in the `#awesome` channel on the [OFTC](http://www.oftc.net/) IR You can ask questions on [Stack Overflow](http://stackoverflow.com/questions/tagged/awesome-wm). #### Reddit -We also have a [awesome subreddit](https://www.reddit.com/r/awesomewm/) where you can share your work and ask questions. +We also have an [awesome subreddit](https://www.reddit.com/r/awesomewm/) where you can share your work and ask questions. ## Reporting issues @@ -126,7 +126,7 @@ Please report any issues you may find on [our bugtracker](https://github.com/awe ## Contributing code -You can submit pull requests on the [github repository](https://github.com/awesomeWM/awesome). +You can submit pull requests on the [GitHub repository](https://github.com/awesomeWM/awesome). Please read the [contributing guide](https://github.com/awesomeWM/awesome/blob/master/docs/02-contributing.md) for any coding, documentation or patch guidelines. ## Status diff --git a/docs/02-contributing.md b/docs/02-contributing.md index dcde71447..66fa73218 100644 --- a/docs/02-contributing.md +++ b/docs/02-contributing.md @@ -2,7 +2,7 @@ ## Bugs -Please look at [Github Issues](https://github.com/awesomeWM/awesome/issues). +Please look at [GitHub Issues](https://github.com/awesomeWM/awesome/issues). ## Triage Issues [![Open Source Helpers](https://www.codetriage.com/AwesomeWM/awesome/badges/users.svg)](https://www.codetriage.com/AwesomeWM/awesome) @@ -106,7 +106,7 @@ If you plan to submit patches, you should follow the following guidelines. ### Patches -Submitting patches via pull requests on the Github project is the preferred +Submitting patches via pull requests on the GitHub project is the preferred method. #### Pull request diff --git a/docs/03-declarative-layout.md b/docs/03-declarative-layout.md index 1555a7c09..cf093f76a 100644 --- a/docs/03-declarative-layout.md +++ b/docs/03-declarative-layout.md @@ -36,7 +36,7 @@ configurable rules. ### Awful widgets -This modules contains the higher level window manager widgets. Since most of them +This module contains the higher level window manager widgets. Since most of them are used by the default config, here is how it maps: @DOC_awful_wibar_defaultwibar_EXAMPLE@ @@ -45,7 +45,7 @@ are used by the default config, here is how it maps: ### Titlebar widgets -The titlebar comes with some convinient default widgets. It simplify the most +The titlebar comes with some convenient default widgets. It simplifies the most basic "Windows/macOS" like titlebars. @DOC_awful_titlebar_defaulttitlebar_EXAMPLE@ @@ -124,7 +124,7 @@ to an object such as the mouse. The `naughty.layout.box` allows to provide custom widgets to use within the notifications. -The `awful.wallpaper` provides a non-intereactive "backgroud" for one or more +The `awful.wallpaper` provides a non-interactive "backgroud" for one or more `screen`. While it uses normal widget, it will not automatically be repainted if they change. It will also not provide any mouse events. @@ -221,7 +221,7 @@ styles, but this creates very confusing code and should be avoided. ## Creating and placing widgets using the declarative style The examples below explain in detail how to use the declarative layout system. -The imperative system is quite self explanatory and the respective widget API +The imperative system is quite self-explanatory and the respective widget API documentation should be enough for most. ### A simple layout @@ -254,7 +254,7 @@ Code: } -This examples uses the `awful.widget.only_on_screen` container to display +This example uses the `awful.widget.only_on_screen` container to display widgets only on some screens. ### Composite widgets @@ -513,7 +513,7 @@ property of many widgets such as the `awful.widget.taglist`, `awful.widget.tasklist` and `naughty.layout.box`. These templates are a **table** using the exact same syntax as the declarative widgets, but without the `wibox.widget` prefix in front of the curly braces. These templates -represents future widgets that will be created by their parent widget. This is +represent future widgets that will be created by their parent widget. This is necessary for three reasons: * The widget must create many instances of the template at different points in diff --git a/docs/04-new-widgets.md b/docs/04-new-widgets.md index ce7e29e8b..94a6bc253 100644 --- a/docs/04-new-widgets.md +++ b/docs/04-new-widgets.md @@ -113,6 +113,6 @@ looks like this: widget:after_draw_children(context, cr, width, height) The `:set_children()` method gets called recursively when setting a widget with -the declarative layout system, therefore the method should be well defined. +the declarative layout system, therefore the method should be well-defined. It should probably hook into the `:add` or `:add_widget` methods or be overridden to do nothing. diff --git a/docs/07-my-first-awesome.md b/docs/07-my-first-awesome.md index 61e76874b..9ac4929e5 100644 --- a/docs/07-my-first-awesome.md +++ b/docs/07-my-first-awesome.md @@ -65,7 +65,7 @@ overview now also provides a cheat sheet for controlling Vim. ## Change the theme -Awesome has multiple builtin themes you can choose from: +Awesome has multiple built-in themes you can choose from: * *default* * *gtk* diff --git a/docs/09-options.md b/docs/09-options.md index 4c56f5047..a64631a77 100644 --- a/docs/09-options.md +++ b/docs/09-options.md @@ -133,7 +133,7 @@ in the modeline either since at that point the file is already being read. -Usually, modeslines have the final say of which options to enable. This allows +Usually, modelines have the final say of which options to enable. This allows `rc.lua` to be portable between computers without have to modify `~/.xinitrc` or your session files. However, sometime, it is useful to override these parameters. The most common use case is the to bump the API level to see more @@ -176,7 +176,7 @@ useful for development. This option only check if the file is a valid Lua script. It will not check if -your custom logic makes sense. Even when this options says your config is fine, +your custom logic makes sense. Even when this option says your config is fine, it does **NOT** mean it can load properly. It only means it can be parsed and the interpreter can attempt to execute it. @@ -195,7 +195,7 @@ the interpreter can attempt to execute it. -This options disable the built-in real transparency support. This means +This option disables the built-in real transparency support. This means titlebars and wiboxes can no longer be made fully transparent. If you don't use a compositing manager such as `compton` or `picom`, this will only improve reliability and portability. Transparency is enabled by default and this should diff --git a/docs/17-porting-tips.md b/docs/17-porting-tips.md index cbae2c7e4..40890308b 100644 --- a/docs/17-porting-tips.md +++ b/docs/17-porting-tips.md @@ -258,7 +258,7 @@ Another dynamic screen related changes. - awful.key({ modkey }, "r", function () mypromptbox[mouse.screen]:run() end), + awful.key({ modkey }, "r", function () `awful.screen.focused`().mypromptbox:run() end), -`awful.prompt` now uses a more future proof arguments table instead of many +`awful.prompt` now uses a more future-proof arguments table instead of many optional arguments. ⠀ awful.key({ modkey }, "x", diff --git a/docs/90-FAQ.md b/docs/90-FAQ.md index 90db5468a..3355e8363 100644 --- a/docs/90-FAQ.md +++ b/docs/90-FAQ.md @@ -24,7 +24,7 @@ There are two common causes for this: The first is a display driver issue where painting on the screen takes long time. All input events (keyboard and mouse) are processed in the main thread. The drawing is also locking the main thread to avoid artifacts and race -ccontiditions. If there is a delay with the painting, it will delay the inputs. +conditions. If there is a delay with the painting, it will delay the inputs. The solution to this problem is using a compositing manager such as [compton](https://github.com/chjj/compton) or the older `xcompmgr`. This will move painting to another process and fully mitigate the issue. @@ -34,7 +34,7 @@ and most commonly manifests itself as occasional freezes instead of a generic de Do **not** use such functions and prefer `awful.spawn.easy_async`, `awful.widget.watch` or the GIO async API. Even if you *think* a command is fast enough and won't impact the main event loop iteration time, you are wrong. -*Every* calls to `io.open` are impacted by the system `iowait` queue and can +*Every* call to `io.open` is impacted by the system `iowait` queue and can spend hundreds of milliseconds blocked *before* being executed. Note that some common widget or probe libraries do not follow this advice currently and are known to cause input lag on some systems (but not all). @@ -399,7 +399,7 @@ To see where, run the following command: $ ls -l /proc/$(pidof awesome)/fd/2 -There's handy way to run Awesome and redirect both its standard output and error streams to files: +There's a handy way to run Awesome and redirect both its standard output and error streams to files: exec /usr/bin/awesome >> ~/.cache/awesome/stdout 2>> ~/.cache/awesome/stderr @@ -473,6 +473,6 @@ bugtracker](https://github.com/awesomeWM/awesome/issues). ### Do you accept patches and enhancements? Yes, we do. -You can submit pull requests on the [github repository](https://github.com/awesomeWM/awesome). +You can submit pull requests on the [GitHub repository](https://github.com/awesomeWM/awesome). Please read the [contributing guide](https://github.com/awesomeWM/awesome/blob/master/docs/02-contributing.md) for any coding, documentation or patch guidelines.