# VSCode Neovim setup

I recently switched over to using the vscode-neovim extension for VSCode.

What wasn’t obvious though was how to get a plugin manager and plugins / vim customisations working.

I’ll add here quickly my plugins setup as I’m using `vim-surround`, and a bunch of Tim Pope plugins:

I’m on Linux / Ubuntu 22.04, with nvim installed via `apt` with `ppa-neovim/unstable` – you need this to get the current required nvim v0.8+.

I moved from Vim to Neovim and I still use my `.vimrc` and amazingly this kind of setup seems to work with vscode-neovim too.

As per the `:help nvim-from-vim` have the following `~/.config/nvim/init.vim`:

This happily loads my `~/.vimrc` file for terminal `nvim` and then loads `~/.vimrc.vscode` for vscode-neovim – which also appears to load:

1. It sets my leader to `<space>`
3. It loads my custom key mappings
4. It loads `vim-surround` and and `vim-repeat`
1. I know it loads these because I have a command `map <leader>' ysiw'`
2. This puts single quotes around the current word
3. This works (so `vim-surround` works)
4. I can then ‘repeat’ my adding quotes with `.` which means `vim-repeat` is working in combination with it.

I have massively stripped my `.vimrc` file down and renamed it to `~/.vimrc.vscode`:

Some interesting things that do work:

• vim-plug works!
• Basically it’s just really really cool that you can use a `.vimrc`
• This means almost tons of `remap`s should work
• `:buffers` works but it’s kind of ugly
• `:nohlsearch` works (removing the highlight)
• `:vsplit` works and moving with `<C-w>[hjkl]`

Lots of things don’t work like:

• I got a conflict between my vim-plug config for VSCode and for neovim
• By running `:PlugClean` inside VSCode this wiped all my neovim vim-plug directories
• Effectively I think this means its better to maintain your plugins via neovim
• Then use a subset within VSCode
• preview, quickfix and location windows
• I don’t think `:windo diffthis` works
• You have the same problem as with VSCode Vim that undoing all changes doesn’t get rid of the file ‘dirty bit’ so you have to save it to fully undo
• `:bd` doesn’t work as you expect – you need to use `:q` instead
• I found the `:e <type file path>` didn’t work with auto-complete beyond the current directory – just use `Ctrl + P` instead.
• There is no command history – you can’t use the up arrow to go to previous ex commands that you typed – I’m surprised about this so maybe there is a config setting somewhere Ctrl + N/Ctrl + P are used instead of up/down

I’ll try to list more as I go further.

For a couple of hours spent setting it up and to have 90% of the plugins I need working is really great.

Until I can get fugitive and vim diffs (in combination with fugitive) working I will still want to use terminal nvim, but that fits quite easily into my coding process for now.

# Javascript REPL

I really like the simple ‘console’ REPL that you have in a browser debug tools. I wanted to recreate this in VS Code.

## tl;dr Debug console

It turns out after lots of experimenting this can be also done with the ‘Debug Console’ when you start a debug session – see VSCode debugging.

This is exactly what I wanted.

However I had tried a whole bunch of REPL plugins first.

## Node.js Interactive window (REPL)

https://marketplace.visualstudio.com/items?itemName=lostfields.nodejs-repl

This is also a nice solution but seemed lacking compared to the browser console because you can’t inspect the objects so easily. But I guess it’s more like a standard REPL.

One problem is that it hasn’t been developed for years.

You have to disable eslint at the top

```/* eslint-disable */
```

This seems more like a repl than the playground – it evals immediately

## Interactive Javascript playground

https://github.com/axilleasiv/vscode-javascript-repl-docs

Very similar to the above plugin – neither is particularly actively maintained

This does seem to be very nice though.

You have to disable eslint at the top

```/* eslint-disable */
```

This allows you to do more like a playground where you can eval immediately or just eval with `//=` comments after a line

You can run a REPL on a markdown file too: https://github.com/axilleasiv/vscode-javascript-repl-docs/wiki/Markdown-code-blocks

## Code Runner

By far the most installed plugin is https://github.com/formulahendry/vscode-code-runner. This works for any language but has support for Node.

It’s kind of ugly though and it’s more like a SQL prompt where you can run a line or two of code and get output.

## Ramda

https://ramdajs.com/repl/

This seems really interesting – you can install it locally too. This is probably the closest that I am looking for.

But you have to do quite a lot of installation locally.

## Jupyter notebooks

Initially I was left cold by the REPLs as I didn’t have much access to the values – I liked the interactivity of the browser console.

My next step was to try Jupyter notebooks with a node.js kernal.

This led me to: https://github.com/DonJayamanne/typescript-notebook

This recommends installing Jupyter which adds a whole ton of stuff to VS Code but it all seems quite cool.

You can start in pseudo REPL mode where you just keep running a single line of code.

Or you can properly generate a ‘node notebook’ `*.nnb` file that you can use as a scratch pad. This then gives you full notebook support – this might be interesting for debug logs. I could create a JIRA-XXX.nnb notebook for each issue – then attach this to the Jira issue. Similar to the vim logs.

## Note: You need to disable Vim mode for the nnb file

Then you have nice shortcuts you can use:

• `b` – create new run section below
• `enter` – focus in the section (like INSERT mode for Vim)
• `esc` – lose focus on the section (like NORMAL mode for Vim)
• `shift+enter` – run the section
• `j`,`k` – move up and down sections
• `dd` – delete section

It also nicely shows up functions that you have created inside the notebook in the intellisense.

# VSCode debugging

What I don’t think a lot of VSCode users are used to is constantly living with the debugger turned on. Most web devs grew up in a world without Visual Studio, so `console.log` is the norm. However anyone who used Visual Studio for Visual Basic or C# development will know the power of constantly using and setting break points in your code. I’ve long ago stopped using Visual Studio, but here’s rough notes of what I did to bring debugging love back.

The debugger attaches a firefox/chrome extension to a running server and debug session.

So you must:

1. `npm run dev`
2. `npm run dev:workers` (in `packages/server`)
3. Start debug session via VS Code (see below)

## No more logs

So trying to get VSCode debugging working again so that I don’t keep pissing around with `console.log`.

Following on from Speedy deployment.

I have the Firefox debugger extension installed.

I now make sure I add things to my `.vscode/launch.json` so that I have them in the future for when I forget.

Here is the `launch.json` configuration:

```{
"version": "0.2.0",
"configurations": [
{
"name": "Launch index.html",
"type": "firefox",
"request": "launch",
"reAttach": true,
"file": "\${workspaceFolder}/index.html"
}
]
}
```

## Note: that is attaching to a file – we want to attach to the next.js running URL

You can also create something very similar by clicking the ‘Add configurations’ button at the bottom when you have the `launch.json` file open.

Now we’re using next so need to hook into that. There are quite a few tutorials for this:

For the Next.js specific `launch.json`:

```{
"version": "0.2.0",
"configurations": [
{
"type": "firefox",
"request": "launch",
"reAttach": true,
"name": "Next: Firefox",
"url": "http://localhost:3001",
"webRoot": "\${workspaceFolder}"
}
]
}
```

Note the `url` and `webRoot` settings.

## Setting up Firefox to connect

You need to enable remote debugging.

Now you should be able to the ‘Run and Debug’ side bar and run the “Next: Firefox” as in the `name` setting above.

I added a breakpoint to a file, which showed up as a grey circle next to the line numbers. I was expecting a red filled circle. When you run the debug session the breakpoint doesn’t stop there. The error comes down to the path settings because next.js isn’t running at the root of the workspace:

See the notification in the bottom corner:

This is similar to the dev.to Bonus: If your Next.js code is not at the root of your workspace section, but here we have `pathMappings` instead of `sourceMapPathOverrides`.

