Add missing Oxford commas to improve documentation clarity (#332)

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: rzhao271 <7199958+rzhao271@users.noreply.github.com>

Coding-Guidelines.md

@@ -25,7 +25,7 @@ We use tabs, not spaces.
 * All strings visible to the user need to be externalized
 
 ## UI labels
-* Use title-style capitalization for command labels, buttons and menu items (each word is capitalized).
+* Use title-style capitalization for command labels, buttons, and menu items (each word is capitalized).
 * Don't capitalize prepositions of four or fewer letters unless it's the first or last word (e.g. "in", "with", "for").
 
 ## Style

December-Test-Plan.md

@@ -11,7 +11,7 @@ Verify that long text now nicely wraps across multiple lines in the debug repl b
 - [x] linux @aeschli 
 
 We have changed breakpoints states and now show it differently in the UI. Verify:
-* new UI properly and intuitivly reflects if breakpoints are enabled, disabled, verified or deactivated. 
+* new UI properly and intuitivly reflects if breakpoints are enabled, disabled, verified, or deactivated. 
 * breakpoints get hit / not hit depending on their enablement state
 
 ### Debug - extension debugging
@@ -94,7 +94,7 @@ Should expand to
 
 - [x] win | mac | linux @jrieken
 
-The language client / server libraries now support the complete set of language features available in the extension host. Implement a sample language server with more features by taking https://github.com/Microsoft/vscode-languageserver-node-example as a starting point. Focus on the new support for CodeActions, CodeLens, Formatting and rename.
+The language client / server libraries now support the complete set of language features available in the extension host. Implement a sample language server with more features by taking https://github.com/Microsoft/vscode-languageserver-node-example as a starting point. Focus on the new support for CodeActions, CodeLens, Formatting, and rename.
 
 ## vscode-tslint
 
@@ -249,6 +249,6 @@ If you are in a repository without a **remote** configured, none of the previous
 - [x] any platform @isidorn 
 
 Due to the move to textmate tokenizer, there were changes in the appearance of the default light and dark theme: Some themes got far more colorful, in particular JavaScript, some languages lost colors, e.g. Jade and XML. The goal was to stay as close as possible to what we had in 0.9.0: We stick to a few major colors: blue for keywords, green for comments and red for strings.
- * Test JavaScript and TypeScript in the light and dark theme, compare it our old state at https://opentools.azurewebsites.net/try. Note, new colors for method, function and parameters declarations
- * Test XML, HTML, Jade, Razor, Handlebars, CSS, LESS and SASS, JSON in the light and dark theme: They should all look consistent. Check stings, comments...
+ * Test JavaScript and TypeScript in the light and dark theme, compare it our old state at https://opentools.azurewebsites.net/try. Note, new colors for method, function, and parameters declarations
+ * Test XML, HTML, Jade, Razor, Handlebars, CSS, LESS, and SASS, JSON in the light and dark theme: They should all look consistent. Check stings, comments...
  * Try some of the other languages as well. Check stings, comments...

IME-Test.md

@@ -1,4 +1,4 @@
-Input method smoke test. VS Code is powered by [Monaco](https://github.com/Microsoft/monaco-editor), a browser based code editor which supports IE 9/10/11, Edge, Chrome, Firefox, Safari and Opera, so when we make changes to the editor part, we should make sure it still works on all browsers Monaco support.
+Input method smoke test. VS Code is powered by [Monaco](https://github.com/Microsoft/monaco-editor), a browser based code editor which supports IE 9/10/11, Edge, Chrome, Firefox, Safari, and Opera, so when we make changes to the editor part, we should make sure it still works on all browsers Monaco support.
 
 The golden standard is Word
 

Keybinding-Issues.md

@@ -229,7 +229,7 @@ Moreover, it is not possible to correlate modifier keys, `e.code` and `e.key` in
 
 ## How it works on Windows
 
-All built-in commands, extensions and user settings register keybindings in terms of `keyCode`. All Electron APIs (i.e. menus) refer to keybindings in terms of `keyCode`. The only special thing to do here is to be sure to present good labels in the UI to end-users.
+All built-in commands, extensions, and user settings register keybindings in terms of `keyCode`. All Electron APIs (i.e. menus) refer to keybindings in terms of `keyCode`. The only special thing to do here is to be sure to present good labels in the UI to end-users.
 
 For example, the `Toggle Line Comment` action is bound to <kbd>Ctrl+0xBF</kbd>:
 
@@ -256,7 +256,7 @@ Backslash: {
 
 ## How it works on macOS/Linux
 
-All built-in commands, extensions and user settings register keybindings in terms of `keyCode`. Therefore, the immediate thing to do here is to transform these keybindings in terms of `code`. This is done with an heuristic based on the produced characters.
+All built-in commands, extensions, and user settings register keybindings in terms of `keyCode`. Therefore, the immediate thing to do here is to transform these keybindings in terms of `code`. This is done with an heuristic based on the produced characters.
 
 
 <table>

Notebook-Smoke-Test.md

@@ -13,7 +13,7 @@
 
 ### File opening & rendering
 
-One major goal of native notebook experience in VS Code is performance: file opening, scrolling and editing should be as performant as a normal text editor. Please test the code change doesn't regress the performance
+One major goal of native notebook experience in VS Code is performance: file opening, scrolling, and editing should be as performant as a normal text editor. Please test the code change doesn't regress the performance
 
 * Open `samples/runCode.ipynb`, make sure markdown cell and code cells are rendered properly.
   * Scrolling in the editor is smooth, no significant noticeable lag.

Performance-Issues.md

@@ -158,7 +158,7 @@ Very detailed information is captured in CPU profiles and that helps us best to
 If VS Code is slugging when scrolling, moving mouse or typing, please create a performance profile. Do the following
   - Toggle the developer tools Help > Toggle Developer Tools
   - Select 'Performance'. In there click the record button.
-  - Scroll, type or any operation leads to the slowness of the UI
+  - Scroll, type, or perform any operation leads to the slowness of the UI
   - Let it profile for 30 to 60 seconds, stop it.
   - Save the profile to a file and attach the file to your issue.
 

Pointer-Device--&-Touch-support.md

@@ -29,7 +29,7 @@ For more details, please read blow:
 
 ## Pointer/Mouse Event
 
-Pointer events are DOM events fired by pointer devices, which include Mouse, Touch and Pen. Pointer events inherit from Mouse events, so we only need to adopt following generic mouse/pointer listeners without modifying out mouse handler code.
+Pointer events are DOM events fired by pointer devices, which include Mouse, Touch, and Pen. Pointer events inherit from Mouse events, so we only need to adopt following generic mouse/pointer listeners without modifying out mouse handler code.
 
 ### PointerDown/MouseDown
 

Removing-Insiders.md

@@ -24,7 +24,7 @@ To remove the `.deb` package (Debian and Ubuntu):
 sudo apt-get purge code-insiders
 ```
 
-To remove the `.rpm` package (Red Hat, CentOS and SUSE):
+To remove the `.rpm` package (Red Hat, CentOS, and SUSE):
 
 ```
 sudo yum remove code-insiders

Roadmap.md

@@ -219,7 +219,7 @@ Over the course of the last years we made significant progress on our original r
 
 
 ## VS Code Services
-- [x] Investigate hand-off/continuity service: When opening the same folder in different VS Code installs we hand over all untitled files, uncommitted or untracked changes, and some UI state.
+- [x] Investigate hand-off/continuity service: When opening the same folder in different VS Code installs we hand over all untitled files, uncommitted, or untracked changes, and some UI state.
 
 
 ## Languages
@@ -266,7 +266,7 @@ We have a dedicated [Python Roadmap](https://github.com/microsoft/vscode-python/
 
 ## Engineering
 - [x] Improve our smoke tests and revisit the current approach on how we implement them.
-- [x] Invest into a unified, improved and fast file watching
+- [x] Invest into a unified, improved, and fast file watching
 - [ ] :runner: Improve our GitHub issue bots, examples:
    - [x] reject invalid incoming issues automatically
    - [ ] :runner: automate training of our classification bot

Roadmap‐2021‐2022.md

@@ -137,7 +137,7 @@ For 2021/22, we'll particularly focus in the following themes.
 
 
 ## Engineering
-- [x] Invest into a unified, improved and fast file watching
+- [x] Invest into a unified, improved, and fast file watching
 - [ ] :runner: Improve our GitHub issue bots, examples:
    - [x] reject invalid incoming issues automatically
    - [x] detect issues of limited use that 'need more information' automatically

Running-the-Endgame.md

@@ -8,7 +8,7 @@ Each iteration closes with an [endgame](https://github.com/Microsoft/vscode/wiki
 - Discuss the endgame plan in Monday's planning call
   - Find an endgame buddy in the other lab
   - Remind people to update their testing availability and platform(s) in the call and release channel
-- Communicate in the `release` Slack channel every day about the plan, progress, TODOs and any other important notifications.
+- Communicate in the `release` Slack channel every day about the plan, progress, TODOs, and any other important notifications.
   - Tidy up milestone (PRs, Issues, Feature Requests missing labels)
   - Availability of the insiders build
   - Testing to be done (Test Plan Items, Verifications)

Sanity-Check.md

@@ -69,7 +69,7 @@ You can run it as so:
 npx @vscode/vscode-bisect@latest --sanity --commit <commit SHA of build to test>
 ```
 
-It will guide you through the process and download, install and execute each build artefact that needs to be tested.
+It will guide you through the process and download, install, and execute each build artefact that needs to be tested.
 
 Supported builds and flavors (all):
 

Semantic-Highlighting-Overview.md

@@ -60,7 +60,7 @@ When set, language extensions like TypeScript start reporting semantic tokens.
 
 Each semantic token is described by a token type, any number of token modifiers and a language. There's a [standardized set](https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#semantic-token-classification) of semantic types and modifiers, but languages can also define new and derived types and modifiers.
 
-Color themes can [write rules](https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#theming) directly against these semantic token types, modifiers and language.
+Color themes can [write rules](https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#theming) directly against these semantic token types, modifiers, and language.
 
 Alternatively, if a theme does not contain a semantic theming rule for a token, VSCode will use a [mapping from semantic token to a TextMate scopes](https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#semantic-token-scope-map) and look up the color in the themes TextMate rules. 
 

Source-Code-Organization.md

@@ -7,7 +7,7 @@ The `core` is partitioned into the following layers:
 - `base`: Provides general utilities and user interface building blocks that can be used in any other layer.
 - `platform`: Defines service injection support and the base services for VS Code that are shared across layers such as `workbench` and `code`. Should not include `editor` or `workbench` specific services or code.
 - `editor`: The "Monaco" editor is available as a [separate downloadable](https://microsoft.github.io/monaco-editor/) component.
-- `workbench`: Hosts the "Monaco" editor, notebooks and custom editors and provides the framework for panels like the Explorer, Status Bar, or Menu Bar, leveraging [Electron](https://www.electronjs.org/) to implement the VS Code desktop application and browser APIs to provide VS Code for the Web.
+- `workbench`: Hosts the "Monaco" editor, notebooks, and custom editors and provides the framework for panels like the Explorer, Status Bar, or Menu Bar, leveraging [Electron](https://www.electronjs.org/) to implement the VS Code desktop application and browser APIs to provide VS Code for the Web.
 - `code`: The entry point to the desktop app that stitches everything together, this includes the Electron main file, shared process, and the CLI for example.
 - `server`: The entry point to our server app for remote development.
 

Virtual-Workspaces.md

@@ -178,7 +178,7 @@ We are working on a UI for VS Code to indicate that the Window runs in a restric
 If working on a single file is not option, language extensions can also decide to disable the extension when in a virtual workspaces. 
 
 If your extension provides both grammars and rich language support and have to disable the extension also the grammars will be disabled. To avoid this, we recommend to split off a basic language extension (grammars, language configuration, snippets) form the rich language support and have two extensions.
-- The basic language extension has `"virtualWorkspaces": true` and provides language id, configuration, grammar and snippets.
+- The basic language extension has `"virtualWorkspaces": true` and provides language id, configuration, grammar, and snippets.
 - The rich language extension  has `"virtualWorkspaces": false` contains the main file contributing language supports and commands and has a extension dependency (`extensionDependencies`) on the basic language extension. The rich language extension should keep the ID of the established extension, so the user will continue to the full functionality by installing a single extension.
 
 You can see this with the built-in language extensions, such as JSON, which consists of a JSON extension and a JSON language feature extension.

[DEV]-Perf-Tools-for-VS-Code-Development.md

@@ -55,7 +55,7 @@ Emitting events can be a source of performance issues. Imagine an event with 100
 * When creating your emitter, pass the `_profName`-option. ❗This is dev-time only and MUST NOT be committed
 * Reload or execute the code in questions
 * Run "F1 > Print Emitter Profiles"
-* On the dev tools console and you'll see a summary including the listener count, the invocation count, total and average durations
+* On the dev tools console and you'll see a summary including the listener count, the invocation count, total, and average durations
 
 
 ### Targeted CPU profiling

[WIP]-Code-Editor-Design-Doc.md

@@ -112,12 +112,12 @@ export interface IViewModel extends IEventEmitter {
 }
 ```
 
-The first half methods are wrappers of Model, Editor configuration and View state. The second half are converters of View and Model info. Remember the first example of tab and column width we mentioned at the beginning of this topic? `convertModelPositionToViewPosition` and its counterpart `convertViewRangeToModelRange` are the right methods to call and they sit in the ViewModel but not other layers.
+The first half methods are wrappers of Model, Editor configuration, and View state. The second half are converters of View and Model info. Remember the first example of tab and column width we mentioned at the beginning of this topic? `convertModelPositionToViewPosition` and its counterpart `convertViewRangeToModelRange` are the right methods to call and they sit in the ViewModel but not other layers.
 
 Besides, both Model and ViewModel are implemented as `EventEmitter`, which allows us to handle events with ease.
 
 ## Model
-Model is the data and business logic, which is completely UI independent. To some extent, it's the core part of Monaco editor. It holds content and metadata of files, tokens and markers which provide a language-specific, structured representation of plain text, decorations for customized visual effect metadata, etc.
+Model is the data and business logic, which is completely UI independent. To some extent, it's the core part of Monaco editor. It holds content and metadata of files, tokens, and markers which provide a language-specific, structured representation of plain text, decorations for customized visual effect metadata, etc.
 
 Monaco has a rich extensibility model and you can extend it in many ways. However, we do not provide direct access to the View or ViewModel to extensions. We are continually trying to optimize the use of the underlying web technologies to deliver an always available, highly responsive editor and we will continue to tune our use of the DOM as these technologies and our product evolve. To maintain performance and compatibility, we run extensions in their own host process and prevent direct access to the View related information. Instead, we feed extensions with Model which is more stable and very unlikely to change vastly and break external extensions.