docs: fix typos, unpublish git tutorial

2023-10-27 16:18:11 +02:00 · 2023-10-27 16:18:11 +02:00 · dc4a053369
commit dc4a053369
parent 6ea381e7c2
1 changed files with 44 additions and 781 deletions
--- a/content-org/blog.org
+++ b/content-org/blog.org
@ -45,24 +45,24 @@ now free as in /free beer/ and in /freedom/.
 #+end_center
 You can find the installer of ALYS for Alter/Ego on the repository
-linked above as well as a free license file. Regarding its UTAU
+linked above as well as a free licence file. Regarding its UTAU
 version, its prototype is already configured with ~oto.ini~ files, but
 the source file for its Alter/Ego version are stripped of any
 configuration.
 ** What’s New?
 Therefore, ALYS is now available under three different licences:
- The character is now under the free [[https://creativecommons.org/licenses/by-nc/4.0/][CC-BY-NC-4.0 license]]
+- The character is now under the free [[https://creativecommons.org/licenses/by-nc/4.0/][CC-BY-NC-4.0 licence]]
 - The UTAU vocal libraries are now under the [[https://www.gnu.org/licenses/gpl-3.0.en.html][GPL-3.0license ]] ([[https://choosealicense.com/licenses/gpl-3.0/][short
  readable version]])
- The Alter/Ego is still under a proprietary license under my name but
+- The Alter/Ego is still under a proprietary licence under my name, but
  it is now available free of charge
 Basically, this means you can do whatever you wish with the character
-as long as it is non-commercial and you credit [[https://www.instagram.com/hsaphirya/][Saphirya]], ALYS’
+as long as it is non-commercial, and you credit [[https://www.instagram.com/hsaphirya/][Saphirya]], ALYS’
 designer. The UTAU vocal libraries can be used, modified, and
 redistributed as much as you wish as long as it stays under the
-GPL-3.0 license. And you are free to use the Alter/Ego vocal libraries
+GPL-3.0 licence. And you are free to use the Alter/Ego vocal libraries
 as much as you wish, but you cannot redistribute or modify them.
 I also decided to release ALYS’ very first, secret, unreleased,
@ -72,7 +72,7 @@ people could hear through ALYS’ first songs. It is released more as a
 way of preserving the fact it existed rather preserving a usable vocal
 library. (I don’t even remember what it sounds like.)
-if you have any question, you are free to send me an email at
+If you have any question, you are free to email me at
 [[mailto:lucien@phundrak.com][lucien@phundrak.com]] or open an issue on the repository mentioned
 above.
 * Conlanging                                                       :@conlang:
@ -253,6 +253,12 @@ Maintenant, au travail !
 :EXPORT_DATE: 2020-11-28
 :export_hugo_menu: :menu "main"
 :END:
 /Edit on October 28th 2023:/ This article was written on November 28th
 2020, almost three years ago. Since then, I have noticed issues with
 the current implementation of my dynamic C array, as noted by some
 readers in the comments below. I will probably rewrite a new dynamic
 array in C some time in the future addressing these issues.
 Although C is a very, very popular language, it is also known to be
 quite tiny: memory is handled manually, and much of what is available
 in its standard library is a given in all other languages. But C being
@ -428,11 +434,11 @@ to take new data from the user. But first, let me explain a bit how
 this dynamic array which I call vector works in C.
 As you saw earlier, a vector is initialized with a fixed amount of
-memory allocated to the vector so people can store their data in these
+memory allocated to the vector, so people can store their data in
-arrays. Now, imagine you have an array of four elements and you wish
+these arrays. Now, imagine you have an array of four elements, and you
-to add one more, what to do? You can reallocate your array with
+wish to add one more, what to do? You can reallocate your array with
 ~realloc~ with one more slot for your element, so now you have an array
-for five elements with your four original elements an a free slot for
+for five elements with your four original elements and a free slot for
 your fifth. Cool, now you can add new elements as you need them!
 Except that if you want to add some tens of thousands of new elements,
@ -466,7 +472,7 @@ static void vec_realloc(Vector *const self) NONNULL;
 Its implementation is rather simple: double its capacity, and
 reallocate its array twice its previous size. Of course, there is an
-assertion on whether the arrays has been correctly reallocated to
+assertion on whether the arrays have been correctly reallocated to
 ensure memory safety.
 #+NAME: vector-vec_realloc-c
 #+BEGIN_SRC c
@ -509,7 +515,7 @@ And this is it! There may be a function added later that will allow
 the insertion of a new value in any valid position between the first
 and last position of an array (not counting the unused slots of said
 array), and if I implement this it will imply a reimplementation of
-~vec_push~ so that ~vec_push~ relies of this potential new ~vec_insert~.
+~vec_push~ so that ~vec_push~ relies on this potential new ~vec_insert~.
 *** Retrieving Data
 Two functions are available when retrieving data: ~vec_safe_at~ which
@ -569,7 +575,7 @@ void *vec_last(Vector const *const self)
 }
 #+END_SRC
-For the sake of the Object Oriented Programming paradigm, two
+For the sake of the Object-Oriented Programming paradigm, two
 functions were also declared in order to retrieve some data that could
 otherwise be easily accessible:
 #+NAME: vector-vec_length_capacity-h
@ -649,7 +655,7 @@ static void vec_maybe_delete_element(Vector const *self,
 Its implementation is quite simple: if a destructor exists, then the
 element at the requested index will be destroyed through this
 destructor. Otherwise, nothing is done with the destructor, hence the
-name of the function ~vec_maybe_delete_element~. However it should be
+name of the function ~vec_maybe_delete_element~. However, it should be
 noted that the element will be freed from memory, so if the user needs
 it before popping it, they need to retrieve it with something like
 ~vec_at~ and store it elsewhere.
@ -683,7 +689,7 @@ void vec_pop_at(Vector *const t_self, size_t const t_index)
 }
 #+END_SRC
-A check is performed at the beninning of the function: that the
+A check is performed at the beginning of the function: that the
 element we want to pop actually exists. If it does not, the function
 does nothing, otherwise the function deletes the element if needed.
 The call to ~vec_maybe_delete_element~ will free the requested element.
@ -826,7 +832,7 @@ the ones that stand out the most for me.
 During the last couple of years, LSP has given text editors incredible
 capabilities, giving them IDE-like features relatively easily. Aside
 from Elisp development, most of the code I write is now done with the
-help of an LSP server, running along Emacs and analyzing my code,
+help of an LSP server, running along Emacs and analysing my code,
 suggesting and performing changes and actions for me.
 Several integrations of LSP exist for Emacs, such as [[https://emacs-lsp.github.io/lsp-mode/][LSP Mode]], [[https://github.com/joaotavora/eglot][Eglot]],
@ -872,9 +878,9 @@ Tree-Sitter supports the current major modes :
 - ~typescript-ts-mode~
 Tree-Sitter also holds for now a special status in the new ~emacs-29~
-branch since new features can still be added to it, as its merging
+branch since new features can still be added to it, as its merge with
-with the master branch is still recent. So we might see the list of
+the master branch is still recent. So we might see the list of major
-major modes for Emacs get a bit longer yet, especially considering
+modes for Emacs get a bit longer yet, especially considering
 Tree-Sitter tries to make adding new languages relatively easy.
 If you can’t wait to test Tree-Sitter, there is already [[https://emacs-tree-sitter.github.io/][another package]]
@ -1087,7 +1093,7 @@ post if you are interested in how I got there.
 **** Update 2021-11-22
 I’ve put the code presented here as a complete package. You can find
-it in [[https://labs.phundrak.com/phundrak/org-unique-id][this repository]] or in its [[https://github.com/Phundrak/org-unique-id][Github mirror]] (be aware the latter may
+it in [[https://labs.phundrak.com/phundrak/org-unique-id][this repository]] or in its [[https://github.com/Phundrak/org-unique-id][GitHub mirror]] (be aware the latter may
 not be as up-to-date as the former is. Installation instructions are
 in the README.
@ -1167,11 +1173,11 @@ removed from ~<head>~):
 </html>
 #+END_SRC
-As you can see, all the anchors are in the fomat of ~org[a-f0-9]{7}~.
+As you can see, all the anchors are in the format of ~org[a-f0-9]{7}~.
 First, this is not really meaningful if you want to read the anchor
 and guess where it will lead you. But secondly, these anchors will
 change each time you export your Org file to HTML. If I want to share
-a URL to my website and to a specific heading,… well I can’t, it will
+a URL to my website and to a specific heading, … well I can’t, it will
 change the next time I update the document. And I don’t want to have
 to set a ~CUSTOM_ID~ property for each one of my headings manually. So,
 what to do?
@ -1183,9 +1189,9 @@ remedy that (it’s a great read, go take a look). And it worked, and
 for some time I used their code in my Emacs configuration file in
 order to generate unique custom IDs for my Org headers. Basically what
 the code does is it detects if ~auto-id:t~ is set in an ~#+OPTIONS~
-header. If it is, then it will iterate over all of the Org headers,
+header. If it is, then it will iterate over all the Org headers, and
-and for each one of them it will insert a ~CUSTOM_ID~, which is made
+for each one of them it will insert a ~CUSTOM_ID~, which is made from a
-from a UUID generated by Emacs. And tada! we get for each header a
+UUID generated by Emacs. And tadah! we get for each header a
 ~h-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}~ custom
 ID that won’t change next time we export our Org file to HTML when we
 save our file, and only for headings which don’t already have a
@ -1194,8 +1200,8 @@ save our file, and only for headings which don’t already have a
 Except…
 *** These headers are not meaningful
-Ok, alright, that’s still a huge step forward, we don’t have to type
+OK, alright, that’s still a huge step forward, we don’t have to type
-any ~CUSTOM_ID~ property manually anymore, it’s done automatically for
+any ~CUSTOM_ID~ property manually any more, it’s done automatically for
 us. But, when I send someone a link like
 ~https://langue.phundrak.com/eittland#h-76fc0b91-e41c-42ad-8652-bba029632333~,
 the first reaction to this URL is often something along the lines of
@ -1203,7 +1209,8 @@ the first reaction to this URL is often something along the lines of
 comes to the anchor. How am I supposed to guess it links to the
 description of the vowels of the Eittlandic language? (That’s a
 constructed language I’m working on, you won’t find anything about it
-outside my website.)
+outside my website. Also, this link is dead now, it got simplified
 thanks to Vuepres.)
 So, I went back to my configuration file for Emacs, and through some
 trial and error, I finally found a way to get a consistent custom ID
@ -1343,750 +1350,6 @@ ID on each save, regardless of whether a custom ID already exists or
 not, but it’s at the risk an ID manually set will get overwritten.
 * Linux                                                              :@linux:
 ** [Fr] Tutoriel Git et Github                  :linux:git:tutorial:tutoriel:
 :PROPERTIES:
 :EXPORT_FILE_NAME: tutoriel-git-et-github
 :EXPORT_DATE: 2020-06-05
 :export_hugo_menu: :menu "main"
 :END:
 #+TOC: headlines 1 local
 *** Git ? Qu'est-ce donc ?
 Git est un logiciel de version de fichiers permettant de garder une
 trace de toutes les modifications apportées au fichiers suivis dans un
 répertoire (un dépôt) et ses sous-répertoires –sous couvert qu’ils
 n’aient pas été ignorés explicitement. Il permet également de
 conserver plusieurs versions parallèles du projet, comme par exemple
 une version stable et une version de développement, et permet l’ajout
 de modifications d’une de ces versions parallèles à une autre via des
 fusions partielles ou totales de branches, avec une automatisation des
 fusions de fichiers lorsqu’il n’y a pas de conflit entre ces derniers.
 Avant de continuer, sache que je suis bilingue français-sarcasme, si
 tu es du genre à t’énerver pour un rien, cette page est à haut risque
 pour toi.
 Toujours là ? Tu auras été prévenu·e.
 *** Ça a l’air cool, comment ça s’obtient ?
 **** Et surtout, comment ça s’installe ?
 Très bonne question Kevin. Tout d’abord, il faut t’assurer que git
 soit installé sur ton système et utilisable depuis le terminal. Sous
 GNU/Linux, tu peux l’installer via ton gestionnaire de paquet, ce qui
 rendra la commande accessible directement depuis le terminal. Tu auras
 sans doute besoin de préfixer la commande avec ~sudo~. Si tu n’as pas
 les droits pour utiliser ~sudo~, demande à celui qui a les droits (ton
 administrateur système ou ton papa (j’avais prévenu que je n’allais
 pas être sympa dans ce tutoriel)).
 #+BEGIN_SRC sh
 $ apt install git                    # Debian, Ubuntu et les distros basées dessus
 $ yum install git                    # CentOS
 $ dnf -y install git                 # Fedora
 $ pacman -S git                      # ArchLinux et les distros basées dessus
 $ emerge --ask --verbose dec-vcs/git # Gentoo
 #+END_SRC
 #+CAPTION: >install gentoo
 [[./img/install-gentoo.jpg]]
 Si tu n’es pas sous GNU/Linux mais que tu as au moins le goût d’être
 sous un OS de type Unix, tu peux exécuter la commande correspondante à
 ton OS suivant :
 #+BEGIN_SRC sh
 $ pkg install git                                     # FreeBSD
 $ brew install git                                    # macOS avec brew
 $ port install git +svn +doc +bash_completion +gitweb # macOS avec MacPorts
 #+END_SRC
 Si tu es sous Windows, soit tu utilises le WSL (Windows Subsystem for
 Linux), soit… bonne chance. Toutes les commandes seront en syntaxe
 Unix dans ce tutoriel, mais si tu as bien deux neurones, tu devrais
 pouvoir tout de même suivre le tutoriel.
 **** Ok c’est bon, et il y a une configuration à faire ?
 Tu peux configurer Git si tu le souhaites, oui. En général, il est
 recommandé de paramétrer au moins son nom et son e-mail. Tu peux les
 paramétrer via la ligne de commande :
 #+BEGIN_SRC sh
 $ git config --global user.name "Kévin Masturbin"
 $ git config --global user.email "kevin.du.neuftrwa@hotmail.com"
 #+END_SRC
 Tu peux aussi éditer le fichier =~/.gitconfig= comme suit :
 #+BEGIN_SRC toml
 [user]
     email = ton@email.truc
     name = Ton nom
 #+END_SRC
 Cela permettra d’associer ton nom et ton adresse mail à tes commits.
 Par défaut, ceux qui sont enregistrés avec ton compte utilisateur de
 ton PC sont mis par défaut dans ces paramètres, mais on met quasiment
 tous un nom à la con quand on le créé. Et ça permet d’avoir les même
 paramètres si tu es sur un autre ordinateur.
 Il y a encore pas mal de paramètres que tu peux gérer avec ce fichier,
 je reparlerai de certains plus tard, mais pour le reste, la
 documentation en ligne sur ~gitconfig~ ne manque pas.
 *** Ok très bien, comment on l’utilise maintenant ?
 Du calme Jean-Kevin, ralentis un peu. Comme le dit ce vieux dicton
 Chinois :
 #+begin_quote
 Celui qui marche  trop vite…… marche…………… trop… vite…?  C’est compliqué les
 dictons chinois…
 #+end_quote
 De toutes façons, ce dicton est une contrefaçon, donc la qualité de la
 citation n’est pas extraordinaire. Bref.
 **** Je commence comment ?
 Si tu souhaites créer un dépôt git, rien de plus simple : créé ton
 répertoire dans lequel tu travailleras, et déplace-y-toi. Ensuite, tu
 pourra initialiser ton dépôt via la commande ~git init~.
 #+BEGIN_SRC text
 $ mkdir monsuperprojet
 $ cd monsuperprojet
 $ git init
 Initialized empty Git repository in /tmp/monsuperprojet/.git/
 #+END_SRC
 Si tu obtiens à peu près le même message après la dernière commande,
 félicitations ! Tu viens de créer ton premier dépôt git. En
 l’occurrence, j’ai créé mon dépôt dans ~/tmp~, mais toi tu peux voir un
 truc du genre ~/home/corentin/monsuperprojet~ à la place. Tu peux
 vérifier que tout va bien en rentrant la commande ~git status~.
 #+BEGIN_SRC text
 $ git status
 On branch master
 No commits yet
 nothing to commit (create/copy files and use "git add" to track)
 #+END_SRC
 Parfait ! Ah, et ne met rien d’important dans ~/tmp~, ce dossier est
 réinitialisé à chaque redémarrage de ta machine. Ou alors, met-y
 uniquement des fichiers que tu ne souhaites avoir que temporairement
 sur ta machine (comme ce meme que tu télécharges depuis Reddit pour le
 reposter sur Discord).
 **** Et pour rajouter des fichiers ?
 Maintenant tu peux commencer à travailler sur ton projet. Mais tout
 d’abord, on va voir ce qu’il se passe si jamais on créé un fichier
 dans le dépôt. Créé un fichier ~main.c~ dans lequel tu vas entrer ce
 code :
 #+BEGIN_SRC c
 #include <stdio.h>
 int main(int ac, char* av[]) {
  printf("Hello World!\n");
  return 0;
 }
 #+END_SRC
 Bref, si tu exécutes à nouveau git status, tu obtients cette sortie :
 #+BEGIN_SRC text
 $ git status
 On branch master
 No commits yet
 Untracked files:
  (use "git add <file>..." to include in what will be committed)
        main.c
 nothing added to commit but untracked files present (use "git add" to track)
 #+END_SRC
 Tu commences à comprendre un peu le bail ? Git vient de détecter qu’un
 nouveau fichier a été créé qu’il ne connaissait pas avant. Suivons ses
 bon conseils et ajoutons le fichier au dépôt.
 #+BEGIN_SRC text
 $ git add main.c
 $ git status
 On branch master
 No commits yet
 Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   main.c
 #+END_SRC
 Super, maintenant git va surveiller les changements du fichier, mais
 attention, il n’a pas encore enregistré son état. Pour l’instant il
 sait juste que le fichier est là, dans un certain état, mais rien ne
 garanti encore qu’on pourra retrouver cet état plus tard. On appelle
 ça le /staging/. Pour ce faire, il faut créer ce qu’on appelle un
 /commit/. En gros, il s’agit d’un enregistrement des modifications
 apportées à un ou plusieurs fichiers (dans leur globalité ou
 partiellement, on verra ça plus tard), le tout avec un commentaire.
 #+BEGIN_SRC text
 $ git commit -m "Un petit pas pour moi, un grand pas pour mon projet"
 [master (root-commit) 89139ef] Un petit pas pour moi, un grand pas pour mon projet
 1 file changed, 6 insertions(+)
 create mode 100644 main.c
 #+END_SRC
 Parfait ! Certains éléments peuvent être un peu différent chez toi,
 comme par exemple la référence du commit juste avant le message. Ça,
 c’est un truc qui est géré automatiquement par git. Et voilà, on a
 l’état de notre répertoire qui est enregistré et qui sera disponible
 plus tard. Maintenant, tu sais comment enregistrer des état de ton
 dépôt via les commits.
 **** Cool, mais j’ai accidentellement mis un fichier en staging
 Si jamais tu as un staging que tu veux annuler, tu peux utiliser la
 commande ~git reset HEAD nomdufichier~ (ou plusieurs noms de fichiers)
 pour annuler le staging. Une fois le fichier qui n’est plus dans ton
 staging, tu peux même annuler toutes les modifications que tu as
 apporté au fichier depuis ton dernier commit avec la commande ~git
 checkout -- nomdufichier~, et tu peux aussi mettre plusieurs noms de
 fichiers. Par exemple, si j’ai modifié mon ~main.c~ en modifiant ainsi
 les arguments du ~main()~ :
 #+BEGIN_SRC c
 #include <stdio.h>
 int main(void) {
  printf("Hello World!\n");
  return 0;
 }
 #+END_SRC
 Je peux annuler tout ça via ces commandes :
 #+BEGIN_SRC text
 $ git reset HEAD main.c
 Unstaged changes after reset:
 M       main.c
 $ git checkout -- main.c
 $ git status
 On branch master
 nothing to commit, working tree clean
 #+END_SRC
 Si je fait un ~cat main.c~, je vois qu’il est revenu à son état initial.
 Et petite remarque concernant les arguments de la fonction ~main~ en C :
 on peut leur donner le nom que l’on souhaite (personellement j’aime
 bien parfois metre ~ac~ et ~av~ au lieu de ~argc~ et ~argv~), ça ne changera
 strictement rien au comportement du code. Et si l’on ne souhaite pas
 utiliser les arguments reçus par le ~main~, on peut simplement déclarer
 la fonction main comme ~main(void)~. Au moins, c’est clair pour le
 compilateur et le lecteur du code : on s’en fiche des arguments du
 ~main~.
 Par contre, chose importante : mettre void en arguments du main est du
 C, *et ce n’est pas valide en C++*. /Le C++ n’est pas du C avec des
 fonctionnalités en plus/.
 **** En fait, j’ai juste oublié un truc dans mon commit précédent
 Si jamais tu veux à la place ajouter la modification d’un fichier au
 dernier commit (mettons, tu as oublié d’ajouter également un fichier
 texte), tu peux utiliser l’option ~--amend~ lors du commit du fichier
 oublié.
 #+BEGIN_SRC text
 $ git add main.c # J’ai refait les modifications annulées plus tôt
 $ git commit -m "second commit"
 [master 97f698a] second commit
 1 file changed, 1 insertion(+), 1 deletion(-)
 $ echo "C’est un super projet !" > projet.txt
 $ git add projet.txt
 $ git commit --amend -m "second commit + oubli"
 [master 9aff4c0] second commit + oubli
 Date: Fri Oct 5 11:10:56 2018 +0200
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 projet.txt
 #+END_SRC
 En gros, le commit que tu viens de faire a remplacé le précédent en
 conservant les informations du commit précédent, mis à part son
 commentaire. Si tu ne met pas l’option ~-m "ton texte"~ lors de
 l’amendement du commit, ton éditeur texte par défaut va s’ouvrir pour
 que tu puisses modifier le texte du commit précédent si tu le
 souhaite. Si jamais vim s’ouvre et que tu n’as aucune idée de comment
 sortir de cet enfant du démon, tu as juste à appuyer sur la touche
 Échap (au cas où), puis à taper ~:wq~ (~w~ pour écrire le fichier, ~q~ pour
 quitter), puis tu appuie sur la touche Entrée. Si tu as Nano qui s’est
 ouvert, alors il faut taper Ctrl-X. Dans tous les cas, tu aurais dû
 utiliser Emacs.
 **** Euh, j’ai oublié ce que j’ai changé lors du dernier commit
 Pas de panique ! Tu peux entrer la commande ~git diff~ afin de voir ce
 que tout ce que tu as modifié lors de ton dernier commit. Et si tu ne
 souhaite voir les modifications que d’un certain fichier, tu peux
 ajouter le nom de ton fichier à la fin de la commande.
 #+BEGIN_SRC text
 $ echo "C’est un super projet !" > projet.txt
 $ git diff
 diff --git a/projet.txt b/projet.txt
 index 03b0f20..b93413f 100644
 --- a/projet.txt
 +++ b/projet.txt
@@ -1 +1 @@
 -projet
 +C’est un super projet !
 #+END_SRC
 Tu peux également voir les différences de fichiers entre deux commits
 en entrant leur référence. Pour avoir la référence, tu peux rentrer la
 commande ~git log~ pour avoir un petit historique des commits.
 #+BEGIN_SRC text
 $ git log
 commit 4380d8717261644b81a1858920406645cf409028 (HEAD -> master)
 Author: Phuntsok Drak-pa <phundrak@phundrak.fr>
 Date:   Fri Oct 5 11:59:40 2018 +0200
    new commit
 commit 59c21c6aa7e3ec7edd229f81b87becbc7ec13596
 Author: Phuntsok Drak-pa <phundrak@phundrak.fr>
 Date:   Fri Oct 5 11:10:56 2018 +0200
    nouveau texte
 commit 89139ef233d07a64d3025de47f8b6e8ce7470318
 Author: Phuntsok Drak-pa <phundrak@phundrak.fr>
 Date:   Fri Oct 5 10:56:58 2018 +0200
    Un petit pas pour moi, un grand pas pour mon projet
 #+END_SRC
 Bon, c’est un peu long et un peu trop d’infos d’un coup, généralement
 je préfère taper ~git log --oneline --graph --decorate~ afin d’avoir un
 affichage comme suit :
 #+BEGIN_SRC text
 $ git log --oneline --graph --decorate
 ,* 4380d87 (HEAD -> master) new commit
 ,* 59c21c6 nouveau texte
 ,* 89139ef Un petit pas pour moi, un grand pas pour mon projet
 #+END_SRC
 Plus propre, non ? Et les références sont plus courtes, ce qui est
 plus agréable à taper. Allez, comparons les deux derniers commits.
 #+BEGIN_SRC text
 $ git add .
 $ git commit -m "new commit"
 $ git log --oneline --graph --decorate
 ,* 4380d87 (HEAD -> master) new commit
 ,* 59c21c6 nouveau texte
 ,* 89139ef Un petit pas pour moi, un grand pas pour mon projet
 $ git diff 59c21c6 4380d87
 diff --git a/projet.txt b/projet.txt
 index 03b0f20..b93413f 100644
 --- a/projet.txt
 +++ b/projet.txt
@@ -1 +1 @@
 -projet
 +C’est un super projet !
 #+END_SRC
 **** Il y a des fichiers dont je me fiche dans mon dépôt
 Dans ce cas, il est grand temps de te présenter le fichier ~.gitignore~.
 Comme son nom l’indique, il permet au dépôt d’ignorer des fichiers
 selon ce que tu lui indiqueras. Par exemple, si tu veux ignorer tous
 les fichiers qui se terminent en ~.out~ (ou ~.exe~ sous Windows), tu peux
 éditer (ou créer) ton ~.gitignore~ et entrer ces lignes :
 #+BEGIN_SRC gitignore
 ,*.out
 ,*.exe
 #+END_SRC
 Maintenant, si tu créés un fichier en ~.out~ ou ~.exe~, il sera
 complètement ignoré par git et ne sera pas stocké dans l’historique
 des versions. Il s’agit de ce qu’on appelle du globbing. En gros,
 l’étoile indique que tu t’en fiches de ce qu’il y a devant ~.out~ ou
 ~.exe~ dans cet exemple, si quelque chose se termine par ça, c’est
 ignoré. Pour ignorer quelque chose dans un dossier, tu pourrais avoir
 quelque chose du genre ~mondossier/*~ et POUF, tous les fichiers de
 ~mondossier/~ sont ignorés. En gros, le globbing va fonctionner comme le
 globbing de ton shell (Bash, Zsh, Fish,…)
 Par exemple, [[https://labs.phundrak.com/phundrak/langue-phundrak-com/commit/f8ec1936f839e9e95a6badf4480589f5bc9d00a0][voici un dépôt]] un peu plus complexe que ce qu’on est en
 train de faire (figé lors d’un commit fixé). Tu peux voir dans mon
 ~.gitignore~ qu’il y a pas mal d’extensions de fichiers qui sont
 ignorées, mais j’ai aussi ~_minted*~ et ~auto-generated*~ qui sont des
 dossiers ignorés, et pas juste leur contenu qui est ignoré (l’étoile
 est là pour ignorer tous les dossiers dont le nom commence par ce qui
 précède l’étoile). J’ai aussi ignoré le dossier ~.dart_tool/~ qui lui
 pour le coup n’a pas de globbing, ainsi que le fichier ~pubspec.lock~,
 sans globbing non plus.
 **** On est plusieurs dessus en fait…
 Pas de panique ! Git a été créé pour ça, et il dispose d’une
 fonctionnalité de branchage permettant d’avoir plusieurs versions
 coexistantes d’un même fichier. Cela peut être très utile pour avoir
 soit plusieurs personnes travaillant sur un même projet, soit pour une
 même personne travaillant sur plusieurs fonctionnalités différentes,
 soit les deux. Ainsi, on a plusieurs version indépendantes que l’on
 pourra fusionner plus tard.
 Par défaut une branche est créée lors de la création d’un dépôt qui
 s’appelle ~master~. Pour créer une nouvelle branche, on peut donc
 utiliser la commande ~git checkout -b nomdelanouvellebranche~.
 #+BEGIN_SRC text
 $ git checkout -b nouvelle-branche
 Switched to a new branch 'nouvelle-branche'
 #+END_SRC
 À partir d’ici, toute modification apportée aux fichiers du dépôt
 n’affecteront que la branche courante, ~nouvelle-branche~ donc, et les
 fichiers de la branche ~master~ resteront inchangés. Si jamais tu veux
 retourner pour une quelconque raison sur la branche ~master~, il te
 suffira d’utiliser la commande ~git checkout master~.
 Si tu souhaites avoir une liste des branches du dépôt, tu peux taper
 ~git branch --list~. La branche active sera marquée d’une étoile à côté
 de son nom.
 #+BEGIN_SRC text
 $ git branch --list
  master
 ,* nouvelle-branche
 #+END_SRC
 **** J’ai accidentellement modifié des fichiers sur la mauvaise branche, mais je n’ai pas encore fait de commits.
 Tout va bien alors ! Tu vas simplement exécuter cette commande :
 #+BEGIN_SRC text
 $ git stash
 #+END_SRC
 Ça va déplacer toutes tes modifications que tu n’as pas encore commit
 dans le stash, qui est une sorte d’emplacement temporaire, en dehors
 des branches. Normalement, ça va réinitialiser tes fichiers tels
 qu’ils étaient lors du dernier commit. Maintenant, change la branche
 sur laquelle tu travailles, par exemple tu si tu es sur la branche
 ~kevin~, tu exécutes ceci :
 #+BEGIN_SRC text
 $ git checkout kevin
 #+END_SRC
 Tes modifications sont toujours dans ton stack, et pour les restaurer,
 tu n’as plus qu’à exécuter
 #+BEGIN_SRC text
 $ git stash pop
 #+END_SRC
 Et voilà, tu viens de déplacer tes modifications sur la bonne branche.
 Pour information, si tu as créé un nouveau fichier ou un nouveau
 dossier avec des fichiers, ils ne seront pas déplacés dans le stash,
 mais ils ne seront pas supprimés lors de la première commande. Tu
 auras juste à les commit sur ta nouvelle branche pour qu’ils cessent
 de se déplacer de branche en branche.
 **** Du coup, Mathilde a bien avancé sur son code, et moi aussi, chacun sur notre branche. On fait comment maintenant ?
 Au bout d’un moment, tu vas sans doute vouloir fusionner deux
 branches, par exemple tu as finis de développer une nouvelle
 fonctionnalité sur la branche ~nouvelle-branche~ et tu souhaites
 l’ajouter à la version stable de ton code qui se situe sur ~master~.
 Dans ce cas, ce que tu peux faire, c’est retourner sur ta branche
 ~master~, puis tu vas effectuer ce qu’on appelle un merge ; en gros,
 pour faire simple, tu vas appliquer les modifications de la branche
 que tu souhaites fusionner avec ta branche ~master~ sur cette dernière.
 #+BEGIN_SRC text
 $ git checkout master
 Switched to branch 'master'
 $ git merge nouvelle-branche
 Updating 133c5b6..2668937
 Fast-forward
 projet.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 projet.txt
 #+END_SRC
 Rappelle-toi que la commande ~merge~ ramène les commits de la branche
 spécifiée vers ta branche active, et pas forcément vers le ~master~. Du
 coup, si tu est sur une branche ~mathilde~ et que tu effectues un ~git
 merge leon~, tu vas ramener tous les commits de leon vers la branche
 mathilde. Ça peut être intéressant à faire si jamais un bug a été
 corrigé dans une autre branche ou qu’une fonctionnalité a été ajoutée
 et que tu veux en bénéficier dans ta branche active. N’oublie juste
 pas de tout bien commit avant de faire ton merge.
 *** J’ai entendu parler de Github…
 Tu commences à me plaire Enzo ! Github est un site web sur lequel tu
 peux héberger des projets libres ou open-source (si tu ne connais pas
 la différence, voici un article pour t’aider à comprendre, et un autre
 pour la route). C’est en particulier orienté pour les projets gérés
 par git, ce qui tombe bien car c’est ce qu’on utilise. Cela a pour
 avantage de pouvoir aisément partager ton code et d’assurer qu’il est
 bien sauvegardé quelque part d’autre que ton disque dur (un ~rm -rf~ est
 si vite arrivé). Et surtout, ça peut te permettre de collaborer avec
 d’autres personnes sur le même projet sans te casser la tête.
 #+begin_quote
 Git est à Github ce que le porn est à Pornhub.
 #+end_quote
 J’aimerais tout de même te mettre au courant que Github n’est
 largement pas le seul site de ce genre à exister. Le concurrent le
 plus célèbre de Github est [[https://about.gitlab.com/][Gitlab]], et personnellement j’utilise [[https://gitea.io/en-us/][Gitea]].
 Ces deux derniers peuvent même être hébergés en instances
 personnelles, comme [[https://labs.phundrak.com/phundrak/langue-phundrak-com/commit/f8ec1936f839e9e95a6badf4480589f5bc9d00a0][ce que je fais avec Gitea]] (qui est beaucoup plus
 léger que Gitlab, mais avec quelques fonctionnalités en moins), et il
 existe encore [[https://labs.phundrak.com/phundrak/langue-phundrak-com/commit/f8ec1936f839e9e95a6badf4480589f5bc9d00a0][plein d’autres alternatives]], à toi de trouver les
 autres.
 *** J’ai téléchargé un projet en zip
 Ou bien, tu peux télécharger le projet directement via git. Eh oui !
 git permet de gérer les dépôts dits distants, c’est à dire ceux qui
 sont hébergés sur un serveur en ligne, comme par exemple sur Github.
 Pour cela, il te faut te munir du lien vers le dépôt git, et le passer
 en argument de git clone. Par exemple, si tu veux télécharger de dépôt
 du petit logiciel de chat en réseau que j’ai codé durant ma L2
 d’informatique, tu peux exécuter ceci :
 #+BEGIN_SRC text
 $ git clone https://github.com/noalien/GL4Dummies.git
 Cloning into 'GL4Dummies'...
 remote: Enumerating objects: 682, done.
 remote: Counting objects: 100% (682/682), done.
 remote: Compressing objects: 100% (455/455), done.
 remote: Total 3516 (delta 354), reused 509 (delta 215), pack-reused 2834
 Receiving objects: 100% (3516/3516), 72.95 MiB | 2.13 MiB/s, done.
 Resolving deltas: 100% (2019/2019), done.
 #+END_SRC
 Et c’est bon, tu as accès au répertoire ~GL4Dummies~ et au code source
 du projet. (Courage aux élèves de Paris 8 qui feront de la
 programmation graphique !)
 *** Et si je veux créer mon propre dépôt sur Github
 Dans ce cas là, c’est simple Brigitte. Il faut que tu te créés un
 compte sur Github, puis tu cliques sur le bouton ~+~ et ~New Repository~.
 Tu lui donnes le nom que tu souhaites (en l’occurrence je le nomme
 ~temporary-repo~ car je vais le supprimer cinq minutes après l’écriture
 de ces lignes), et tu cliques sur ~Create Repository~. Tu n’ajoutes rien
 avant, pas de description, pas de ~.gitignore~, RIEN.
 Et là, magie ! Github indique comment ajouter le dépôt distant à ton
 dépôt local.
 #+BEGIN_SRC text
 $ git remote add origin https://github.com/Phundrak/temporary-repo.git
 #+END_SRC
 Et voilà, ton dépôt est lié au dépôt distant. Oui, juste comme ça.
 Sinon, si tu souhaites d’abord créer ton dépôt sur Github puis sur ta
 machine, tu peux aussi très bien le créer sur Github (logique) puis le
 cloner sur ta machine comme je te l’ai montré avant.
 *** Et du coup, comment je met tout ça en ligne ?
 Bon ok, ce n’est pas aussi simple que ça. Une fois que tu as lié ton
 dépôt au dépôt distant, il faudra que tu mettes en ligne tes commits
 quand tu en auras l’occasion. Pour ce faire, tu n’as qu’à taper ~git
 push~ ; et la première fois, il faudra que tu indiques à ton dépôt où
 mettre en ligne précisément dans le dépôt distant, auquel cas tu
 ajoutes ~-u origin master~ pour cette première fois. Git te demandera
 donc tes identifiants Github pour pouvoir mettre tout ça en ligne.
 #+BEGIN_SRC text
 $ git push -u origin master
 Username for 'https://github.com': phundrak
 Password for 'https://phundrak@github.com':
 Enumerating objects: 10, done.
 Counting objects: 100% (10/10), done.
 Delta compression using up to 8 threads
 Compressing objects: 100% (7/7), done.
 Writing objects: 100% (10/10), 940 bytes | 313.00 KiB/s, done.
 Total 10 (delta 0), reused 0 (delta 0)
 remote:
 remote: Create a pull request for 'master' on GitHub by visiting:
 remote:      https://github.com/Phundrak/temporary-repo/pull/new/master
 remote:
 To https://github.com/Phundrak/temporary-repo.git
 ,* [new branch]      master -> master
 Branch 'master' set up to track remote branch 'master' from 'origin'.
 #+END_SRC
 Bon, là en nom d’utilisateur il y a le mien, faudra remplacer avec le
 tiens. Et ouais, ma vitesse de mise en ligne n’est pas fameuse, je
 suis sur une connexion 3G+ à l’heure où j’écris ces lignes, ne me juge
 pas. Bref, toujours est-il que je viens de mettre en ligne les
 fichiers du dépôt sur Github. Pas la peine de chercher le mien sur
 Github par contre, ça fera un bail que je l’aurai supprimé au moment
 où tu liras ces lignes.
 Pour info, tu peux éviter d’avoir à taper ton identifiant et ton mot
 de passe à chaque fois que tu fais un push sur ton dépôt si tu
 indiques à Github ta clef SSH. Tu auras plus d’informations là (c’est
 à peu près la même merde pour Gitlab, Gitea et Cie).
 *** Quelqu’un a fait des modifications depuis mon dernier commit, je récupère ça comment ?
 Pour faire un exemple, je viens de créer un ~README.md~ sur Github
 directement. Ce type de fichiers est assez standard afin de présenter
 plus ou moins en détails le dépôt et le projet qui y est lié, et son
 contenu apparaîtra formaté sur la page du dépôt sur Github s’il est au
 format ~.md~ (Markdown) ou ~.org~ (org-mode, le Markdown d’Emacs avec
 lequel est écrit ce tutoriel, et qui est clairement supérieur à
 Markdown). Mais il n’est pas présent dans mon dépôt local, du coup je
 vais devoir le récupérer. On va donc entrer git pull.
 #+BEGIN_SRC text
 $ git pull
 remote: Enumerating objects: 4, done.
 remote: Counting objects: 100% (4/4), done.
 remote: Compressing objects: 100% (3/3), done.
 remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
 Unpacking objects: 100% (3/3), done.
 From https://github.com/Phundrak/temporary-repo
   4380d87..8bd4896  master     -> origin/master
 Updating 4380d87..8bd4896
 Fast-forward
 README.md | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 README.md
 #+END_SRC
 *** Je suis en train de travailler sur le même fichier que Ginette
 Là, c’est un problème qui aurait pu être évité avec l’usage des
 branches dont je t’avais parlé plus haut, mais visiblement, vous êtes
 sur la même branche. Pas bien. Dans ce cas-là, met-toi d’accord avec
 Ginette pour savoir qui fait ses push en premier. Si le choix tombe
 sur Ginette, ou si elle a imposé sa vision des choses et a fait son
 push avant toi, Github va râler car tu n’es pas à jour. Dans ce cas ne
 panique pas, si tu n’as pas fait tes commits, lance la commande ~git
 stash~ ; ça va sauvegarder tes modifications dans un coin à part et va
 annuler tes modifications.
 *** Github ne veut pas de mes pushs sur le dépôt de Gilberte, oskour !
 Du calme Jean-Célestin. Cela veut tout simplement dire que tu n’as
 tout simplement pas les droits d’écriture sur son dépôt. Du coup, soit
 tu peux lui demander directement à ce qu’elle te donne les droits
 d’écriture si elle a confiance en toi, soit tu peux créer un fork puis
 une pull-request sur Github depuis ton fork où tu auras fait tes
 modifications.
 *** Fork ? Pull request ? Que font des fourchettes et des pulls dans ce tuto ?
 Ouhlà Billy, il va falloir remettre les choses au clair. Là il s’agit
 de quelque chose de spécifique à Github qu’à Git (d’où le fait qu’on
 en discute dans ce chapitre que le précédent).
 Sur Github, il est possible de copier vers ton profil le dépôt de
 quelqu’un d’autre dans l’état où il est au moment du fork. Cela inclus
 les fichiers du ~master~, mais également de toutes les branches du
 dépôt. Tu peux y penser en terme de super-branche dont tu deviens le
 propriétaire. Tu peux ainsi travailler comme bon te semble sur le code
 source sans que son propriétaire ne vienne t’engueuler car tu es en
 train de polluer sa base de code.
 Si jamais il y a une modification dont tu es particulièrement fier, tu
 peux la soumettre au propriétaire du dépôt original (et à ses
 modérateurs et contributeurs s’il y en a) via ce qu’on appelle une
 pull-request. Cela signifie donc que tu demandes l’autorisation
 d’ajouter des commits à la base de code, et ces commits peuvent être
 lus et commentés par le propriétaire ou les modérateurs. Il peut y
 avoir une discussion entre toi et les autres personnes qui ont leur
 mot à dire, le code peut être temporairement refusé, auquel cas tu
 peux reproposer de nouveau commits sur la même pull-request jusqu’à ce
 que ton code soit définitivement accepté ou refusé. Dans tous les cas,
 cela mènera à la fermeture de ta pull-request, et tu pourras fièrement
 annoncer que tu as participé à un projet sur Github, ou bien avouer
 avec toute la honte du monde qu’il a été refusé.
 *** J’ai remarqué un bug ou une erreur, mais je ne peux pas corriger ça moi-même
 Eh bien dans ce cas-là, ouvre une /issue/ Bernadette ; /issue/ qui en
 français veut dire /problème/. Il s’agit d’un système de Github te
 permettant de signaler quelque chose aux propriétaires du dépôt, il
 peut s’agir d’un bug, d’une demande de fonctionnalité ou de
 proposition de modification d’autres fonctionnalités. Cela peut donner
 lieu à des discussions menant à la compréhension du bug, ou à une
 amélioration de ta proposition.
 Si tu soumets un bug, avant d’ouvrir une nouvelle issue, assure-toi de
 bien savoir comment le bug se produit et peut se reproduire. Est-ce
 que le bug apparaît si tu utilise ou ouvre le logiciel d’une autre
 façon ? Est-ce que le bug apparaît ailleurs ? Est-tu sûr que le bug
 soit un bug ? Et si tu décides de le partager, assure-toi de partager
 un maximum d’information et tout ce que tu sais sur ce bug, en
 particulier les étapes et conditions pour le reproduire.
 *** Les raccourcis et paramètres de Git
 Comme j’en avais parlé plus haut, il est possible de configurer git de
 façon un peu plus poussée que simplement déclarer notre nom et notre
 adresse e-mail dans notre =~/.gitconfig=. Il est par exemple possible de
 déclarer notre éditeur texte préféré, notre navigateur par défaut ou
 bien même des raccourcis qui pourront t’être bien utile. Ci dessous je
 te met une partie de mon fichier de configuration avec quelques-unes
 de mes préférences et pas mal de mes alias.
 #+BEGIN_SRC toml
 [core]
  editor = emacsclient -c
  whitespace = fix,-indent-with-non-tab,trailing-space
 [web]
  browser = firefox
 [color]
  ui = auto
 [alias]
  a = add --all
  c = commit
  cm = commit -m
  cam = commit -am
  co = checkout
  cob = checkout -b
  cl = clone
  l = log --oneline --graph --decorate
  ps = push
  pl = pull
  re = reset
  s = status
  staged = diff --cached
  st = stash
  sc = stash clear
  sp = stash pop
  sw = stash show
 #+END_SRC
 - ~a~ :: Permet d’ajouter d’un coup tout nouveau fichier d’un dépôt en
  préparation au commit. On peut faire la même chose avec ~git add .~ si
  on est à la racine du dépôt.
 - ~c~ :: Un raccourci pour commit, ça permet d’éviter quelques frappes
  de clavier d’écrire ~git c~ plutôt que ~git commit~.
 - ~cm~ :: De même pour ~cm~ qui évite de devoir écrire ~commit -m~. On n’a
  plus qu’à écrire directement le message de commit après ~cm~.
 - ~cam~ :: Non, ce n’est pas un plan, c’est le même alias que ~cm~ mais
  qui en plus met automatiquement tous les fichiers modifiés ou
  supprimés, donc s’il n’y a pas de nouveau fichier à ajouter, même
  pas besoin de passer par un ~git a~ avant le ~git cam "j’aime les
  pâtes"~.
 - ~co~ :: Pour aller plus vite quand on veut écrire ~checkout~.
 - ~cob~ :: Et pour en plus rajouter le flag ~-b~ pour la création d’une
  nouvelle branche.
 - ~cl~ :: Pour quand tu voudras télécharger ce tutoriel en tapant ~git cl
  https://github.com/Phundrak/tutoriel-git.git~ plutôt que ~git clone
  https://github.com/Phundrak/tutoriel-git.git~.
 - ~l~ :: Te permet d’avoir le log un peu plus sympa et compact dont
  j’avais parlé plus haut.
 - ~ps~ :: Pour faire un push plus rapidement.
 - ~pl~ :: Et pour télécharger les derniers commits sur le dépôt plus
  rapidement.
 - ~re~ :: Pour réinitialiser plus rapidement.
 - ~s~ :: Pour rapidement savoir où tu en es dans ton dépôt, savoir ce
  qui a été modifié, ajouté, supprimé, déplacé, tout ça…
 - ~staged~ :: Eh oui, Git n’a pas de fonction dédiée pour lister les
  fichiers en staging, du coup la voilà.
 - ~st~ :: Pour sauvegarder tes modifications sur le stash plus
  rapidement.
 - ~sc~ :: Pour supprimer ton stash plus rapidement.
 - ~sp~ :: Pour rétablir le stash sur la branche courante plus
  rapidement.
 - ~sw~ :: Pour rapidement savoir ce qu’il y a sur le stash.
 *** Et c’est tout ?
 C’est déjà pas mal ! Mais non, ce n’est certainement pas tout.
 Cependant, ce tutoriel n’a pour but de t’apprendre que les bases de
 Git et de Github, pas de tout t’apprendre ! Si tu souhaites aller plus
 loin, connaître plus de commandes (comme ~git blame~ ou ~git reset~), ou
 bien connaître plus d’options, je ne peux que t’inviter à aller te
 documenter par toi-même sur le site de Git qui se trouve ici, ou bien
 à consulter des pages de manuel dans ton terminal via ~man git~, ~man
 git-apply~ ou ~man git-cherry-pick~ (oui, il faut lier ~git~ et le nom de
 la commande par un tiret d’union).
 Si jamais tu as une question, n’hésite pas à m’envoyer un mail à
 [[mailto:lucien@phundrak.com][lucien@phundrak.com]]. Si jamais tu trouves une erreur dans ce que je
 viens de dire dans ce tutoriel, ou si tu as une suggestion, c’est
 justement le moment de mettre en pratique ce que tu as lu un peu plus
 haut et d’ouvrir une issue sur Github sur le [[https://github.com/Phundrak/tutoriel-git][dépôt de ce tutoriel]].
 ** [EN] My YouTube subscriptions as an RSS feed          :linux:dev:tutorial:
 :PROPERTIES:
 :EXPORT_FILE_NAME: youtube-subscriptions-rss
@ -2105,7 +1368,7 @@ player. You lost focus.
 *** My Solution: mpv + RSS
 Wouldn’t it be nice if it were possible to watch these videos with a
-full fledged video player over which you have complete control? Which
+full-fledged video player over which you have complete control? Which
 could be customized to your heart’s content? Which won’t secretly
 track what you watch?
@ -2161,8 +1424,8 @@ https://www.youtube.com/feeds/videos.xml?playlist_id=PL96C35uN7xGI15-QbtUD-wJ5-G
 #+end_src
 *** Which RSS reader to go with?
-If you know me, you’ll know I am extremely biaised towards Emacs, so
+If you know me, you’ll know I am extremely biased towards Emacs, so of
-of course I’ll recommend Elfeed to any Emacs user ([[https://config.phundrak.com/emacs#Packages-Configuration-Applications-Elfeedoip0fl6184j0][my relevant
+course I’ll recommend Elfeed to any Emacs user ([[https://config.phundrak.com/emacs#Packages-Configuration-Applications-Elfeedoip0fl6184j0][my relevant
 configuration is here]]). I even wrote an advice around
 ~elfeed-show-visit~ to ensure YouTube videos are open with mpv instead
 of my web browser.
@ -2180,14 +1443,14 @@ really my cup of tea, but I can see why some people enjoy it.
 *** Improving a bit the mpv tooling
 You might have heard it, but youtube-dl hasn’t been doing great
-recently. The tool is becoming slow and it lacks quite a few features
+recently. The tool is becoming slow, and it lacks quite a few features
 it could really benefit from. While it is important to acknowledge its
 historical importance, I think it is now time to move on, and its
 successor shall be [[https://github.com/yt-dlp/yt-dlp][yt-dlp]]. In my experience, this youtube-dl fork is
 much faster than youtube-dl itself on top of providing additional
 features such as [[https://github.com/yt-dlp/yt-dlp#sponsorblock-options][SponsorBlock integration]].
-How do you replace youtube-dl with yt-dlp then? If you use ArchLinux
+How do you replace youtube-dl with yt-dlp then? If you use Arch Linux
 or one of its derivates (I hope not Manjaro though), you can simply
 install ~yt-dlp-drop-in~ from the AUR.
 #+begin_src bash
@ -2197,5 +1460,5 @@ yay -S yt-dlp-drop-in
 # or whichever AUR helper you prefer, as long as it is NOT yaourt
 #+end_src
-If you are not an ArchLinux user, check out [[https://www.funkyspacemonkey.com/replace-youtube-dl-with-yt-dlp-how-to-make-mpv-work-with-yt-dlp][this article]], it will help
+If you are not an Arch Linux user, check out [[https://www.funkyspacemonkey.com/replace-youtube-dl-with-yt-dlp-how-to-make-mpv-work-with-yt-dlp][this article]], it will
-you.
+help you.