more documentation updates

4 files changed, 38 insertions, 40 deletions

diff --git a/docs/guide/debugger.md b/docs/guide/debugger.md
index 85a7574e..39facff3 100644
--- a/docs/guide/debugger.md
+++ b/docs/guide/debugger.md
@@ -19,19 +19,19 @@ The debugger UI mainly consists of six parts:
 - debugger context menu
 - stack variable annotations
 
-The current UI should accommodate common operations within the debugger. And it is set to receive huge improvements over this summer.
 
 ### Debugger Sidebar
 
-The debugger sidebar locates inside the sidebar, which is on the left side of the main window. It can be enabled by clicking the button that looks like a bug.
+Clicking the debugger sidebar button (along the left edge of the main window, the one that looks like a bug) will activate the debugger sidebar.
+
+The debugger sidebar contains four widgets: the control buttons, the register widget, the breakpoint widget, and the module widget.
 
-The debugger sidebar contains four widgets, the control buttons, the register widget, the breakpoint widget, and the module widget.
 
 #### Control Buttons
 
 ![](../img/debugger/controlbuttons.png)
 
-There is a row of buttons at the top of the debugger Sidebar. They control the execution of the target. The behavior of the button is hopefully sensible from its icon. One can also hover over the button to get the name of the icon.
+There is a row of buttons at the top of the debugger sidebar. They control the execution of the target. The behavior of each button is hopefully sensible from its icon. One can also hover over the button to get the name of the icon.
 
 Buttons that do not work for the current target status are disabled. For example, before launching the target, the `Step Into` button is disabled.
 
@@ -78,26 +78,27 @@ There is a `Debugger` menu in the main window menu bar.
 
 Among the menu items, many are debugger control operations. They have the same effect as those buttons in the debugger sidebar.
 
-Besides, there is a `Launch/Connect Settings...` item which will trigger a `Debug Adapter Settings` dialog:
+The `Launch/Connect Settings...` menu item will trigger a `Debug Adapter Settings` dialog:
 
 ![](../img/debugger/adaptersettings.png)
 
-Within it, one can select of a DebugAdapter to use, as well as configure useful things like command-line arguments or the working directory.
+Within this dialog, one can select which DebugAdapter to use, as well as configure debugger settings such as command-line arguments or the working directory.
 
 `Run in Seperate Terminal` will cause the target to run in its own terminal, and the debugger will not be able to monitor its `stdout/stderr`, or send input `stdin`.
 This is suitable when the target sends complex output, and the debugger's console emulator (which is quite basic now) cannot handle it.
 
 ### Global Area Panels
 
-The debugger adds three new global area widgets, i.e., target terminal, debugger console, and stack trace.
+The debugger adds three new global area widgets: Target Console (terminal), Debugger Console, and Stack Trace.
 
-#### Target I/O
+#### Target Console
 
 ![](../img/debugger/targetterminal.png)
 
-The `Target I/O` panel simulates a terminal for the target. If the process writes to stdout, the content will be printed here. There is a line input at the bottom, and all input to it will be sent to the target's stdin.
+The `Target Console` panel simulates a terminal for the target. If the process writes to stdout, the content will be printed here. There is an input box at the bottom, and anything entered into it will be sent to the target's stdin.
+
 
-Due to a backend limitation, this feature only works on macOS and Linux. On Windows, the target always runs in its terminal, and all input/output happens there.
+Due to a backend limitation, this feature only works on macOS and Linux.  On Windows, the target always runs in its own external terminal, and all input/output happens there.
 
 On macOS and Linux, the default setting redirects the stdin/stdout here. However, if the user configures the target to run in its terminal (by calling `dbg.request_terminal_emulator = True`), then the stdin/stdout will not be redirected, and need to be accessed in the target's terminal.
 
@@ -134,9 +135,9 @@ Double-clicking an item in the stack frames list navigates to the return address
 
 A debugger status widget is added to the main window's status bar. It indicates the current status of the target.
 
-For example, when the target stops, it will include the reason for the stop. When the target exists, the exit code is reported. When an error occurs during certain operations, an error message will also be displayed here.
+For example, when the target stops, it will include the reason for the stop. When the target exits, the exit code is reported. When an error occurs during certain operations, an error message will also be displayed here.
 