Note: I adjusted the `webRoot` to include the packages path after fixing this for Chromium, but it still requires the `pathMappings`.

I clicked on ‘Yes’ in the above message. It then created the `pathMappings` `launch.json` as:

```{
"version": "0.2.0",
"configurations": [
{
"type": "firefox",
"request": "launch",
"reAttach": true,
"name": "Next: Firefox",
"url": "http://localhost:3001",
"webRoot": "\${workspaceFolder}/packages/client",
"pathMappings": [
{
"url": "webpack://_n_e",
"path": "\${workspaceFolder}/packages/client"
}
]
}
]
}
```

Now the break point within VS Code is a red filled circle and the code correctly breaks on it.

You can do the same in the Firefox dev tools – I actually think I prefer those dev tools for debugging – but then you’re separated from the code.

## Setting up Chromium to connect

Now we should be able to do the same for Chrome.

My linux setup doesn’t use regular Chrome, but flatpak Chromium instead. So the second configuration below is much easier.

Note: I found the `\${userHome}` variable from https://code.visualstudio.com/docs/editor/variables-reference

Similar to Firefox when I had to set a `pathMappings` config, for Chrome its easier because you just set the `webRoot` to the `packages/client` directory. This should work for Firefox too – but doesn’t :woman_shrugging: :woman_facepalming:

```{
"version": "0.2.0",
"configurations": [
// This is runtimeExecutable is mildly crazy because of flatpak
// Normal chrome installs won't need runtimeExecutable
{
"type": "chrome", // must be chrome
"runtimeExecutable": "\${userHome}/.local/share/flatpak/app/org.chromium.Chromium/current/active/export/bin/org.chromium.Chromium",
"request": "launch",
"name": "Next: Chromium (flatpak)",
"url": "http://localhost:3001",
"webRoot": "\${workspaceFolder}/packages/client"
},
// Regular Chrome
{
"type": "chrome",
"request": "launch",
"name": "Next: Chrome",
"url": "http://localhost:3001",
"webRoot": "\${workspaceFolder}/packages/client"
}
]
}
```

## Debug console

Once you have a debug session running, you can access the tab ‘Debug Console’ in the output panel (the same panel as the terminal).

This then gives you what seems to be a perfect console session as you get within a browser.

When you hit a breakpoint you can refer to the locally defined variables and inspect them.

# Translating Sublime Text into Vim

## Intro

Coming from a Windows world getting into Vim, to me is almost exactly like the struggles I had learning French or Dutch. I spent 10 years learning French growing up and I can’t speak a proper sentence. I then moved from England to the Dutch speaking part of Belgium (Flanders) and I learnt to speak Dutch to a conversational level within 2 years.

If you’re going to learn Vim you need to immerse yourself in it. I suspect the majority of Vim users only ever use it to make minor file modifications via SSH. That’s what I did anyway.

I’ve used lots of editors in Windows but the one I prefer now is Sublime Text (ST). However ST has almost all the exact same commands as other editors, with the one major improvement which is `Ctrl+P`, we’ll come to that later. ST is free to use with a popup once in a while, its a great tool, you should buy a licence.

So for users of all other editors, all you have to do is learn the elements of Sublime Text I use here and then you should be able to translate them to your own editor. I hear you notepad lovers. So we’ll use ST as the boundary layer between our nice fuzzy `Ctrl + N``Ctrl + C``Ctrl + V` and `:e``y` and `P`.

## Why O Why

Is it worth the pain? I have spent in excess of 100 hours doing nothing but learning Vim and getting it set up the way I want.

I mean, the question ‘How to close Vim?’ has a 1000+ up votes on Stack Overflow. That’s insanity.

However, I think that if you master Vim the layer between your thought and your code becomes thinner. So this has nothing to do with linting or plugins this has to do with performing at a higher level with the code that you write.

Also I think Vim is just misunderstood. This is where my analogy of learning a spoken language comes from. Switching between Windows editors is like switching dialects sure some of the Scottish folk sound funny, but you can understand what they say. All of us assume that Vim is just another dialect, but it’s not. It’s like nothing you’ve used before. So there’s nothing for your brain to grab on to and understand.

1. Vim gets you closer to your code. Once performant in Vim you can perform code editing tasks faster and keep up with the speed of your thought. This breaks through the ceiling that you will hit with most other GUI editors.
2. Vim is very fast, I don’t think it’s necessarily faster than ST, but certainly it’s at that level, everything happens instantly. There’s none of the delay that you sometimes have with opening ST or other heavier editors e.g. Netbeans, IntelliJ. Speed is one of the barriers between your thought and your code, slow editors are slowing you down.
3. Vim is ‘hyper’ cross-platform (Windows, Mac, Linux, SSH, Docker, Browser (via WASM), Android, Amiga …) and works via the command line, every benefit you learn on Windows means that you have the multiplied benefit that you can use the exact same instructions on Linux or on Mac. Again so it ST, but Vim works via SSH, it works in Docker, it works everywhere.
4. Once you learn the commands you can do things quicker, deleting a word is just typing `dw`, once fluent this can be performed faster than using the mouse or `Ctrl+Shift+Right-arrow, Delete`. These are small 1% improvements, but they add up.
5. Vim has a command history. This is really useful for doing repeated things. Sure your search box in other editors has it plus you’ll have recent files that you’ve opened, but every single command that you type is recorded. My example for this is reformatting code with Regex. Once you’ve closed your regular editor your search and replace history is lost. In Vim it’s there waiting for you.
6. Not only that but anything you did as the last command can be repeated with `.`. This can be complex things like repeating all the text you just typed in Insert mode. Or if you just cut a line and you want to paste it a few times, now you’re just typing `.` instead of `Ctrl + V`.
7. Syntax highlighting! In the DOS prompt, SSH prompt! Seriously, this is amazing. Windows has been around for 30 years and there’s nothing else I know of that can give you this.
8. Less Chrome. Vim is mostly like using the distration free mode of Sublime Text all the time. Less distraction, more thinking.
9. Everything you’ve got in your editor currently: Tabs, Split screen, Projects, Linting, REPL, Plugins, Sidebar file tree. But we’re still in the donkey DOS prompt here.
10. Closer to the command line. Again thinning that barrier between you and your code. In Vim you can type `!` and then any command line command, e.g. `!mkdir temp` or `!python` will allow you to drop into the python REPL and then come straight back to Vim once you’re done.
11. Vim’s buffers, which are the equivalent of tabs in other editors, are amazing. When you have a regular editor open you’ll typically have 10 or so tabs open, or at least that’s what I had as otherwise it becomes too crammed. With Vim you just keep opening all the files you want into buffers. I regularly now work with 100 buffers open, but then I can very easily switch between them – `:b [part of file name]` then `<Tab>` and you switch to the other file, if you have more than one file open with that bit of the name then you just tab through the list, e.g. `:b Controller` will allow you to tab through all the `*Controller*` files (buffers) that you have open.
12. Not strictly Vim itself, but it has excellent integration with FZF and Ripgrep, which are Rust commandline tools for fuzzy file finding and ‘find in files’. These tools are ridiculously fast. Having a fuzzy file finder means that you don’t need the folder structure on the left any more. Ripgrep works better on Linux but in any place it will churn through GB of source code. Also once you have the search results you can do more with them, they open up in a standard Vim ‘window’ and so you can search/highlight in your search, can then also run search/replaces on the list that you get back.
13. Vim sessions are what allow Vim to work in a similar way to Sublime Text in that you can save all the open files that you had when you close Vim and open up exactly where you were last time.
14. But Vim sessions are really flexible, the one great thing I’ve found about them is that I can combine all the projects that I’m working on into one. My colleagues use various other IDEs and we have a set of projects each with their own git repo and docker container. My colleagues need to switch projects each time they want to look at code in one project. However I can put all the repos in one folder and then create my Vim session above all of them. Then FZF can find any files amongst them, Ripgrep can search through all of them at the same time. So it means I can jump-to-definition across any project that I have.
15. Combining all you do with other tools in one. Here’s a few things that I now do in Vim that I used to use other tools for: file diffs, git diffs, subversion diffs, todo lists, database connections/commands, git conflicts, subversion conflicts. This is not quite a case of Emacs where you never need to leave it again, but all my development tools work perfectly inside Vim, so I can use the power of the various commands I’ve learnt in Vim across these other tools
16. Git diffs, this is a surprising one, but once you start using Fugitive plugin doing a side by side diff is easy and comes with nice syntax highlighting
17. Git conflicts are handled beautifully with the Fugitive plugin, the majority of developers that I know only know how to use SourceTree or the output from Bitbucket diffs. With Fugitive you can do a 3-way vertical diff (see the Vimcast on Git conflicts), so you have the conflicted file in the middle with the two files you want to merge either side. It is the nicest way possible to do a merge. Even the GUI tools that I’ve seen that do do a 3-way merge are pretty ugly. Meld is quite good one for Linux and Windows, but it’s not fully supported on Mac, but this suffers from being slow. In Vim everything is fast and again I’ve got all my Vim tools handy as the diff windows are just Vim windows.
18. Todo lists is a simple one – but you have things like Org mode in Emacs that you can replicate in Vim, but for the most part Markdown does everything you need.
19. Database connections are always done in a special application. The main one I’ve used is SQL Server Management Studio (SSMS) – but of course that only works for SQL Server. If you work with MySQL either you need to use things like PHPMyAdmin or just use the MySQL command line, there are sometimes closed source tools for connecting to various databases but I’ve never particularly liked one. Tim Pope recently created the dadbod plugin that allows you to connect and run commands on all the major databases. This means that like SSMS I can have my SQL file open with syntax highlighting but then I can highlight a few lines and run those. This is super powerful, you then of course get all the query results in a Vim window and can use all the regular commands to search that and copy paste text from there. I still regard SSMS as the most powerful SQL editor that I used, but now I can have the majority of the functionality that I used there but for any database. I don’t have the things like query optimisations, but it’s rare that I need that.
20. Making a tailored editor… typically all you do with other editors is install a few plugins. With Vim it’s expected that you’ll customise almost everything. People with ST share their list of plugins, where as people with Vim share their `.vimrc` file which contains all their plugins and all their settings. It’s the difference between an off the peg suit and a tailored suit, other people might not see the difference but you will feel it. You create Vim exactly as you want it.
22. Fully free and open source, it’s inspired a whole bunch of new editors – neovim, gonvim, AMP…
23. Touch typing becomes more important. Once you use the keys for everything then you encourage yourself to touchtype more. This adds benefits to your coding. And as Joel Spolsky says, fast accurate typing is one of the fundamentals of a developer. I’m still not great at this but using Vim is helping me to improve.
24. Split windows are something that I never bothered with in ST, but recently they’ve become very useful. When I’m trying to implement a new feature based on someone elses code I find it useful to have a side-by-side view of the two files. Further I can have the main code I’m working on in one window and then search throughout the code in the other window. Again you can do things like this in ST but I never really started doing this until I got used to Vim and Vim split windows.

