bash code blocks

elParaguayo · Dec 13, 2023 · 0afeebe · 0afeebe
1 parent 85b6a5f
commit 0afeebe
Show file tree

Hide file tree

Showing 6 changed files with 99 additions and 99 deletions.
diff --git a/docs/manual/commands/shell/iqshell.md b/docs/manual/commands/shell/iqshell.md
@@ -15,9 +15,9 @@ Dependencies
 In order to run iqshell, you must have `ipykernel`_ and `jupyter_console`_.
 You can install the dependencies when you are installing qtile by running:
 
-.. code-block:: bash
-
-    $ pip install qtile[ipython]
+``` bash
+$ pip install qtile[ipython]
+```
 
 Otherwise, you can just install these two packages separately, either through
 PyPI or through your distribution package manager.
@@ -31,27 +31,27 @@ Installing and Running the Kernel
 Once you have the required dependencies, you can run the kernel right away by
 running:
 
-.. code-block:: bash
-
-    $ python3 -m libqtile.interactive.iqshell_kernel
+``` bash
+$ python3 -m libqtile.interactive.iqshell_kernel
+```
 
 However, this will merely spawn a kernel instance, you will have to run a
 separate frontend that connects to this kernel.
 
 A more convenient way to run the kernel is by registering the kernel with
 Jupyter.  To register the kernel itself, run:
 
-.. code-block:: bash
-
-    $ python3 -m libqtile.interactive.iqshell_install
+``` bash
+$ python3 -m libqtile.interactive.iqshell_install
+```
 
 If you run this as a non-root user, or pass the `--user` flag, this will
 install to the user Jupyter kernel directory.  You can now invoke the kernel
 directly when starting a Jupyter frontend, for example:
 
-.. code-block:: bash
-
-    $ jupyter console --kernel qshell
+``` bash
+$ jupyter console --kernel qshell
+```
 
 The `iqshell` script will launch a Jupyter terminal console with the qshell kernel.
 

diff --git a/docs/manual/commands/shell/qtile-run.md b/docs/manual/commands/shell/qtile-run.md
@@ -7,7 +7,7 @@ a specific group, make it floating, intrusive, etc.
 
 The Windows must have NET_WM_PID.
 
-.. code-block:: bash
-
-    # run xterm floating on group "test-group"
-    qtile run-cmd -g test-group -f xterm
+``` bash
+# run xterm floating on group "test-group"
+qtile run-cmd -g test-group -f xterm
+```
diff --git a/docs/manual/commands/shell/qtile-shell.md b/docs/manual/commands/shell/qtile-shell.md
@@ -18,37 +18,37 @@ Navigating the Object Graph
 The shell presents a filesystem-like interface to the command graph - the
 builtin "cd" and "ls" commands act like their familiar shell counterparts:
 
-.. code-block:: bash
+``` bash
+> ls
+layout/  widget/  screen/  bar/     window/  group/
 
-    > ls
-    layout/  widget/  screen/  bar/     window/  group/
+> cd screen
+layout/  window/  bar/  widget/
 
-    > cd screen
-    layout/  window/  bar/  widget/
+> cd ..
+/
 
-    > cd ..
-    /
-
-    > ls
-    layout/  widget/  screen/  bar/     window/  group/
+> ls
+layout/  widget/  screen/  bar/     window/  group/
+```
 
 If you try to access an object that has no "default" value then you will see an
 error message:
 
-.. code-block:: bash
-
-    > ls
-    layout/  widget/  screen/  bar/     window/  group/
+``` bash
+> ls
+layout/  widget/  screen/  bar/     window/  group/
 
-    > cd bar
-    Item required for bar
+> cd bar
+Item required for bar
 
-    > ls bar
-    bar[bottom]/
+> ls bar
+bar[bottom]/
 
-    > cd bar/bottom
-    bar['bottom']> ls
-    screen/  widget/
+> cd bar/bottom
+bar['bottom']> ls
+screen/  widget/
+```
 
 Please refer to :ref:`object_graph_selectors` for a summary of which objects need a
 specified selector and the type of selector required. Using `ls` will show
@@ -60,54 +60,54 @@ selectors are available. The first value shows whether a selector is optional
 (`False` means that a selector is required) and the second value is a list of
 selectors:
 
-.. code-block:: bash
-
-    > ls
-    layout/  widget/  screen/  bar/     window/  group/
+``` bash
+> ls
+layout/  widget/  screen/  bar/     window/  group/
 
-    > items(bar)
-    (False, ['bottom'])
+> items(bar)
+(False, ['bottom'])
+```
 
 Displaying the shell path
 =========================
 
 Note that the shell provides a "short-hand" for specifying node keys (as
 opposed to children). The following is a valid shell path:
 
-.. code-block:: bash
-
-    > cd group/4/window/31457314
+``` bash
+> cd group/4/window/31457314
+```
 
 The command prompt will, however, always display the Python node path that
 should be used in scripts and key bindings:
 
-.. code-block:: bash
-
-    group['4'].window[31457314]>
+``` bash
+group['4'].window[31457314]>
+```
 
 Live Documentation
 ==================
 
 The shell `help` command provides the canonical documentation for the Qtile
 API:
 
