doc/languages-frameworks/*: add missing languages to code fences

convert shell -> ShellSession

7 files changed, 57 insertions, 56 deletions

diff --git a/doc/languages-frameworks/agda.section.md b/doc/languages-frameworks/agda.section.md
index f57b194a726..30a266502bf 100644
--- a/doc/languages-frameworks/agda.section.md
+++ b/doc/languages-frameworks/agda.section.md
@@ -3,7 +3,7 @@
 ## How to use Agda
 
 Agda can be installed from `agda`:
-```
+```ShellSession
 $ nix-env -iA agda
 ```
 
@@ -15,13 +15,13 @@ To use Agda with libraries, the `agda.withPackages` function can be used. This f
 
 For example, suppose we wanted a version of Agda which has access to the standard library. This can be obtained with the expressions:
 
-```
+```nix
 agda.withPackages [ agdaPackages.standard-library ]
 ```
 
 or
 
-```
+```nix
 agda.withPackages (p: [ p.standard-library ])
 ```
 
@@ -32,7 +32,7 @@ If you want to use a library in your home directory (for instance if it is a dev
 Agda will not by default use these libraries. To tell Agda to use the library we have some options:
 
 * Call `agda` with the library flag:
-```
+```ShellSession
 $ agda -l standard-library -i . MyFile.agda
 ```
 * Write a `my-library.agda-lib` file for the project you are working on which may look like:
@@ -49,7 +49,7 @@ More information can be found in the [official Agda documentation on library man
 Agda modules can be compiled with the `--compile` flag. A version of `ghc` with `ieee754` is made available to the Agda program via the `--with-compiler` flag.
 This can be overridden by a different version of `ghc` as follows:
 
-```
+```nix
 agda.withPackages {
   pkgs = [ ... ];
   ghc = haskell.compiler.ghcHEAD;
@@ -80,12 +80,12 @@ By default, Agda sources are files ending on `.agda`, or literate Agda files end
 ## Adding Agda packages to Nixpkgs
 
 To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/development/libraries/agda/${library-name}/` and an entry should be added to `pkgs/top-level/agda-packages.nix`. Here it is called in a scope with access to all other Agda libraries, so the top line of the `default.nix` can look like:
-```
+```nix
 { mkDerivation, standard-library, fetchFromGitHub }:
 ```
 and `mkDerivation` should be called instead of `agdaPackages.mkDerivation`. Here is an example skeleton derivation for iowa-stdlib:
 
-```
+```nix
 mkDerivation {
   version = "1.5.0";
   pname = "iowa-stdlib";
diff --git a/doc/languages-frameworks/dotnet.section.md b/doc/languages-frameworks/dotnet.section.md
index c3947042494..36369fd4e63 100644
--- a/doc/languages-frameworks/dotnet.section.md
+++ b/doc/languages-frameworks/dotnet.section.md
@@ -4,7 +4,7 @@
 
 For local development, it's recommended to use nix-shell to create a dotnet environment:
 
-```
+```nix
 # shell.nix
 with import <nixpkgs> {};
 
@@ -20,7 +20,7 @@ mkShell {
 
 It's very likely that more than one sdk will be needed on a given project. Dotnet provides several different frameworks (E.g dotnetcore, aspnetcore, etc.) as well as many versions for a given framework. Normally, dotnet is able to fetch a framework and install it relative to the executable. However, this would mean writing to the nix store in nixpkgs, which is read-only. To support the many-sdk use case, one can compose an environment using `dotnetCorePackages.combinePackages`:
 
-```
+```nix
 with import <nixpkgs> {};
 
 mkShell {
@@ -37,7 +37,7 @@ mkShell {
 
 This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
 
-```
+```ShellSesssion
 $ dotnet --info
 .NET Core SDK (reflecting any global.json):
  Version:   3.1.101
diff --git a/doc/languages-frameworks/idris.section.md b/doc/languages-frameworks/idris.section.md
index 41e4f7ec312..000e3627d70 100644
--- a/doc/languages-frameworks/idris.section.md
+++ b/doc/languages-frameworks/idris.section.md
@@ -4,7 +4,7 @@
 
 The easiest way to get a working idris version is to install the `idris` attribute:
 
-```
+```ShellSesssion
 $ # On NixOS
 $ nix-env -i nixos.idris
 $ # On non-NixOS
@@ -21,7 +21,7 @@ self: super: {
 
 And then:
 
-```
+```ShellSesssion
 $ # On NixOS
 $ nix-env -iA nixos.myIdris
 $ # On non-NixOS
@@ -29,7 +29,7 @@ $ nix-env -iA nixpkgs.myIdris
 ```
 
 To see all available Idris packages:
-```
+```ShellSesssion
 $ # On NixOS
 $ nix-env -qaPA nixos.idrisPackages
 $ # On non-NixOS
@@ -37,7 +37,7 @@ $ nix-env -qaPA nixpkgs.idrisPackages
 ```
 
 Similarly, entering a `nix-shell`:
-```
+```ShellSesssion
 $ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
 ```
 
@@ -45,14 +45,14 @@ $ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruvi
 
 To have access to these libraries in idris, call it with an argument `-p <library name>` for each library:
 
-```
+```ShellSesssion
 $ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
 [nix-shell:~]$ idris -p contrib -p pruviloj
 ```
 
 A listing of all available packages the Idris binary has access to is available via `--listlibs`:
 
-```
+```ShellSesssion
 $ idris --listlibs
 00prelude-idx.ibc
 pruviloj
@@ -105,7 +105,7 @@ build-idris-package  {
 
 Assuming this file is saved as `yaml.nix`, it's buildable using
 
-```
+```ShellSesssion
 $ nix-build -E '(import <nixpkgs> {}).idrisPackages.callPackage ./yaml.nix {}'
 ```
 
@@ -121,7 +121,7 @@ with import <nixpkgs> {};
 
 in another file (say `default.nix`) to be able to build it with
 
-```
+```ShellSesssion
 $ nix-build -A yaml
 ```
 
@@ -133,7 +133,7 @@ Specifically, you can set `idrisBuildOptions`, `idrisTestOptions`, `idrisInstall
 
 For example you could set
 
-```
+```nix
 build-idris-package {
   idrisBuildOptions = [ "--log" "1" "--verbose" ]
 
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
index 26458c3906e..4c69f9c85cf 100644
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@@ -78,7 +78,7 @@ $ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'
 By default `nix-shell` will start a `bash` session with this interpreter in our
 `PATH`, so if we then run:
 
-```
+```Python console
 [nix-shell:~/src/nixpkgs]$ python3
 Python 3.8.1 (default, Dec 18 2019, 19:06:26)
 [GCC 9.2.0] on linux
@@ -89,7 +89,7 @@ Type "help", "copyright", "credits" or "license" for more information.
 Note that no other modules are in scope, even if they were imperatively
 installed into our user environment as a dependency of a Python application:
 
-```
+```Python console
 >>> import requests
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
@@ -145,8 +145,8 @@ print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
 Executing this script requires a `python3` that has `numpy`. Using what we learned
 in the previous section, we could startup a shell and just run it like so:
 
-```
-nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
+```ShellSesssion
+$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
 The dot product of [1 2] and [3 4] is: 11
 ```
 
diff --git a/doc/languages-frameworks/qt.section.md b/doc/languages-frameworks/qt.section.md
index 9747c1037ad..6f8c9626e6d 100644
--- a/doc/languages-frameworks/qt.section.md
+++ b/doc/languages-frameworks/qt.section.md
@@ -103,7 +103,7 @@ supported Qt version.
 ### Example adding a Qt library {#qt-library-all-packages-nix}
 
 The following represents the contents of `qt5-packages.nix`.
-```
+```nix
 {
   # ...
 
@@ -133,7 +133,7 @@ to select the Qt 5 version used for the application.
 ### Example adding a Qt application {#qt-application-all-packages-nix}
 
 The following represents the contents of `qt5-packages.nix`.
-```
+```nix
 {
   # ...
 
@@ -144,7 +144,7 @@ The following represents the contents of `qt5-packages.nix`.
 ```
 
 The following represents the contents of `all-packages.nix`.
-```
+```nix
 {
   # ...
 
diff --git a/doc/languages-frameworks/rust.section.md b/doc/languages-frameworks/rust.section.md
index 7789ef857ee..882eb9c4afa 100644
--- a/doc/languages-frameworks/rust.section.md
+++ b/doc/languages-frameworks/rust.section.md
@@ -2,13 +2,14 @@
 
 To install the rust compiler and cargo put
 
-```
-rustc
-cargo
+```nix
+environment.systemPackages = [
+  rustc
+  cargo
+];
 ```
 
-into the `environment.systemPackages` or bring them into
-scope with `nix-shell -p rustc cargo`.
+into your `configuration.nix` or bring them into scope with `nix-shell -p rustc cargo`.
 
 For other versions such as daily builds (beta and nightly),
 use either `rustup` from nixpkgs (which will manage the rust installation in your home directory),
@@ -18,7 +19,7 @@ or use Mozilla's [Rust nightlies overlay](#using-the-rust-nightlies-overlay).
 
 Rust applications are packaged by using the `buildRustPackage` helper from `rustPlatform`:
 
-```
+```nix
 { lib, rustPlatform }:
 
 rustPlatform.buildRustPackage rec {
@@ -49,7 +50,7 @@ package. `cargoHash256` is used for traditional Nix SHA-256 hashes,
 such as the one in the example above. `cargoHash` should instead be
 used for [SRI](https://www.w3.org/TR/SRI/) hashes. For example:
 
-```
+```nix
   cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
 ```
 
@@ -59,13 +60,13 @@ expression and building the package once. The correct checksum can
 then be taken from the failed build. A fake hash can be used for
 `cargoSha256` as follows:
 
-```
+```nix
   cargoSha256 = lib.fakeSha256;
 ```
 
 For `cargoHash` you can use:
 
-```
+```nix
   cargoHash = lib.fakeHash;
 ```
 
@@ -255,7 +256,7 @@ Otherwise, some steps may fail because of the modified directory structure of `t
 source code in a reproducible way. If it is missing or out-of-date one can use
 the `cargoPatches` attribute to update or add it.
 
-```
+```nix
 rustPlatform.buildRustPackage rec {
   (...)
   cargoPatches = [
@@ -481,7 +482,7 @@ an example for a minimal `hello` crate:
 
 Now, the file produced by the call to `carnix`, called `hello.nix`, looks like:
 
-```
+```nix
 # Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
 { stdenv, buildRustCrate, fetchgit }:
 let kernel = stdenv.buildPlatform.parsed.kernel.name;
@@ -510,7 +511,7 @@ dependencies, for instance by adding a single line `libc="*"` to our
 `Cargo.lock`. Then, `carnix` needs to be run again, and produces the
 following nix file:
 
-```
+```nix
 # Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
 { stdenv, buildRustCrate, fetchgit }:
 let kernel = stdenv.buildPlatform.parsed.kernel.name;
@@ -565,7 +566,7 @@ Some crates require external libraries. For crates from
 Starting from that file, one can add more overrides, to add features
 or build inputs by overriding the hello crate in a seperate file.
 
-```
+```nix
 with import <nixpkgs> {};
 ((import ./hello.nix).hello {}).override {
   crateOverrides = defaultCrateOverrides // {
@@ -585,7 +586,7 @@ derivation depend on the crate's version, the `attrs` argument of
 the override above can be read, as in the following example, which
 patches the derivation:
 
-```
+```nix
 with import <nixpkgs> {};
 ((import ./hello.nix).hello {}).override {
   crateOverrides = defaultCrateOverrides // {
@@ -606,7 +607,7 @@ dependencies. For instance, to override the build inputs for crate
 `libc` in the example above, where `libc` is a dependency of the main
 crate, we could do:
 
-```
+```nix
 with import <nixpkgs> {};
 ((import hello.nix).hello {}).override {
   crateOverrides = defaultCrateOverrides // {
@@ -622,27 +623,27 @@ general. A number of other parameters can be overridden:
 
 - The version of rustc used to compile the crate:
 
-  ```
+  ```nix
   (hello {}).override { rust = pkgs.rust; };
   ```
 
 - Whether to build in release mode or debug mode (release mode by
   default):
 
-  ```
+  ```nix
   (hello {}).override { release = false; };
   ```
 
 - Whether to print the commands sent to rustc when building
   (equivalent to `--verbose` in cargo:
 
-  ```
+  ```nix
   (hello {}).override { verbose = false; };
   ```
 
 - Extra arguments to be passed to `rustc`:
 
-  ```
+  ```nix
   (hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
   ```
 
@@ -654,7 +655,7 @@ general. A number of other parameters can be overridden:
   `postInstall`. As an example, here is how to create a new module
   before running the build script:
 
-  ```
+  ```nix
   (hello {}).override {
     preConfigure = ''
        echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
@@ -668,7 +669,7 @@ One can also supply features switches. For example, if we want to
 compile `diesel_cli` only with the `postgres` feature, and no default
 features, we would write:
 
-```
+```nix
 (callPackage ./diesel.nix {}).diesel {
   default = false;
   postgres = true;
@@ -691,7 +692,7 @@ Using the example `hello` project above, we want to do the following:
 
 A typical `shell.nix` might look like:
 
-```
+```nix
 with import <nixpkgs> {};
 
 stdenv.mkDerivation {
@@ -713,7 +714,7 @@ stdenv.mkDerivation {
 ```
 
 You should now be able to run the following:
-```
+```ShellSesssion
 $ nix-shell --pure
 $ cargo build
 $ cargo test
@@ -723,7 +724,7 @@ $ cargo test
 To control your rust version (i.e. use nightly) from within `shell.nix` (or
 other nix expressions) you can use the following `shell.nix`
 
-```
+```nix
 # Latest Nightly
 with import <nixpkgs> {};
 let src = fetchFromGitHub {
@@ -751,7 +752,7 @@ stdenv.mkDerivation {
 ```
 
 Now run:
-```
+```ShellSession
 $ rustc --version
 rustc 1.26.0-nightly (188e693b3 2018-03-26)
 ```
@@ -786,7 +787,7 @@ in the `~/.config/nixpkgs/overlays` directory.
 
 Add the following to your `configuration.nix`, `home-configuration.nix`, `shell.nix`, or similar:
 
-```
+```nix
 { pkgs ? import <nixpkgs> {
     overlays = [
       (import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz))
diff --git a/doc/languages-frameworks/vim.section.md b/doc/languages-frameworks/vim.section.md
index 155dacc237b..22b5e6f3013 100644
--- a/doc/languages-frameworks/vim.section.md
+++ b/doc/languages-frameworks/vim.section.md
@@ -156,7 +156,7 @@ assuming that "using latest version" is ok most of the time.
 
 First create a vim-scripts file having one plugin name per line. Example:
 
-```
+```vim
 "tlib"
 {'name': 'vim-addon-sql'}
 {'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']}
@@ -197,7 +197,7 @@ nix-shell -p vimUtils.vim_with_vim2nix --command "vim -c 'source generate.vim'"
 You should get a Vim buffer with the nix derivations (output1) and vam.pluginDictionaries (output2).
 You can add your Vim to your system's configuration file like this and start it by "vim-my":
 
-```
+```nix
 my-vim =
   let plugins = let inherit (vimUtils) buildVimPluginFrom2Nix; in {
     copy paste output1 here
@@ -217,7 +217,7 @@ my-vim =
 
 Sample output1:
 
-```
+```nix
 "reload" = buildVimPluginFrom2Nix { # created by nix#NixDerivation
   name = "reload";
   src = fetchgit {
@@ -248,7 +248,7 @@ Nix expressions for Vim plugins are stored in [pkgs/misc/vim-plugins](/pkgs/misc
 
 Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](/pkgs/misc/vim-plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
 
-```
+```nix
 deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
   dependencies = with super; [ deoplete-nvim vim-fish ];
 });