## Lesson 1: Install GVim

GVim is by far the best way to get introduced to Vim, it is a much more standardised way of using Vim rather than starting in the terminal and hitting problems. I really want to encourage people to try using Vim in the DOS prompt just because it’s amazing to finally see it there but for anyone starting just use GVim. I still use GVim on Windows as there’s still a frustrating slowness to editing in the DOS prompt but almost all my other gripes with it have disappeared over the last two years – the Windows team changing it are doing an amazing job.

Nevertheless, we’ll start with GVim, as well as being more consistent it allows for discovery as it has a lot of common menu commands at top that typically say what the commands are so that you can slowly familiarise yourself with it.

I suggest installing GVim via Chocolatey, or otherwise you can just download it and install it from the vim.org site (that’s all Chocolatey does behind the scenes).

Hopefully it also means I can help more people, Powershell users can probably translate the DOS commands more easily to Powershell than vice-versa. Linux and Mac users used to using GUI tools should be able to figure it out too. When I write `Ctrl + C` people will understand, when I write `<C-c>` users unfamiliar with Vim / Emacs will stare blankly.

### Install Vim in DOS (not required)

If you’ve installed GVim then this also installs a command line version of GVim. The good part of this is that it comes with the most recent version of Vim – currently 8.1. There are some very nice things that have been added in the most recent version that improves the colour handling inside the Windows 10 DOS prompt.

Add `C:\Program Files\GVim\bin` to your `PATH`.

I love using Vim inside the DOS prompt. I think it is the simplest, purest way of using Vim in Windows.

Vim 7.4 also comes with Git for Windows. You can install this via Chocolatey, or just via the Git website.

```> choco install -y git
```

We then need to add the GNU `usr` tools to our `PATH` – add `C:\Program Files\Git\usr\bin` to your `PATH`.

This gives you all the loveliness of all the GNU tools e.g., `ls``grep` as well. If you really want to do yourself a favour install clink and solarized DOS prompt colours too.

## Lesson 2: Basic commands

You can skip this if you know the commands. I knew the basics of these for years before I started immersing myself in the rest of Vim.

### Inserting code

You go into the INSERT mode by hitting the `i` key and switch back to NORMAL mode by hitting escape.

Once you’re in edit mode then it’s fairly similar to other editors, you can move left, right, up, down with the arrow keys, then just type and delete stuff with the backspace or delete keys.

Initially to be more familiar with other non-modal editors most users will spend all their time in INSERT mode. I personally think there is nothing wrong with this and this is exactly what I did to be as productive as possible in the beginning.

To be more productive though, it is necessary to learn the other Vim commands, otherwise you’re just taking away all the other features that you’re used to in ST which almost all do exist in Vim, just that they’re more hidden or you need to install a plugin for it.

### Searching / moving code

A lot of the `Ctrl + ...` commands that you expect from other editors are handled in Vim’s NORMAL mode – you should see the word `NORMAL` in the bottom left-hand corner.

This is the weirdest part of Vim, that you delete words via three or four letter commands.

I actually practiced the commands by installing an Android app with Vim commands and the beginnger free part of shortcutFoo Vim.

After those commands the next most important one is `:`. This is the most common way of starting the command line typing at the bottom. It’s similar to when you type `Ctrl + P` into ST.

The first command to type is `:help`, this shows the first cool thing of Vim – split windows as standard.

The weirdest concept I had (after years of very light usage) is typing `:w` instead of `:x` to write the file, because now we actually want to stay in Vim, rather than get the hell out as fast as possible.

# Vim Language Server Client (LSC) plugin first impressions

After months of problems with CoC: https://github.com/neoclide/coc-eslint/issues/72 I’ve given up and I’m trying other plugins.

I used ALE for ages with eslint, but never got it decently working using LSP. I tried ALE with Deoplete – but ALE is very slow and deoplete took ages to configure (python3 + pip + msgpack 1.0+ is a pain to install).

I came across this blog post showing love for Language Server Client (LSC): https://bluz71.github.io/2019/10/16/lsp-in-vim-with-the-lsc-plugin.html.

But this had a problem that it doesn’t work for linting, only LSP and I need eslint.

However this reddit comment described perfectly the use of installing ALE and LSC.

ALE with eslint, LSC with tsserver (+ LSP compliant wrapper `typescript-language-server`).

This seems like a good combo. ALE was reliable for ages and slow linting doesn’t matter too much, it’s slow auto-completion that’s a problem. Also ALE doesn’t have the floating window features that CoC and LSC do.

