Remove underscore pauses from (hopefully) all snapshots

This seeks to remove the "_" from the key presses of snapshots and inline
runs in the documentation. The "_" no longer does anything, but got legacy
reasons at the moment we can't actually allow "_" to be an input to a
"faked" keypress in the docs and snapshots.

Removing these clears the way to letting "_" have the same status as any
other character.

See #1994.

docs/guide/CSS.md

@@ -68,7 +68,7 @@ Let's look at a trivial Textual app.
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/dom1.py" press="_"}
+    ```{.textual path="docs/examples/guide/dom1.py"}
     ```
 
 This example creates an instance of `ExampleApp`, which will implicitly create a `Screen` object. In DOM terms, the `Screen` is a _child_ of `ExampleApp`.

docs/guide/app.md

@@ -27,7 +27,7 @@ Apps don't get much simpler than this—don't expect it to do much.
 
 If we run this app with `python simple02.py` you will see a blank terminal, something like the following:
 
-```{.textual path="docs/examples/app/simple02.py" press="_"}
+```{.textual path="docs/examples/app/simple02.py"}
 ```
 
 When you call [App.run()][textual.app.App.run] Textual puts the terminal in to a special state called *application mode*. When in application mode the terminal will no longer echo what you type. Textual will take over responding to user input (keyboard and mouse) and will update the visible portion of the terminal (i.e. the *screen*).
@@ -57,7 +57,7 @@ Another such event is the *key* event which is sent when the user presses a key.
 
 The `on_mount` handler sets the `self.screen.styles.background` attribute to `"darkblue"` which (as you can probably guess) turns the background blue. Since the mount event is sent immediately after entering application mode, you will see a blue screen when you run this code.
 
-```{.textual path="docs/examples/app/event01.py" hl_lines="23-25" press="_"}
+```{.textual path="docs/examples/app/event01.py" hl_lines="23-25"}
 ```
 
 The key event handler (`on_key`) has an `event` parameter which will receive a [Key][textual.events.Key] instance. Every event has an associated event object which will be passed to the handler method if it is present in the method's parameter list.
@@ -114,7 +114,7 @@ Here's an app which adds a welcome widget in response to any key press:
 
 When you first run this you will get a blank screen. Press any key to add the welcome widget. You can even press a key multiple times to add several widgets.
 
-```{.textual path="docs/examples/app/widgets02.py" press="a,a,a,down,down,down,down,down,down,_,_,_,_,_,_"}
+```{.textual path="docs/examples/app/widgets02.py" press="a,a,a,down,down,down,down,down,down"}
 ```
 
 ## Exiting

docs/guide/devtools.md

@@ -60,7 +60,7 @@ textual console
 
 You should see the Textual devtools welcome message:
 
-```{.textual title="textual console" path="docs/examples/getting_started/console.py", press="_,_"}
+```{.textual title="textual console" path="docs/examples/getting_started/console.py"}
 ```
 
 In the other console, run your application with `textual run` and the `--dev` switch:

docs/guide/input.md

@@ -20,7 +20,7 @@ The most fundamental way to receive input is via [Key][textual.events.Key] event
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/input/key01.py", press="T,e,x,t,u,a,l,!,_"}
+    ```{.textual path="docs/examples/guide/input/key01.py", press="T,e,x,t,u,a,l,!"}
     ```
 
 When you press a key, the app will receive the event and write it to a [TextLog](../widgets/text_log.md) widget. Try pressing a few keys to see what happens.
@@ -102,7 +102,7 @@ The following example shows how focus works in practice.
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/input/key03.py", press="tab,H,e,l,l,o,tab,W,o,r,l,d,!,_"}
+    ```{.textual path="docs/examples/guide/input/key03.py", press="tab,H,e,l,l,o,tab,W,o,r,l,d,!"}
     ```
 
 The app splits the screen in to quarters, with a `TextLog` widget in each quarter. If you click any of the text logs, you should see that it is highlighted to show that the widget has focus. Key events will be sent to the focused widget only.

docs/guide/layout.md

@@ -444,7 +444,7 @@ The code below shows a simple sidebar implementation.
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/layout/dock_layout1_sidebar.py" press="pagedown,down,down,_,_,_,_,_"}
+    ```{.textual path="docs/examples/guide/layout/dock_layout1_sidebar.py" press="pagedown,down,down"}
     ```
 
 === "dock_layout1_sidebar.py"
@@ -468,7 +468,7 @@ This new sidebar is double the width of the one previous one, and has a `deeppin
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/layout/dock_layout2_sidebar.py" press="pagedown,down,down,_,_,_,_,_"}
+    ```{.textual path="docs/examples/guide/layout/dock_layout2_sidebar.py" press="pagedown,down,down"}
     ```
 
 === "dock_layout2_sidebar.py"

docs/guide/screens.md

@@ -36,7 +36,7 @@ Let's look at a simple example of writing a screen class to simulate Window's [b
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/screens/screen01.py" press="b,_"}
+    ```{.textual path="docs/examples/guide/screens/screen01.py" press="b"}
     ```
 
 If you run this you will see an empty screen. Hit the ++b++ key to show a blue screen of death. Hit ++escape++ to return to the default screen.
@@ -65,7 +65,7 @@ You can also _install_ new named screens dynamically with the [install_screen][t
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/screens/screen02.py" press="b,_"}
+    ```{.textual path="docs/examples/guide/screens/screen02.py" press="b"}
     ```
 
 Although both do the same thing, we recommend `SCREENS` for screens that exist for the lifetime of your app.
@@ -145,7 +145,7 @@ Screens can be used to implement modal dialogs. The following example pushes a s
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/screens/modal01.py" press="q,_"}
+    ```{.textual path="docs/examples/guide/screens/modal01.py" press="q"}
     ```
 
 Note the `request_quit` action in the app which pushes a new instance of `QuitScreen`. This makes the quit screen active. if you click cancel, the quit screen calls `pop_screen` to return the default screen. This also removes and deletes the `QuitScreen` object.

docs/guide/styles.md

@@ -20,7 +20,7 @@ The first line sets the [background](../styles/background.md) style to `"darkblu
 
 The second line sets [border](../styles/border.md) to a tuple of `("heavy", "white")` which tells Textual to draw a white border with a style of `"heavy"`. Running this code will show the following:
 
-```{.textual path="docs/examples/guide/styles/screen.py" press="_"}
+```{.textual path="docs/examples/guide/styles/screen.py"}
 ```
 
 ## Styling widgets

docs/guide/widgets.md

@@ -136,7 +136,7 @@ Let's use markup links in the hello example so that the greeting becomes a link
 
 === "Output"
 
-    ```{.textual path="docs/examples/guide/widgets/hello05.py" press="_"}
+    ```{.textual path="docs/examples/guide/widgets/hello05.py"}
     ```
 
 If you run this example you will see that the greeting has been underlined, which indicates it is clickable. If you click on the greeting it will run the `next_word` action which updates the next word.