-The widget always shows the status of the debugger for the current binary view. If you switch to a tab that views a different binary, it will show the status of the debugger for that binary, which might be inactive.
+The widget shows the status of the debugger for the current binary view if a debugging session is active.
 
 
 ### Context menu
@@ -153,7 +154,7 @@ Among these actions, target control actions, e.g., `Run`/`Step Into` have the sa
 
 `Make Code` is an experimental feature that displays the selected region as code. If the region is indeed code, the user can then hit `P` to create a function there.
 
-### Stack variable annotation
+### Stack Variable Annotation
 
 ![](../img/debugger/stackvariable.png)
 
@@ -161,7 +162,7 @@ When the target breaks and a stack trace is available, the debugger annotates th
 
 The above image shows the annotated stack with three stack frames. The start and end of each stack frame are marked, and stack variables are defined according to the stack variables in the functions.
 
-To view the stack variable annotations, switch to the linear view of the Debugger binary view, and then navigate to the stack pointer address.
+To view the stack variable annotations, switch to the linear view of the Debugger binary view, and then navigate to the stack pointer address (such as by double-clicking the stack pointer in the Registers view).
 
 A useful setup is a split view that shows the code on the left, and the stack on the right. If the user adopts this layout, remember to put the linear view that shows the stack region on a different sync group, so executing the target would not lead to navigation of the linear view. This way, we can observe how variables on the stack change.
 
@@ -172,7 +173,7 @@ Only the stack frames and variables of the current (active) thread are annotated
 The annotation is done only when there are at least two frames in the stack trace. This is a known limitation, and we will address it later.
 
 
-### Other UI elements
+### Other UI Elements
 
 On every line that has a breakpoint, there are two visual indicators:
 
@@ -182,14 +183,14 @@ On every line that has a breakpoint, there are two visual indicators:
 On the line where the program counter is at, there are two visual indicators:
 
 - the line is highlighted in blue
-- a program counter tag is added to the left
+- a program counter tag (=>) is added to the left
 
 
 ## Design
 
 ### Debug Adapters
 
-The goal of the Binary Ninja debugger is to provide a unified way of debugging programs on different platforms (e.g., Windows, Linux, macOS, etc). However, this is not an easy task, because each platform has its way of supporting debugging and it varies considerably.
+The goal of the Binary Ninja debugger is to provide a unified way of debugging programs on different platforms (e.g., Windows, Linux, macOS, etc). However, this is not an easy task, because each platform has its own way of supporting debugging and it varies considerably.
 
 To deal with this, we abstract the core functionalities of a debugger into a class `DebugAdapter`. Each debug adapter is a subclass of the `DebugAdapter` with the platform-dependent implementation of each method.
 
@@ -216,17 +217,17 @@ When the target is launched, the debugger automatically switches the view to the
 
 The debugger automatically applies all analysis data to the Debugger BinaryView, including functions and types, etc. This means the user can conveniently use types that are present in the static analysis.
 
-The Debugger BinaryView can be accessed by `dbg.live_view`, which should not be None once the target is launched. One can read/write to it in the normal way. Writing to it will also cause the target's memory to change.
+The Debugger BinaryView can be accessed by `dbg.live_view` once the target is launched. One can read/write to it in the normal way. Writing to it will also cause the target's memory to change.
 
-Right now, the Debugger BinaryView is discarded once the target exits. It cannot be easily reused due to ASLR, which makes the base of the program different in each run. As a result, any changes the user made to the Debugger BinaryView is also gone after the target exits. In the future, we will provide a way to let the user to selectively commit the changes made to the original view.
+Right now, the Debugger BinaryView is discarded once the target exits. It cannot be easily reused due to ASLR, which makes the base of the program different in each run. As a result, any changes the user made to the Debugger BinaryView will be discarded after the target exits.
 
 ## API
 