LSC along with ALE is almost entirely Vimscript (with some Dart that doesn’t require a further install) which makes it an easy install – no further dependencies makes plugins much better with Vim.

## Installation of raw plugin

First thing that disappoints me currently in the instructions of the plugin is not having the Plugin code to copy-paste, I love where I can blindly follow the instructions with copy paste and it all magically works.

So to install the plugin in your `.vimrc` or `init.nvim` for example using Plug or Vundle:

### Plug

```Plug 'natebosch/vim-lsc'
```

Then run `:PlugInstall`

### Vundle

```Plugin 'natebosch/vim-lsc'
```

Then run `:PluginInstall`

### Pathogen

```git clone https://github.com/natebosch/vim-lsc ~/.vim/bundle/vim-lsc
```

Then run `:Helptags` to generate help tags

### Dein

```call dein#add('natebosch/vim-lsc')
```

This will work too with any of the other plugin managers that support github plugins as sources.

## Installation of typescript language server

However at this point you have a problem because there is nothing to indicate that anything is working. No auto-completion happens, nothing.

If you install Coc, from what I remember immediately auto-completion starts happening.

You can run `:LSC<tab>` which should open up a list of the possible LSC commands to at least show that you have it installed.

Coc starts working for pretty much every file with an auto-complete using the words in the current file. This is great for seeing the immediate response that you know you’ve installed the plugin correctly. Plus with Coc you can run `:CocInstall coc-eslint` which starts installing the eslint and then works again immediately from what I remember.

I want to test LSC with the typescript LSP, which I’d already installed with:

```npm install --global typescript
```

Now fair enough but rather frustratingly the typescript tsserver isn’t a fully compliant LSP, so you need the LSP compliant wrapper `typescript-language-server` mentioned above install globally same as typescript:

```npm install --global typescript-language-server
```

I have two specific requirements which makes my commands differ:

1. I use yarn
2. I installed yarn/npm using `sudo`

So my actual command was:

```sudo yarn global add typescript typescript-language-server
```

Coc mimics VS Code and works with tsserver out of the box which saves you from having to install the extra library. If LSC could be made to work with tsserver it would be a nice step. Coc even goes so far as to install tsserver for you so you just need `CocInstall coc-tsserver` and the magic starts happening. So you can install and get Coc working without having to leave Vim – the same happens for eslint because typically developers using eslint will already have it in their project and this just gets picked up magically.

The frustration of `typescript-language-server` is that there is the far too similarly named `javascript-typescript-langserver`, I have no idea of the difference nor do I really care, I just want the one that works. The LSC documentation for JavaScript language servers fails for this it shows me how to configure both of them but gives me no idea which one I should prefer.

I’m very much a proponent for the “don’t make me think” mantra because that’s what most people are after when they’re trying to install a plugin.

Why go through all the work of writing your plugin in Vimscript only to leave the documentation bare leaving people frustrated.

## Configuration

Annoyingly the configuration for Javascript is buried. There’s no mention in the README that there is a wiki that lists all the language server configurations, and even in the wiki the home page is bare, so you have to spot the pages menu on the left-hand side.

Then when you get to the Javascript section you have the previously mentioned problem that there are two servers and you don’t know which to choose.

So I already have tsserver installed and that’s used by VS Code and so is used by 90% of all developers now and so I’ll use that.

```let g:lsc_server_commands = {
\ 'javascript': 'typescript-language-server --stdio'
\ }
```

Futher frustration though is that there’s no comments in there giving helpful tips on how to set them up properly. The bluz71 blog above has the useful extra hint:

For LSC to function please ensure typescript-language-server is available in your `\$PATH`.

So you should make sure to add the npm/yarn global installation directory into your path – it’s easy enough to find instructions for this. To test make sure you can run this in the directory where you start Vim:

```\$ typescript-language-server --version
0.4.0
```

Obviously you’ll probably get some other version number, but you should at least get a response. You don’t set up a path to the language server binary in the config so it assumes you’ve got it directly available.

## That’s all folks… not quite

That should be that. With a restart of Vim the magic should happen – open up a Javascript file, start typing away and BAM, auto-complete pop-ups should start appearing.

However for me it didn’t, patiently typing a few characters and then reading documentation on how many characters to type before something happened did nothing.

I tried a `:LSClientGoToDefinition` and it spewed out an error:

```Error detected while processing function lsc#reference#goToDefinition[2]..lsc#server#userCall:
line    2:
E684: list index out of range: 0
E15: Invalid expression: lsc#server#forFileType(&filetype)[0]
```

Firstly getting errors is always bad and secondly this error message makes no sense.

The problem here is that there is no ‘health check’ that I could find. ALE gives a very good diagnostics page via `:ALEInfo`. The `LSClientAllDiagnostics` and `:LSClientWindowDiagnostics` that sound like they might be useful aren’t at all in this situation.

Even after reading through `:help lsc` I did not spot anything to help with spotting issues. But the intro there is very helpful:

There is no install step for vim-lsc. Configure the filetypes that are tracked
by installed language servers in the variable “g:lsc_server_commands”. Each
value in this dict should be a string which corresponds to either an
executable in your “\$PATH”, an absolute path to an executable, or a
“host:port” pair. If multiple filetypes are tracked by the same server they
should be entered as separate keys with the same value. The value may also be
a `dict` to allow for additional configuration.

It was only after re-reading the bluz71 blog again that I spotted my problem:

For a given filetype the LSC plugin will take care of launching, communicating and shutting down the named language server command.

My problem is that because I have the `mxw/vim-jsx` plugin, my javascript filetype becomes `javascript.jsx`, so my config needs:

```let g:lsc_server_commands = {
\ 'javascript.jsx': 'typescript-language-server --stdio'
\ }
```

Now I did a re-source of my `.vimrc` via `:source %` and then tried again with my Javascript file and nothing worked still.

However doing a restart of Vim, now I got an error that flashed up in the Vim command line and disappeared, but then finally the magic started to happen.

So to know if LSC is working, the first thing you notice is that it subtly highlights the word you are on and any other words (‘symbols’) that match that.

Now auto-completion starts working and I can tweak away with key mappings. However I don’t really care about key mappings – they’re easy to tweak.

## Final thoughts

This does seem like a great plugin now that it’s working. It has the speed and functionality of Coc and it works which is a major plus point over Coc at the moment.

What I fundamentally care about when trying these LSP plugins is getting something to work as fast as possible so I can test out the plugin. I can then add other language servers and configurations, but until I’ve got something working there’s nothing but frustration.

# Embracing the Neovim/Vim Terminal

I’ve only finally just started using Neovim’s terminal. Vim 8 has this too of course, but it was Neovim that championed it and included it by default.

I switched to Neovim about a year ago to see if there was anything missing compared to Vim. I find Neovim fascinating purely because of how faithful it is to Vim. They had the perfect answer to open source – “if you don’t like it fork it” and make your own. Vim itself is healthier because of the additions that Neovim included.

I literally can’t visually tell if I am using Vim or Neovim. You have the one initial setup to use your existing `.vimrc` file and the rest just works perfectly.

I’ve never had to raise a bug because of some incompatibility. All the Vim plugins I use work.

The sheer scale of porting an editor that has been around for 30 years to implement what appears to be 99.9% of it’s functionality is amazing.

## First steps

One of the big things of Neovim was its inclusion of a terminal.

I’d tried the terminal a couple of times but I found it jarring, it’s like the Vim experience all over again – you’ve no idea how to quit.

