Merge pull request #6428 from MicrosoftDocs/fix/github-issues-20260309

Fix multiple GitHub issues: paths, filters, outdated WSL content, missing anchor

Author: GrantMeStrength

hub/dev-drive/index.md

@@ -250,7 +250,7 @@ The following examples demonstrate an administrator's ability to set filters all
 To use the `setfiltersallowed` command to allow `Filter-01` and `Filter-02` on all Dev Drives, use the command:
 
 ```powershell
-fsutil devdrv setfiltersallowed Filter-01, Filter-02
+fsutil devdrv setfiltersallowed "Filter-01, Filter-02"
 ```
 
 To display the filter attach policy for all Dev Drives, use the command:
@@ -292,7 +292,7 @@ The following filters may be used with Dev Drive:
 The `WdFilter` is attached by default. The following command is an example demonstrating how to attach all of these additional filters to a Dev Drive:
 
 ```powershell
-fsutil devdrv setfiltersallowed "PrjFlt, MsSecFlt, WdFilter, bindFlt, wcifs, FileInfo, ProcMon24"
+fsutil devdrv setfiltersallowed "PrjFlt, MsSecFlt, WdFilter, bindFlt, wcifs, FileInfo, ProcMon24, WinSetupMon, applockerfltr"
 ```
 
 > [!TIP]

hub/dev-environment/javascript/nodejs-on-wsl.md

@@ -86,13 +86,13 @@ We recommend using Visual Studio Code with the [Remote-development extension pac
 - Your project will automatically build in Linux.
 - You can use all your extensions running on Linux ([ES Lint, NPM Intellisense, ES6 snippets, etc.](https://marketplace.visualstudio.com/items?itemName=waderyan.nodejs-extension-pack)).
 
-Other code editors, like IntelliJ, Sublime Text, Brackets, etc. will also work with a WSL 2 Node.js development environment, but may not have the same sort of remote  features that VS Code offers. These code editors may run into trouble accessing the WSL shared network location (\\wsl$\Ubuntu\home\) and will try to build your Linux files using Windows tools, which likely is not what you want. The Remote-WSL Extension in VS Code handles this compatibility for you, with other IDEs you may need to set up an X server. [Support for running GUI apps in WSL](https://twitter.com/craigaloewen/status/1308452901266751488?lang=en) (like a code editor IDE) is coming soon.
+Other code editors, like IntelliJ, Sublime Text, Brackets, etc. will also work with a WSL 2 Node.js development environment, but may not have the same sort of remote  features that VS Code offers. These code editors may run into trouble accessing the WSL shared network location (\\wsl$\Ubuntu\home\) and will try to build your Linux files using Windows tools, which likely is not what you want. The Remote-WSL Extension in VS Code handles this compatibility for you, with other IDEs you may need to set up an X server.
 
 Terminal-based text editors (vim, emacs, nano) are also helpful for making quick changes from right inside your console. The article, [Emacs, Nano, or Vim: Choose your Terminal-Based Text Editor Wisely](https://medium.com/linode-cube/emacs-nano-or-vim-choose-your-terminal-based-text-editor-wisely-8f3826c92a68) does a nice job explaining some differences and a bit about how to use each.
 
 To install VS Code and the Remote-WSL Extension:
 
-1. [Download and install VS Code for Windows](https://code.visualstudio.com). VS Code is also available for Linux, but Windows Subsystem for Linux does not support GUI apps, so we need to install it on Windows. Not to worry, you'll still be able to integrate with your Linux command line and tools using the Remote - WSL Extension.
+1. [Download and install VS Code for Windows](https://code.visualstudio.com). VS Code is also available for Linux, but installing it on Windows with the Remote-WSL extension provides the best integrated development experience. Not to worry, you'll still be able to integrate with your Linux command line and tools using the Remote - WSL Extension.
 
 2. Install the [Remote - WSL Extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl) on VS Code. This allows you to use WSL as your integrated development environment and will handle compatibility and pathing for you. [Learn more](https://code.visualstudio.com/docs/remote/remote-overview).
 

hub/package-manager/configuration/create.md

@@ -24,7 +24,7 @@ Windows Package Manager uses manifests (YAML files) to locate and install packag
 
 ### File naming convention
 
-The convention for naming a WinGet Configuration file is using the ".winget" file extension (like `configuration.winget`). For Git-based projects the default configuration should be stored in a ".config" directory at: `./config/configuration.winget`. In some cases, more than one configuration file may be appropriate given different toolchains or user preferences. Those additional configuration files should also be located in the ".config" directory.
+The convention for naming a WinGet Configuration file is using the ".winget" file extension (like `configuration.winget`). For Git-based projects the default configuration should be stored in a ".config" directory at: `./.config/configuration.winget`. In some cases, more than one configuration file may be appropriate given different toolchains or user preferences. Those additional configuration files should also be located in the ".config" directory.
 
 ### Sections of a WinGet Configuration file
 

hub/powertoys/keyboard-manager.md

@@ -22,6 +22,7 @@ Also, you can exchange a key or shortcut to an arbitrary unicode text sequence.
 
 PowerToys Keyboard Manager must be enabled (with PowerToys running in the background) for remapped keys and shortcuts to be applied. If PowerToys is not running, key remapping will no longer be applied.
 
+<a id="keys-that-cannot-be-remapped"></a>
 > [!IMPORTANT]
 > There are some shortcut keys that are reserved by the operating system or cannot be replaced. Keys that cannot be remapped include:
 >