-.. code-block:: bash
-
-    > cd layout/1
+``` bash
+> cd layout/1
 
-    layout[1]> help
-    help command   -- Help for a specific command.
+layout[1]> help
+help command   -- Help for a specific command.
 
-    Builtins
-    ========
-    cd    exit  help  ls    q     quit
+Builtins
+========
+cd    exit  help  ls    q     quit
 
-    Commands for this object
-    ========================
-    add           commands      current       delete        doc
-    down          get_info      items         next          previous
-    rotate        shuffle_down  shuffle_up    toggle_split  up
+Commands for this object
+========================
+add           commands      current       delete        doc
+down          get_info      items         next          previous
+rotate        shuffle_down  shuffle_up    toggle_split  up
 
-    layout[1]> help previous
-    previous()
-    Focus previous stack.
+layout[1]> help previous
+previous()
+Focus previous stack.
+```
diff --git a/docs/manual/config/hooks.md b/docs/manual/config/hooks.md
@@ -46,11 +46,11 @@ Let's create an executable file `~/.config/qtile/autostart.sh` that will
 start a few programs when Qtile first runs. Remember to `chmod +x ~/.config/qtile/autostart.sh` so
 that it can be executed.
 
-.. code-block:: bash
-
-    #!/bin/sh
-    pidgin &
-    dropbox start &
+``` bash
+#!/bin/sh
+pidgin &
+dropbox start &
+```
 
 We can then subscribe to `startup_once` to run this script:
 

diff --git a/docs/manual/faq.md b/docs/manual/faq.md
@@ -35,9 +35,9 @@ When I first start xterm/urxvt/rxvt containing an instance of Vim, I see text an
 Vim is not handling terminal resizes correctly. You can fix the problem by
 starting your xterm with the "-wf" option, like so:
 
-.. code-block:: bash
-
-    xterm -wf -e vim
+``` bash
+xterm -wf -e vim
+```
 
 Alternatively, you can just cycle through your layouts a few times, which
 usually seems to fix it.
@@ -49,19 +49,19 @@ How do I know which modifier specification maps to which key?
 To see a list of modifier names and their matching keys, use the `xmodmap`
 command. On my system, the output looks like this:
 
-.. code-block:: bash
-
-    $ xmodmap
-    xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):
-
-    shift       Shift_L (0x32),  Shift_R (0x3e)
-    lock        Caps_Lock (0x9)
-    control     Control_L (0x25),  Control_R (0x69)
-    mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
-    mod2        Num_Lock (0x4d)
-    mod3
-    mod4        Super_L (0xce),  Hyper_L (0xcf)
-    mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
+``` bash
+$ xmodmap
+xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):
+
+shift       Shift_L (0x32),  Shift_R (0x3e)
+lock        Caps_Lock (0x9)
+control     Control_L (0x25),  Control_R (0x69)
+mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
+mod2        Num_Lock (0x4d)
+mod3
+mod4        Super_L (0xce),  Hyper_L (0xcf)
+mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
+```
 
 
 My "pointer mouse cursor" isn't the one I expect it to be!

diff --git a/docs/manual/hacking.md b/docs/manual/hacking.md
@@ -36,10 +36,10 @@ The test suite can be run using the X11 or Wayland backend, or both.  By
 default, only the X11 backend is used for tests. To test a single backend or
 both backends, specify as arguments to pytest:
 
-.. code-block:: bash
-
-    pytest --backend wayland  # Test just Wayland backend
-    pytest --backend x11 --backend wayland  # Test both
+``` bash
+pytest --backend wayland  # Test just Wayland backend
+pytest --backend x11 --backend wayland  # Test both
+```
 
 Testing with the X11 backend requires Xephyr_ (and xvfb for headless mode) in addition to the core
 dependencies.
@@ -54,9 +54,9 @@ built at run time and will have to be generated manually when the code is
 downloaded or when any changes are made to the cffi library.  This can be done
 by calling:
 
-.. code-block:: bash
-
-    ./scripts/ffibuild
+``` bash
+./scripts/ffibuild
+```
 
 Setting up the environment
 ==========================
@@ -202,17 +202,17 @@ It's likely though that you want to use a different, customized startup script
 for testing purposes, for example `~/.config/qtile/xinitrc`. You can do so by
 launching X with:
 
-.. code-block:: bash
-
-  startx ~/.config/qtile/xinitrc
+``` bash
+startx ~/.config/qtile/xinitrc
+```
 
 `startx` deals with multiple X sessions automatically. If you want to use
 `xinit` instead, you need to first copy `/etc/X11/xinit/xserverrc` to
 `~/.xserverrc`; when launching it, you have to specify a new session number:
 
-.. code-block:: bash
-
-  xinit ~/.config/qtile/xinitrc -- :1
+``` bash
+xinit ~/.config/qtile/xinitrc -- :1
+```
 
 Examples of custom X startup scripts are available in `qtile-examples
 <https://github.com/qtile/qtile-examples>`_.