You need a combination of `Ctrl + \`, `Ctrl + n`, which is just as insane as `:wq` for those who don’t know Vim. I don’t know whether it’s an intentional homage, but all I know is that it scared me off for a year.

Somewhere during that year I tried tentatively again and added this (probably from this Vi StackExchange answer) as suggested to my vimrc:

```" terminal easy escape
tnoremap <Esc> <C-\><C-n>
```

But then I just left it there. I always just kept a separate terminal open to run the commands I needed there. This currently is running a bunch of node docker containers. This obviously means `alt + tab` between the windows, or `ctrl + pg up/pg down` if you have terminal tabs (I’m using Ubuntu mostly).

However I kept seeing my colleagues running their terminal session within VS Code. I’d roll my eyes at the wasted screen space, but it did seem kind of natural, you have another step in your development process combined into the one editor.

I was always a fan of “Linux is my IDE” so I also didn’t see a problem of switching to the terminal, it also feels ‘fairly natural’ as both Vim and any other terminal programs are still running in the terminal, so I saw it as a benefit of Vim.

It always seemed natural that if you’re running a terminal process you should open up an actual terminal, not some emulator, get yourself the real thing.

However there’s a few niggles:

1. Searching the terminal output, there are ways but they aren’t as nice as the Vim searching
2. Scrolling naturally around the output, to the top and back to the bottom – especially when its 10,000+ lines long of log output
3. Copying and pasting between the terminal output and Vim
4. It janks either wasting the screenspace of the terminal tabs or having to `alt + tab` to search for the other terminal window

## Welcome back

So I dived in again a couple of days ago. Having the `Esc` remapping is so natural, I’d forgotten that I’d added it to my `vimrc` and was simply the first thing I’d tried to get out. I had to go searching for it again just cause I remembered the frustration of quitting from before and didn’t understand why it was so easy.

But now, suddenly it’s awesome. Once you’ve hit `Esc` it’s just another buffer. It can hide amongst my hundreds of other buffers, so no screenspace wasted. This obviously assumes you’re using Buffers not ‘Tabs’ (aka Tab Pages).

It resolves all the problems above:

1. Searching – I now have my standard `\` command to search and highlight plus grepping/ripgrep/fzf
2. Scrolling – now again all the `gg` top and `G` bottom commands are so much nicer to use, I never feel the need to use the mouse to scroll aimlessly amongst the text, I can always use `Ctrl + f/g` and `j/k` too – all the lovely Vim commands are now available
3. Copying and pasting is just Vim buffers no need for the external clipboard
4. As it’s all just buffers it’s easy to switch to with buffer switching.

So where as I understand it’s just an emulator, not the real terminal, but bash is kind of designed to emulated so not a real problem I guess and now I get terminal + evil mode!

So thanks again Neovim for adding this in.

## Steps of caution

There are some peculiarities of Neovim terminals to get used to.

1. `Esc` is sometimes used in the terminal for genuine reasons, for example cancelling an `fzf` request – this now won’t work. My solution to this has been to have the escape sequence be `<leader><Esc>` this allows escape to still work, but be still easy to quit out.
2. The inception of running Vim via an SSH session inside a Vim terminal has a few niggles, but handles pretty well.
3. It’s a bit hard to re-find your terminal if you’ve got a couple open – you need to remember the buffer number mostly
4. If you close Vim you’ll kill all the processes running there without warning

# A dive into the many faces of manifolds

What are manifolds? I started down this rabbit hole because of Chris Colah’s excellent Neural Networks / Functional programming blog post:

At their crudest, types in computer science are a way of embedding some kind of data in n bits. Similarly, representations in deep learning are a way to embed a data manifold in n dimensions.

So the problem is that people talk about them even when you don’t think you need to care about topology, or even really know what topology means.

The following is a bit of a dive into examples of manifolds with the intention of better understanding what a manifold is.

## Starting somewhere

Opening quote from Wikipedia:

In mathematics, a manifold is a topological space that locally resembles Euclidean space near each point.

Without knowing exactly what topological and Euclidean spaces are that’s hard to understand. Let’s try simple Wikipedia:

A manifold is a concept from mathematics. Making a manifold is like making a flat map of a sphere (the Earth).

A ball (sphere plus interior) is a 3-manifold with boundary. Its boundary is a sphere, a 2-manifold.

So, to me, this makes no sense of creating a manifold (a flat map) from a manifold (a sphere is a 2-manifold). Why create a manifold if you’ve already got one? (My thinking here is wrong, but I’m trying to explain all my incorrect thinking as I go and clear it up at the end)

### Bounds checking

Some kind of useful quotes from the section on boundaries:

A piece of paper is a 2-manifold with a 1-manifold boundary (a line)

A ball is a 3-manifold with a 2-manifold boundary (a sphere)

## Show me the money

‘Simple’ examples are usually the way for me out of confusion. The list of manifolds helps a lot:

1. $\mathbb{R}^n$ are all manifolds, so a line $\mathbb{R}$ is a 1-manifold
2. A x,y 2D plane $\mathbb{R}^2$ is a 2-manifold
3. All spheres $\mathbb{S}^n$ are manifolds… stop there, I’m confused

### Spheres

This really gets me. Why do we need to create maps of the world if it’s already a manifold. The simple Wikipedia explanation makes sense, i.e. it’s obvious that we want to create a flat map of the world. It also makes sense that where as a triangle on the globe doesn’t add up to 180 degrees (bad) does nicely add up to 180 degrees on a flat map (good). But why, if the earth is already a manifold do we want to create another manifold from that. Isn’t being a manifold good enough? Some people are never satisfied.

### n-manifold

A sphere is a 2-manifold, so although it is a 3D object, close to any one point it looks like a 2D grid.

The important part is the n-manifold. This is what cleared it up for me, you don’t care about creating one manifold from another.

An n-manifold resembles the nth dimension near one point. So a flat map is a 2-manifold and the earth is a 2-manifold because they both represent a 2D grid near one point.

### Manifold Hypothesis

In another post from Chris Colah, he talks explicitly about manifolds. But he talks about them assuming that you know what they are:

The manifold hypothesis is that natural data forms lower-dimensional manifolds in its embedding space.

`*scream*`

### Nash equilibria

Although John Nash is most famous for his Nash equilibrium, but it a lot of his most important work was to do with manifolds:

His famous work on the existence of smooth isometric embeddings of Riemannian manifolds into Euclidean space.

### Differentiation

Interestingly differentiating a curve at a point on that curve gives you the slope of the flat line at that point. So there’s a connection between differentiation and manifolds.

There’s a Calculus on Manifolds book that looks interesting, taken from this talk on The simple essence of automatic differentiation. Then there is a link back to Chris Olah’s NN/FP post based on this Conal Elliot’s Automatic Differentiation paper.

## Euclid forgive me

To be honest even Euclidean space gets me confused. That’s basically just $\mathbb{R}^n$ which I can understand better. But is there a specific reason for using Euclidean? Is there some extra property of Euclidean space that isn’t inherent in $\mathbb{R}^n$? There’s a fundamental principle of parallel lines not converging in Euclidean space, but then if a manifold is in Euclidean space, how can a sphere be a manifold? It doesn’t explain why we want to convert one manifold into another (as in the spheres section above), or even really know what topology means.

### Euclid’s grid

I keep thinking of Euclidean space as basically everything. But it’s not – it’s a n-dimensional grid (with infinite points as it’s the real number line in each direction) and it has straight edges. So a ball isn’t in Euclidean space, or “isn’t Euclidean”, I’m not sure which.

In image analysis applications, one can consider images as functions
on the Euclidean space (plane), sampled on a grid

### Data manifolds (back to Chris)

Perhaps data manifolds are the structure of the data. For example as above an image data is a 2D Euclidean grid.

They get referred to in the MIT CS231n CNNs course when talking about ReLUs:

(-) Unfortunately, ReLU units can be fragile during training and can “die”. For example, a large gradient flowing through a ReLU neuron could cause the weights to update in such a way that the neuron will never activate on any datapoint again. If this happens, then the gradient flowing through the unit will forever be zero from that point on. That is, the ReLU units can irreversibly die during training since they can get knocked off the data manifold. For example, you may find that as much as 40% of your network can be “dead” (i.e. neurons that never activate across the entire training dataset) if the learning rate is set too high. With a proper setting of the learning rate this is less frequently an issue.

It’s as if data manifold is the useful/accessible part of the data.

### What’s not Euclidean

For instance, in social networks,
the characteristics of users can be modeled as signals on the
vertices of the social graph [22]. Sensor networks are graph
models of distributed interconnected sensors, whose readings
are modelled as time-dependent signals on the vertices.

In computer graphics and vision, 3D objects are
modeled as Riemannian manifolds (surfaces) endowed with
properties such as color texture.

Manifolds don’t have to Euclidean! But at one particular point on a manifold surface it is approximately a grid in the local area. So this holds if it is Euclidian, because locally on a sheet of paper it’s Euclidean as the sheet of paper is already Euclidean.

But certainly I like the explanation that 3D graphics are manifolds. So there’s nothing special that makes the earth a manifold it’s just one example of one. So I think this means that any 3D shape is a manifold.

So what’s not Euclidean and not a manifold?

### What’s not a manifold?

That dear reader… is an exercise for you.

## What did this get us?

1. Euclidean space means a grid (duh)
2. An image of pixels is a 2D grid – possibly the data manifold that Chris Olah was referring to
3. A 3D graphic (or the earth) is a 2-manifold. These are not Euclidean but are 2D Euclidean (grid shaped) close to a point on their surface
4. When your data is 3D graphics – that is your data manifold

# Vim Airline Powerline fonts on Fedora, Ubuntu and Windows

N.B. I’ve also answered this on Vi Stack Exchange, but I’m posting it here as it took a lot of work.

This took hours to figure out, so here’s more of a dummies guide for Fedora/Ubuntu, with a special section for Windows.

The first is figuring out what the hell are those strange but nice angle brackets that appear in the vim-airline status bar. The background is that airline is a pure vim version of powerline (which was python), and powerline uses UTF-8 characters to insert those angle brackets. So vim-airline just uses the same UTF-8 characters.

Then even if you do manage to get one installed they look uglier than you’d hope because the fonts don’t fully work.

## Configuring Vim

This is opposite to the official instructions but I had this bit wrong at the end which made me question all the font installations. So I suggest you get this configured first and then if you get the fonts working it should magically appear.

The final trick was forcing vim-airline to use the fonts it needs. In the official documentation it should just be adding `let g:airline_powerline_fonts = 1` in your `.vimrc`. However I did this and no luck. There’s more information in `:help airline-customization` and that gives you some simple config settings that you need, just in case. This was the final magic sauce that I needed. I don’t know why this wasn’t automatically created. This is also mentioned in this Vi Stack Exchange answer.

```    if !exists('g:airline_symbols')
let g:airline_symbols = {}
endif