-The debugger exposes its functionality in both Python and C++ API. The Python documentation can be accessed [online](https://api.binary.ninja/binaryninja.debugger.debuggercontroller-module.html).
+The debugger exposes its functionality in both the Python and C++ APIs. The Python documentation can be accessed [online](https://api.binary.ninja/binaryninja.debugger.debuggercontroller-module.html).
 
 The API is centered around the [`DebuggerController`](https://api.binary.ninja/binaryninja.debugger.debuggercontroller-module.html#binaryninja.debugger.debuggercontroller.DebuggerController) class, which provides all functionalities of the debugger. There is no need to directly access the `DebugAdapter` classes.
 
-When the debugger is used within the UI, the `dbg` variable is injected into the Python interpreter. It always represents the debugger for the currently active Binary View. One can think of it as being created by
+When the debugger is used within the UI, the `dbg` magic variable is injected into the Python interpreter. It always represents the debugger for the currently active Binary View. One can think of it as being created by
 
 ```Python
 dbg = DebuggerController(bv)
@@ -237,10 +238,10 @@ where `bv` is another magic variable that always represents the current BinaryVi
 One can simply run `dbg.launch()` in the Python console to launch the target.
 
 
-
 ## How-to Guide
 
-Here is an incomplete guide on how to get started with the debugger. It covers the most basics operations in the debugger.
+Here is an incomplete guide on how to get started with the debugger, covering most of the basics on operations in the debugger.
+
 
 ### Launch and Control the Target
 
@@ -250,31 +251,31 @@ There are several ways to launch the target:
 - Use the debugger main window menu
 - Use the debugger context menu or its keybindings
 - Run LLDB/WinDbg commands in the debugger console
-- run `dbg.go()`, `dbg.step_into()`, etc. in the Python console.
+- Run `dbg.go()`, `dbg.step_into()`, etc. in the Python console.
 
 ### Configure Launch Parameters
 
-- click "Debugger" -> "Launch/Connect Settings..." in the main window menu, and edit parameters in the dialog
-- directly set the value of `dbg.cmd_line`, `dbg.working_directory`, `dbg.working_dir`, etc
+- Click "Debugger" -> "Launch/Connect Settings..." in the main window menu, and edit parameters in the dialog
+- Directly set the value of `dbg.cmd_line`, `dbg.working_directory`, `dbg.working_dir`, etc
 
 
 ### Add/Remove Breakpoints
 
 - Select the line, use the `Toggle Breakpoint` context menu
 - Right-click a line in the Breakpoint widget in the sidebar, and select `Remove Breakpoint`
-- run `dbg.add_breakpoint(address)` or `dbg.delete_breakpoint(address)` in the Python console.
+- Run `dbg.add_breakpoint(address)` or `dbg.delete_breakpoint(address)` in the Python console.
 
 
 ### Modify Register Values
 
 - Double-click a value item in the Register widget, type in the new value, and hit enter
-- run `dbg.set_reg_value(reg_name, value)` in the Python console.
+- Run `dbg.set_reg_value(reg_name, value)` in the Python console.
 
 
 ### View/Edit Memory
 
 - Switch to Linear or hex view of the Debugger BinaryView, and view/edit in the normal way
-- get the Debugger BinaryView by `dbg.live_view`, and read/write it in the normal way
+- Get the Debugger BinaryView by `dbg.live_view`, and read/write it in the normal way
 
 
 ### Remote debugging
diff --git a/docs/guide/objectivec.md b/docs/guide/objectivec.md
index ab2a3160..f101d7a5 100644
--- a/docs/guide/objectivec.md
+++ b/docs/guide/objectivec.md
@@ -40,5 +40,5 @@ Objective-C workflow must be chosen when loading a binary for analysis.
 
 ![](../img/objc_workflow_selected.png)
 
-This will automatically apply strucutre analysis as the binary is analyzed and
+This will automatically apply structure analysis as the binary is analyzed and
 also translate `objc_msgSend` calls to direct method calls, where possible.
diff --git a/docs/guide/settings.md b/docs/guide/settings.md
index ebcce4a0..4e0afe45 100644
--- a/docs/guide/settings.md
+++ b/docs/guide/settings.md
@@ -2,7 +2,7 @@
 
 ## UI
 
-![settings >](./img/settings.png "Settings")
+![settings >](../img/settings.png "Settings")
 
 Binary Ninja provides various settings which are available via the `[CMD/CTRL] ,` hotkey. These settings allow a wide variety of customization of the user interface and functional aspects of the analysis environment.
 
@@ -16,14 +16,14 @@ Several search keywords are available in the settings UI. Those include:
 
 There are several scopes available for settings:
 
-* **User Settings** - Settings that apply globally and override the defaults. These settings are stored in `settings.json` within the [User Folder](./#user-folder).
+* **User Settings** - Settings that apply globally and override the defaults. These settings are stored in `settings.json` within the [User Folder](./index.md#user-folder).
 * **Project Settings** - Settings which only apply if a project is opened. These settings are stored in `.binaryninja/settings.json` within a Project Folder. Project Folders can exist anywhere except within the User Folder. These settings apply to all files contained in the Project Folder and override the default and user settings. In order to activate this feature, select the Project Settings tab and a clickable "Open Project" link will appear at the top right of the view. Clicking this will create `.binaryninja/settings.json` in the folder of the currently selected binary view. If it already exists, this link will be replaced with the path of the project folder.
 * **Resource Settings** - Settings which only apply to a specific BinaryView object within a file. These settings persist in a Binary Ninja Database (.bndb) database or ephemerally in a BinaryView object if a database does not yet exist for a file.
 
 ???+ Warning "Tip"
     Both the _Project_ and _Resource_ tabs have a drop down indicator (▾) that can be clicked to select the project or resource whose settings you want to adjust.
 
-All settings are uniquely identified with an identifier string. Identifiers are available in the settings UI via the context menu and are useful for find settings using the search box and for [programmatically](https://api.binary.ninja/binaryninja.settings-module.html) interacting with settings.
+All settings are uniquely identified with an identifier string. Identifiers are available in the settings UI via the context menu and are useful for finding settings using the search box and for [programmatically](https://api.binary.ninja/binaryninja.settings-module.html) interacting with settings.
 
 **Note**: In order to facilitate reproducible analysis results, when opening a file for the first time, all of the analysis settings are automatically serialized into the _Resource Setting_ scope. This prevents subsequent _User_ and _Project_ setting modifications from unintentionally changing existing analysis results.
 
diff --git a/docs/guide/troubleshooting.md b/docs/guide/troubleshooting.md
index b2da8c53..a3e326d2 100644
--- a/docs/guide/troubleshooting.md
+++ b/docs/guide/troubleshooting.md
@@ -48,7 +48,7 @@ Next, if running a python plugin, make sure the python requirements are met by y
 
 ## Running as Root
 
-Binary Ninja will refuse to run as root on Linux and macOS platforms (this is partially enforced by the usage of an embedded QWebEngine which will not run as root). You can work-around this issue by either running as a regular user, or forcing BN to launch but you will need to also disable [active content](settings.md#updates.activeContent). If you try to use su or another similar tool, make sure that user has permission to the X11 session.
+Binary Ninja will refuse to run as root on Linux and macOS platforms. You can work around this issue by either running as a regular user, or forcing BN to launch. If you try to use su or another similar tool, make sure that user has permission to the X11 session.
 
 ## API
 
@@ -64,7 +64,7 @@ The below steps are specific to different platforms that Binary Ninja runs on.
 
 ### Windows
 
-- While Windows 7 is not officially supported (by us, or Microsoft for that matter), it's possible to have Binary Ninja work if all available windows updates are installed as a library pack update somewhere in the updates is required for us to run.
+- While Windows 7 is not officially supported (by us, or Microsoft for that matter), it may work if all available windows updates are installed (including non-security updates with certificate bundle updates).
 - If you install Windows without internet access and have never run windows updates to install an update, you may have an incomplete windows certificate store. You'll see errors when attempting to update about `CERTIFICATE VERIFICATION FAILED`.  If that is the case, you can either use something like `certutil.exe -generateSSTFromWU roots.sst` and then manually copy over the DST and Amazon certificates into your root store, or wait until the next time you have an update from Windows Update which should automatically refresh your certificate store.
 
 #### Some Graphics Chipsets
@@ -79,10 +79,7 @@ You may also manually create a `settings.json` file in your [user folder](./#use
 
 ``` js
 {
-	"updates" :
-	{
-		"activeContent" : false
-	}
+	"network.enableExternalResources" : false
 }
 ```
 
@@ -110,7 +107,7 @@ If you're running Catalina macOS with the Python 3 installed by XCode and wish t
 
 ### Linux
 
-Given the diversity of Linux distributions, some work-arounds are required to run Binary Ninja on platforms that are not [officially supported][FAQ].
+Given the diversity of Linux distributions, some workarounds are required to run Binary Ninja on platforms that are not [officially supported][FAQ].
 
 #### Common Problems