" unicode symbols
let g:airline_left_sep = '»'
let g:airline_left_sep = '▶'
let g:airline_right_sep = '«'
let g:airline_right_sep = '◀'
let g:airline_symbols.crypt = '🔒'
let g:airline_symbols.linenr = '☰'
let g:airline_symbols.linenr = '␊'
let g:airline_symbols.linenr = '␤'
let g:airline_symbols.linenr = '¶'
let g:airline_symbols.maxlinenr = ''
let g:airline_symbols.maxlinenr = '㏑'
let g:airline_symbols.branch = '⎇'
let g:airline_symbols.paste = 'ρ'
let g:airline_symbols.paste = 'Þ'
let g:airline_symbols.paste = '∥'
let g:airline_symbols.spell = 'Ꞩ'
let g:airline_symbols.notexists = 'Ɇ'
let g:airline_symbols.whitespace = 'Ξ'

" powerline symbols
let g:airline_left_sep = ''
let g:airline_left_alt_sep = ''
let g:airline_right_sep = ''
let g:airline_right_alt_sep = ''
let g:airline_symbols.branch = ''
let g:airline_symbols.linenr = '☰'
let g:airline_symbols.maxlinenr = ''
```

## Kitchen sinking it on Fedora and Ubuntu

This is probably an overkill solution, but first you need to get it consistently working before you can simplify it.

1. Install the general powerline font `sudo dnf install powerline-fonts` (or `sudo apt install fonts-powerline`) – this should mean that you can use any font you already have installed. If you don’t have an easy way of installing like dnf/apt then there’s instructions for manually doing it e.g. https://www.tecmint.com/powerline-adds-powerful-statuslines-and-prompts-to-vim-and-bash/, also the official documentation has instructions (https://powerline.readthedocs.io/en/latest/installation/linux.html#fonts-installation).

Now close your terminal re-open and check that the Powerline symbols font is available if you edit the terminal preferences and set a custom font. You don’t want to use the font directly, just check that it’s available. Now try opening Vim and see if you have nice symbols.

2. If the general powerline font didn’t work or if you’re trying to improve things you can try installing individual ‘patched’ fonts, this took a while to figure out, but you can literally just go to the folder you want in https://github.com/powerline/fonts/ and download it, the font that I’ve liked the most from my tests is the Source Code Pro patched font. Then just open the downloaded font file and click on ‘Install’.

If you’d rather the command line, you can install all patched fonts:

```\$ git clone https://github.com/powerline/fonts.git --depth=1
\$ fonts/install.sh
\$ rm -rf fonts
```

This will install all the patched mono fonts, but then this gives you a chance to explore the possible fonts. The font list it installs is a pretty awesome list of the available source code fonts. It also means you don’t have to faff around installing each of the individual fonts that get included.

3. Check that the font can be specified in the terminal preferences, re-open your terminal session if you’re missing fonts, so note there could be two options here:
1. The general powerline font is working in which case you can just use the base font e.g. DejaVu Sans Mono
2. If you can’t get that working the patched font that you downloaded above should be correct e.g. the equivalent for DejaVu is ‘DejaVu Sans Mono for Powerline’.

## Handling the delicate flower of Windows

The Powerline Fonts doesn’t work with Windows so your only choice is to use a patched font. Also bash script to install all the fonts doesn’t work. This means that on Windows you manually have to go into each of the fonts directories and download all the fonts yourself and install them by opening each one in turn.

I downloaded all of the Source Code Pro patched fonts and installed them. Even though you install them as individual fonts they get added to Windows as a single font ‘Source Code Pro for Powerline’ with a separate attribute to specify the weight.

Then add this to your `.vimrc`:

``````set guifont=Source\ Code\ Pro\ for\ Powerline:h15:cANSI
``````

If you want to use the ‘Light’ font use this.

``````set guifont=Source_Code_Pro_Light:h15:cANSI
``````

It doesn’t make much sense as it doesn’t need to include the ‘for Powerline’, but that’s how it works (I figured it out by setting the font in GVim and then using `set guifont?` to check what GVim used). Also I spotted that when you use GVim to switch the font, the font rendering isn’t very good. I initially discounted the Light font because when I switched using the GVim menu it rendered badly, but if you put the below into your `.vimrc` and restart GVim it should look lovely.

Also the nice thing is that you can set your DOS/Powershell prompt to the same font.

## Tweaking

Once I actually got it working for the first time, it was really disappointing as the icons didn’t fully match up. But as per the FAQ we need to do some tweaking. I started off with Inconsolata as this gives me a consistent font across Windows and Linux. You can install the general font easily on Ubuntu with `apt install fonts-inconsolata` This is what I got:

The arrows are too large and are shifted up in an ugly manner.

Then I tried all the other default Ubuntu fonts.

Ubuntu mono:

DejaVu Sans Mono:

This has the vertical position correct but the right hand side arrows have a space after them.

### Why you use the patched fonts

Using the default fonts relies on the Powerline font to automatically patch existing fonts. However you can improve the look of the airline symbols by using the patched fonts. These are the equivalents using the patched fonts.

I display these all at font size 16 as I like to use a larger font, plus it shows up minor issues.

Inconsolata for Powerline:

This still has issues, but they are almost all solved by the dz variation.

Inconsolata-dz for Powerline dz:

This has a hairline fracture on the right hand side arrows, but is otherwise perfect.

Ubuntu Mono derivative Powerline Regular:

This still has annoying issues.

DejaVu Sans Mono for Powerline Book:

This has a hairline fracture on the right hand side arrows, but is otherwise perfect. I actually prefer it to the Inconsolata-dz as the LN icon is more readable.

On top of these regulars, I tried almost all the available fonts and my other favourite was Source Code Pro.

Source Code Pro for Powerline Medium

This does have issues at size 16 where the arrows are too big, but at size 14 it’s almost unnoticeable. The branch and LN icons do overflow to the bottom, but somehow this doesn’t annoy me.

Source Code Pro for Powerline Light

This almost completely solves the issues of the medium font’s arrow sizes and makes it about perfect, although there’s still the icon overflow.

### Source Code Pro

When I was investigating the options for fonts there’s a couple of things you notice, some font patches have the absolute minimum in details, if you compare this to the Source Code Pro list it’s quite significant. Source Code Pro is a very detailed and complete font that has been considered to work in a large range of scenarios. This kind of completeness matters for edge cases.

Used as a patched font it almost perfectly displays the vim-airline bar. The benefit of so many alternatives is the use of the light font which has an even better display of the vim-airline bar.

Source Code Pro is also under continued open development on Adobe’s Github repository.

# Self-driving cars should first replace amateur instead of professional drivers

Professional drivers, i.e. lorry, bus and taxi drivers are under threat from being replaced by computers. Whilst amateur drivers, all the rest of us, feel no pressure to stop.

I want to lay out the reasons why this is backwards. Amateur drivers should be replaced, whilst professional drivers should have their skills augmented.

Once we reach a level of self driving automation where no humans are needed then this piece is no longer relevant, but there is a lot of scope to avoid human deaths before we reach that point.

The trolley problem is not the issue, the drunken humans who think its fun to go racing the trolleys are the problem.

This gets long, feel free to skip ahead to a section. This is based on a European centric view point, most specifically UK and Belgian roads.

## Professional vs amateur

Lorry, taxi and bus drivers are professional drivers. They do it for their living. People pay them to drive.

Lorry drivers are paid because they can reliably and safely deliver large amounts of goods over long distances. Billions of euros, every year.

Bus drivers are responsible for transporting 10 – 50 people around each journey. When you consider the value of the cargo, either in human terms or in absolute money (\$5m per person) the responsibility is huge.

Taxi drivers are effectively looking after multi-million dollar cargo. They also have vast local knowledge. A special case of this is the ‘knowledge’ that London taxi drivers must pass. Much of this local knowledge is rendered less important by GPS systems, but still the GPS augments the driver’s knowledge.

These professional drivers, drive all day and in all conditions. They have well maintained cars, and make full use of the cars rather than the cars sitting in garages doing nothing.

Professional drivers are the gold standard of driving styles.

Everyone who is not a paid to drive full time is simply an amateur one. They typically drive for the economic benefit (time saving) or convenience/freedom of having a car.

They typically have people in the car who are personally more valuable than taxi passengers as they are likely family or close friends. But the contrast is that they do not think in these terms. They put a sticker ‘baby on board’ in the back window and assume that will solve the problem.

## Level 3 automation

The current level of self-driving for cars such as Tesla and GM, is level 3. This is where the car can drive but requires constant supervision. This flies in the face of two issues:

1. Humans are good at vision but bad at concentration
2. Computers are bad at vision but good at concentration

With passive level 2 systems in a car, the human uses their vision and the car concentrates for extreme circumstances. Further it helps the human concentration because it keeps them constantly engaged.

With active level 3 systems, the computer is relied on for its bad vision and the human is no longer constantly engaged but expected to keep their bad concentration.

Further there is a major issue of doubt / delayed reactions. With level 2 systems, if the car detects it is about to crash, it does not doubt the outcome and reacts faster than a human could. With level 3 systems if the human detects that the car is about to crash they are in doubt if the computer will avoid a crash and so delay before doing anything.

## Safety

Buses in Belgium are 80% safer than cars (0.4 deaths vs 2 deaths per million passenger miles in 2015). But the figure for cars looks better than it is because it includes taxis. Taxis are do many more miles than amateur drivers and are less likely to crash.

In fact the number of bus crashes are so low that we can almost look at the individual cases for the bus crashes. Also note that a single bus crash can kill up to 30 people, so the number of deadly accidents is even fewer.

Lorry, buses and taxis drive more safely. They avoid all the typical causes of crashes:

• Alcohol
• Tiredness
• Texting
• Calling
• Speeding
• Going through red lights
• Driving erratically
• Having poor eye sight
• Driving too close
• Not changing driving style to bad weather conditions
• Calmness in an accident
• Driving without insurance
• Driving without a licence

Tiredness can be an issue for lorry drivers, but there are strict rules. Automated cars also have these attributes but they don’t have human level performance to handle all situations.

This safety of passengers is the potential route to ending traffic deaths. Once you can look at individual crashes similar as with air crashes then the cause of the crash can be properly understood and recorded. When the number is so many as now aggregate statistics have to be used which will never get the number of deaths down to zero.

Professional drivers can be augmented by the automated driving. Each crash can be analysed and added to the training for the automated car. This means that automated cars will have more knowledge in extreme cases but less in every day. On top of that automated cars can react quicker and without emotion to handle a car that is out of control. Automated systems can be taught to drive at the very limit of the frictional ability of the tires combined with weather conditions.

## Drinking, texting, calling, dozing, tail gating

These are the fundamental problems of amateur drivers. Whilst they are warned about the consequences, the chances are always very low of having an accident so there is always the temptation to drive when incapacitated in some way. There is no standard test that can be enforced on drivers before starting. There is some efforts to put in breathalysers in cars, but the chances are so low that these changes will not get to zero deaths. The only stories I have heard about this are repeat drink-drive offenders and taxi drivers. But this still only stops one aspect, drinking. All the other failures of human drivers have no acceptable solutions.

## Crash vs accident

When trying to focus on the cost of human life vs the cost of professional drivers, the language needs to change to focus on that practically all crashes are avoidable, they are not accidents.

From this CityLab article when talking about road deaths framing it in terms of crashes rather than accidents gives focus to the causes. Each crash should be treated in terms of an air crash. There are no air accidents, and to get down to zero road deaths, there can be no accidents. An accident isn’t necessarily avoidable, but a crash is.

## Bus crashes

Aspects of bus crashes in Belgium are down to single figure deaths per year. When the figures are this low we can consider each case individually. These are some of the causes:

• Driver become unwell such as a heart attack
• A tyre blows out on a motorway cross over and drives off the side

Both these cases would be better handled with automated assistance.

If the driver takes their hands off the wheel the computer can take over and bring the bus to a stop at the side of the road.

If an extreme event such as a tyre blow out or hitting a large patch of ice, the computer is able to be better trained. Simulations can be replayed millions of times and the raw physics of these situations can be well analysed.

## Solve all bus crashes

Each of the situations that caused a fatal bus crash can be analysed and simulated. Then further with simulations the environment can be altered to train the car on other similar situations.

Aircraft pilots train in a similar way. This is the best possible circumstances for training drivers. There is such a long history of bus crashes and the numbers are already so low that there is a realistic chance of preventing all bus deaths across Europe.

But all of this is humans being augmented by computers. They are treated as the safety belt, there to catch exceptional circumstances. All the while computers can be learning from the bus drivers. Especially if the bus drivers have taken their advanced driving test then computers are learning the most consistent and safe method of driving.

## Business cost from crashes on the motorway

One of the potential but more extreme solutions is to ban amateur drivers from the motorway. It could be weakened to allow amateur drivers with an advanced license on the motorway.

One simple argument for this is the business cost of the delays that crashes cause. One crash delays thousands of people and lorries. The ring around Antwerp is a major example.

Reducing road deaths on the motorway to zero is within reach. Reducing the bad drivers on the motorway has a multiplying effect. It takes two bad drivers to crash. One who makes the mistake and the other that is too close.

There are some major issues with this solution:

• It will force bad drivers off the motorway and onto the normal roads. This will increase the death rate off the motorway
• Policing this will be a problem. A simple possibility is to have a letter in the car windscreen for all those with an advanced licence. Effectively a reverse learner sticker

## Lost time to driving

Professional drivers lose no time when driving a car, bus or lorry. There is no other work. They lose the time driving to their work. Effectively during this period they are amateurs too.

But all amateur drivers are losing time. Perhaps it is more pleasurable than being stuck on a train. But it’s wasted time.

The first area where level 4 (fully autonomous) vehicles will become a reality will be on motorways. It would be possible to allow self-driving whilst on a motorway but switch it off once the GPS detects that the car has left the motorway. This would cut down on motorway deaths, save businesses money from less delays and give more free time to commuters.

## The cost of the dead

Those who die in car crashes are a specially tragic kind of death. They almost always have nothing wrong with them. They are mentally and physically healthy. They are also often young and espcially cruel when it is young children, for example pedestrians.

The economic cost is put at \$5m per person based on the amount of output that an average person can have. But the wasted effort is bigger when the person is killed younger. All the training and education has been given but they never get a chance to repay that back into society.

But that does not take into account of the destroyed lives of the families of the victims. Parents who lose their children, siblings who lose their brothers and sisters, children who lose their parents. Further the economic cost of the victims families who struggle to work for years after the death.

Why do people not feel/see this pain? We stick horror photos of smokers on packets, but nothing of the crash victims on cars.

The biggest insult is that of drink drivers. The thought of having your child killed by a drunk driver. Death by human stupidity. Not someone evil just someone stupid.

No other amateurs can do such damage. Professionals practically never do this. There will be cases, but the cases are so few that it is at a level at which no more can be done.

One potential improvement is to increase the requirements of the driving tests. In the UK there is the advanced driving test, which tests candidates in many extreme situations as well as increased road safety and traffic awareness. The insurance premium for advanced drivers is lower.

A further possibility would be to require new driving tests every 10 years and requiring the level of advanced driver.

These tests should also be mandatory for professional drivers but the hope is though that it will be easier for them to pass and they will get the added benefit of lower insurance premiums when driving for themselves.

This will smooth the transition to automated cars as humans will behave at a level that is closer to professional drivers.

## Driving freedom

The major issue with restricting amateur drivers is the freedom and reliance we have on cars.

If we were to restrict who can go on motorways it would restrict poorer people unfairly. They cannot afford to buy expensive automated cars.

Is there research of social status with driving deaths?

But we are not completely restricting driving just on motorways for those without an advanced licence. So the freedom is still there just a bit slower.

Plus retaking your licence every 10 years.

But it is restricting a freedom that exists now. People are happy to accept the deaths for the freedom.

But commuters don’t need the freedom. Take it away from the rich with their business cars with cheap taxes. Commuters could take taxis and buses. Introduce toll roads, the French payage system is perfect. Hike the prices during commuter times but make exceptions for professional drivers.

## Difficulties

There was a bus lane in London that received a lot of complaints and it was eventually stopped because it was too much of a political issue. In Belgium, bus lanes still exist in the slow lane. But it could be a professional lane which means lorries as well. This means that the lane would be fully used.

It would be very unpopular though.

The ultimate is to prevent amateur drivers from using the motorway. But you can’t prevent foreign drivers. You could restrict them to lorry speeds unless they have a pass. The car pool lane, but now the professional or advanced drivers lane.

Bringing in an advanced test and also a 10 yearly driving test. Then you can force up the level of driving. But then the whole population must do a driving test. The system can’t cope now. There’s not enough driving instructors.

## Simulations

The automated test could be increased. Along with sight and danger tests.

Also a focus on time, keeping the 3 second rule, increasing it in rain and ice.

We have a limitation of driving instructors, but driving simulations can be drastically improved. There are very realistic driving simulation games with highly accurate physics. These games are played by children but with no emphasis on them being a useful tool.

This is how pilots are trained, they do thousands of hours in a simulator, repeatedly learning disaster scenarios.

All drivers could be put through multiple simulations of crash scenarios or taking on a skid pan as would happen with a regular advance driving test. They could drive around virtual driving cones until such time as they can master it. Mastery of the situation should be the key.

Currently it is very costly to take a driving theory test. They could be made harder but made a fixed price that allows as many retakes as required. This is a similar concept as put forward for learning with Khan Academy, mastery is the importance, getting 100% on the test whilst allowing as many retakes as required.

A further benefit is that the data collected by the driving simulations can be used to train the AIs. To see how a human handles a crash and also gain insight into the multiple attempts at the same crash and see which methods can be used to avoid a crash.

## Conclusion

The focus should be on improving and replacing amateur drivers whilst augmenting professional drivers. This is a highly unrealistic hope as the focus for self-driving car companies now is simply to cut the human cost of drivers. But the human cost of death should be regarded as a higher priority, with a requirement for public policy to intervene.

# On the power of netbooks and laptops over Android/iOS

iOS and Android turn tablets into oversized phones, so no surprise they lose against phones – they have the same (or usually worse, at a given price point) capabilities while being larger, thus less convenient to carry and more fragile.

Windows did try the same as Android and iOS with Windows RT, thankfully that was a disaster. Certainly that’s one of the bad points about iOS and Android they are so locked down that you have to jump through hoops if you wanted to use them as a work machine. You have almost no access to the file system and you have to pay iPad pro levels of money to get the novelty of having windows side-by-side.

Netbooks are ridiculously useful, I used to have a 15 minute bus ride to work with a 12″ Asus EEE and would manage to fill that 15 minutes with active development time every day. The work I did on that bus became the frontend for what now 10 years later is a \$50m company. On the other end of the scale I spent weeks with my then 7 year-old nephew creating stop-motion animations using the same netbook.

For my current job I bought myself a \$350 refurbished Thinkpad (T430, 8GB RAM, SSD, core i5), this brings me in all my income. You can compare that to people that pay \$1000 for an iPhone X because they get bored of their iPhone 8.

The possible drawback is that a Thinkpad doesn’t have a touchscreen. But with my experiment of buying a laptop with a touch screen I found I pretty much never wanted to use the touch screen, it’s a slower interface than keyboard and mouse. You want the screen in front of you at arms length but then you have to reach with your arm to touch the screen.

I bought exactly the same spec Thinkpad for my 5 year old daughter. The Thinkpad T-series are great because you can pour a litre of liquid over them without problem [0] plus they’re built like a brick, so basically perfect for kids. My daughter immediately covered the grey brick with shiny stickers and gave it a name, ‘Fiona’. In theory Fiona has the full capability to do everything my daughter will ever need for the rest of her school years; I don’t imagine a massive shift away from laptops in schools for the next 15 years. Further to that Fiona’s got Ubuntu installed and I can then install Sugar [1] on top (the same software used for One Laptop Per Child [4]).

I can now teach her over the years what it means to have real freedom with your software and hardware.

P.S. I posted an original version of this on HN [3]