DEV Community: Alberto de Murga

How to have a Neovim configuration compatible with Vim

Alberto de Murga — Wed, 01 Dec 2021 18:31:15 +0000

So you can have your cake and eat it too.

I have been a Vim user for about 8 years already. Most of this time I have written code using Neovim, and when they announced the Lua integration, I was excited about the possibilities. I use my Vim configuration at home but also at work. In Booking.com, we do a reasonable amount of development in remote machines. Typically, you use ssh to remotely access a machine and do your work there. Many of those machines are quite liberal in regards of installing external packages (which includes Neovim), but other are heavily locked. However, we have an internal system that allows you to copy your dot files when you connect to a remote machine.

For most of these years, I have kept my configuration compatible between Vim and Neovim. Every Vim configuration should work on Neovim by default, but the other way around. I managed to keep the especial Neovim features and plug-ins under wards so if needed I could launch the configuration in Vim if Neovim wasn’t available in the environment. This solution will not work anymore when with Lua plug-ins are involved.

The requirements

These are the MUST have for the configuration.

It must work in Neovim and Vim with similar functionalities so it does not break my muscle memory.
It must be a single configuration that works out of the box. If not, there will be two different configurations de facto.
Neovim can use Lua and external software (for example, language servers or tools like eslint) without limitations. It will be running in my local machine or in a non critical server.
Vim can only use Vimscript. It can use plug-ins as far as they are written exclusively in Vimscript and can be tracked on git. This will run on restricted servers that only allow to copy configuration files.
Minimise dependencies but keep it fast (Lua plug-ins > Vim plug-ins > external tools).

The solution

How my Neovim configuration directory looks like.

This is how my (Neo)vim configuration looks like. The directory lives in $HOME/.config/nvim, which is the default location for Neovim. When I need to use Vim, I set two symbolic links: $HOME/.config/nvim → $HOME/.vim and $HOME/.config/nvim/init.vim → $HOME/.vimrc

init.vim : It is the entry point of the configuration. It loads the plug-ins using vim-plug, which will work for both. It also defined where the plug-ins should be located and which plug-ins to load depending on if it is Neovim or Vim. Additionally, it loads all the other configuration files.
common.vim : It contains the common configuration like some of the bindings, tabs, word wrapping, etc. All these configurations are classical vim configurations and are the same for both. The rule of thumbs is that anything that is valid for both and not a plug-in goes here. If there are inconsistencies between platforms, the Neovim versions takes priority.
plugins.vim: The complementary of common.vim. Every plug-in configuration used in both versions goes here for instance, like NERDTree, easymotion or lightline.vim.
only_vim.vim : Self explanatory. These are the configurations that should be loaded only in Vim. They are mostly inconsistencies between platforms that require extra configuration or Vim only plug-ins. Because it is loaded after, it will overwrite Neovim’s configurations.
languages : This directory contains custom languages configurations used by both versions, with one file per language and one additional file as a kitchen sink. For instance, the file languages/golang.vim changes the configuration of the tab to use tabs instead of spaces when editing a \*.go file.
lua : Contains all the Lua code for Neovim. It is a requirement of Neovim to place the Lua code here. Neovim configuration takes place and precedence in the common files, which means that this folder mostly contains the configuration of the Lua plug-ins. Every file is the configuration for a concrete plug-in, plus other.lua as a kitchen sink. These plug-ins typically require heavy configuration because they set up language servers bindings, syntax highlight, autocomplete, etc. There is an additional folder, languages, which adds additional information required by the plug-ins that can be split by language. Most of the content is the configuration of the different language servers.

The order of loading the plug-ins in init.vim matter

Some cool plug-ins that I use and their equivalences

This is a bit off-topic, but this is a selection of some of the plug-ins I use and their equivalences between Vim and Neovim. For the full list of all the plug-ins in my configurations, you can check the init.vimfile on Github. Remember that you can always use the Vim plug-ins in Neovim, but not the other way around.

Extra tricks

This snippet will help you to load plug-ins conditionally using vim-plug.

" Lazy loading
" From [https://github.com/junegunn/vim-plug/wiki/faq#conditional](https://github.com/junegunn/vim-plug/wiki/faq#conditional-)-
" activation                            
function! Cond(cond, ...)
    let opts = get(a:000, 0, {})     
    return a:cond ? opts : extend(opts, { 'on': [], 'for': [] }) endfunction

These two variables can be used for distinguishing between Vim and Neovim. Technically you only need one, but it is more descriptive to have both. Defining the base path also helps as vim-plug needs to be able to find them in the right place.

let is_vim = !has('nvim')
let is_nvim = has('nvim')

if is_nvim
    let $BASE = stdpath('config')  
else     
  let $BASE = '$HOME/.vim'                             
endif

call plug#begin($BASE.'/plugged')

Did you like this post? Let me know on Twitter!

How to use bookmarks in bash/zsh

Alberto de Murga — Sat, 04 Sep 2021 12:19:19 +0000

Moving around your terminal effectively is going to make you more productive. Sometimes you need to quickly move between different projects or directories located in different places in your machine. For instance, maybe your code lives in ~/project/my-project, but the configuration of the server is in /etc/... Remembering locations is inefficient, and often they take longer to write. What if there is an easy, inexpensive solution in 4 lines of bash?

How my bookmarks look like

How to install

Here is where the magic is. Add these 4 lines of code to your bashrc or zshrc file.

if [-d "$HOME/.bookmarks"]; then
    export CDPATH=".:$HOME/.bookmarks:/"
    alias goto="cd -P"
fi

Additionally, you need to create the directory in your home folder or wherever it suits you, just remember to update the CDPATH variable above.

mkdir ~/.bookmarks

How to use

To add a new bookmark, you just need to create a symbolic link to the folder in your bookmarks directory. I suggest you start all the bookmarks with the same character. This way, the autocomplete will suggest to you all the bookmarks available once you type the character. In my case, I chose the symbol @ . If you want to edit or remove the bookmark, delete the symbolic link and/or create a new one.

ln -s path/to/certain/directory/with/my/project @important-project

How does it work?

The magic here is in the $CDPATH variable. $CDPATH is a colon-separated list of directories used as a search path for the cd built-in command. It behaves like the $PATH when resolving binaries. The $CDPATH we define first attempts to locate the directories in the current directory, then in our bookmark’s directory, and finally in the root. Because we are using always the same starting character, if we type it, it will suggest all the bookmarks we have defined.

Additionally, we also declare an alias for cd named goto. The option -P will resolve the symbolic links moving us to the directory instead of the symbolic link.

WTF is “0 but true”

Alberto de Murga — Fri, 07 May 2021 06:59:26 +0000

I have spent most of my life coding with JavaScript. For me, it is natural to use, and I know by heart most of its quirks and oddities. I understand many of these are quite strange for newcomers and can generate some aversion. However, recently learnt about one of these things in Perl that makes JavaScript oddities look amateurish.

Perl? What is that?

Perl is a scripting programming language that was quite popular in the early ’90s and lately has fallen in usage, although at the moment of writing it is still in the top 20 in the TIOBE index. It is still widely used in bioinformatics, sysops and projects like git or the Linux kernel among many others. Perl is well known for its concise although often cryptic syntax and powerful one-liners and regular expressions. This is also its curse as it has been accused of being hard to maintain and “write-only”.

Perl shares many similarities with languages like Python, JavaScript or PHP. Its variables may have different types, each one of them prefixes the variables names with a different sigil, similar to PHP: $scalar and list, which may be @array or %hash.

Understanding Perl

The scalar represents a single value, that can be a string, a number, a float, or a reference to a list. We will not get deep into this, but the important idea is that Perl will transform between these different values depending on its needs as other scripting languages do. However, this sometimes is not explicit and it will complain if you use the wrong operator with the wrong type.

0> my $aString = "string"
$res[1] = "string"
1> $aString == "string" ? "true" : "false";
Argument "string" isn't numeric in numeric eq (==) at reply input line 1.
Argument "string" isn't numeric in numeric eq (==) at reply input line 1.
$res[2] = "true"
3> $aString eq "string" ? "true" : "false";
$res[3] = "true"

In the example above, we can see that Perl complained because we used a numeric operator instead of a string operator. Typically, we would execute the script in strict mode without warnings, which will give an error and stop execution.

Perl does not have a boolean type, but different values will be evaluated as “true” or “false”. Quoting the official documentation:

The number 0, the strings ‘0’ and “”, the empty list (), and undef are all false in a boolean context. All other values are true. Negation of a true value by ! or not returns a special false value. When evaluated as a string it is treated as “”, but as a number, it is treated as 0.

What is special about "0 but true"

"0 but true" :

It is a string …
that can be used as 0 …
but evaluates as true.

So, we can operate with it like any other string:

0> my $zeroButTrue = "0 but true";
$res[1] = "0 but true"
1> split " ", $zeroButTrue;
$res[2] = (0, "but", "true")

but we can also do some maths!! This will not work with other strings if we have strict mode and warnings enabled.

2> 10 + $zeroButTrue;
$res[3] = 10
3> my $oneString = "1 string";
$res[4] = "1 string"
4> 10 + $oneString;
Argument "1 string" isn't numeric in addition (+) at reply input line 1.
$res[5] = 11

However, we can see as well that this is not how 0 behaves:

5> $zeroButTrue ? "true" : "false";
$res[6] = "true"
6> 0 ? "true" : "false";
$res[7] = "false"

But why?

The reason behind this odd behaviour is the way *nix systems handle process returns. In these systems, when a process returns 0, it means success or true, the opposite as in Perl or almost any other programming language. Any other number different from 0 is an error, being the value of the output of the error code. Taking these values without processing will create output. Therefore, instead of returning 0, it will return 0 but true and if it is an error, it will return the error code as a value. Error codes are still evaluated as a number, hence they will evaluate as true.

This magic string is indeed a curiosity, and this could have been fixed by simply inverting the result of the return when evaluating (or using unless instead of if), also making the errors evaluate to false. There could be other design decisions for this choice that I am not aware of, but at the same time, it is a fun oddity that will always surprise beginners without being likely to harm them by chance.

References

TC39 proposal: Record and Tuples, the real immutable data structures in JavaScript.

Alberto de Murga — Mon, 26 Apr 2021 11:56:40 +0000

This article was originally published in Medium

Records and tuplesOne of the misleading use cases for beginners in JavaScript is to create constant arrays and objects. With the introductions of ES6, we got two new declarators: let, for mutable variables, and const, for constants. Many beginners believe that this will make their objects and array immutable, to discover later that they are not. The object or array itself is immutable, but not their content. So far, we have relied on the method Object.freeze to deal with this use case.

// This is supposed to be immutable, isn't it?
const obj = { a: 1 }
obj.a = 2
console.assert(obj.a === 1, 'wtf')
// Assertion failed: wtf

Introducing Record and Tuples.

Records are immutable arrays. Tuples are immutable objects. They are compatible with Object and Array methods. Essentially, you can drop a Tuple or a Record in any method that takes an object, or an array and it will behave as expected, unless this implies to modify the element. This applies to method of the standard library, iterators, etc.

// Record
const record = #{ x: 1, y: 2 }
// Tuple
const tuple = #[1, 2, 3, 4]
// We can use most of the methods that work with Arrays and Objects.
console.assert(tuple.includes(1) === true, 'OK, it will not print')
// Although they will return tuples and records.
console.assert(Object.keys(record) === #['x', 'y'], 'OK, it will not print')
// Iterators work too
for (const element of tuple) {
    console.log(element)
}
// 1
// 2
// 3
// 4
// And you can nest them!
const nested = #{
  a: 1,
  b: 2,
  c: #[1, 2, 3]
}
// Nope
tuple.map(x => doSomething(x));
// TypeError: Callback to Tuple.prototype.map may only return primitives, Records or Tuples

// This is ok
Array.from(tuple).map(x => doSomething(x))

However, with great power comes great responsibility.

The power

Comparison by value: Like other simple primitive types, they are compared by value, not by identity. Objects and arrays are equal if they are the same entity. Tuples and records are equal if they contain the same elements.

const objA = {a: 1}
const objB = {a: 1}
const objC = objA
console.assert(objA === objB, 'Same content, but different entities, false')
console.assert(objA === objC, 'They are the say, it will not print')
const recordA = #{a: 1}
const recordB = #{a: 1}
const recordC = recordA
console.assert(recordA === recordB, 'OK, will not print')
console.assert(recordA === recordC, 'OK, will not print')

You can convert to objects and array and the other way around: Using the functions Record() and Tuple.from().

const obj = { ...#{a: 1, b: 2}}
const record = Record({a:1, b:2})
const arr = [ ...#[1, 2, 3]]
const tuple = Tuple.from([1, 2, 3])

They are identified as distinct types: Using the operator typeof returns unique names for each of them.

console.assert(typeof #{a: 1} === 'record', 'this will not print')
console.assert(typeof #[1, 2] === 'tuple', 'this will not print')

The responsibility

They can only contain primitive types: They can only contain String, Number, Boolean, Symbol, BigInt, undefined, null, Record and Tuple. This is, no functions, objects, arrays, classes, etc.
You can use them in Maps and Sets, but not with WeakMaps and WeakSets: Quoting from the spec

It is possible to use a Record or Tuple as a key in a Map, and as a value in a Set. When using a Record or Tuple here, they are compared by value.
It is not possible to use a Record or Tuple as a key in a WeakMap or as a value in a WeakSet, because Records and Tuples are not Objects, and their lifetime is not observable.

JSON.stringify will work as expected, but JSON.parse will still return objects and arrays: There is a proposal to add JSON.parseImmutable which will behave like JSON.parse but returning records and tuples instead of arrays and objects.

Conclusion

This addition is welcomed as it has been a struggle to define immutable values in JavaScript, and confusing for many beginners. Prior solutions implied using external libraries like Immutable.js, workarounds in the standard library like Object.freeze or conventions to achieve similar results.

The proposal is currently on stage 2, so it is subject to changes. However, it already looks solid and I personally hope it makes it through and becomes a standard.

References

Proposal spec [github, web]
Playground (beware, the current specification is not fully implemented)
Tutorial
Cookbook

Go 2 generics in 5 minutes

Alberto de Murga — Fri, 05 Feb 2021 07:44:13 +0000

Go 2 generics in 5minutes

Two generic gophers. Photo by Lukáš Vaňátko on Unsplash

The inclusion or not of generics in the Go language has been a long-standing discussion and cause of drama since the first appearance of the language in 2009. Rivers of ink have been poured in long discussions about if generics are good or bad, and if the language needs to support them or not. Up to this moment, the Go team has decided to leave generics outside the language.

However, with the announcement of the second version of the language, the Go team opened the discussion to add generics to the language. There have been different drafts about how to add generics finally settling down in what it seems a final design draft.

Generics in bullet points

The draft is quite long but not as dense as it could have been expected for such a document. It is important to highlight that the objective of the Go team is to create a backwards compatible design which addresses people’s needs for generics without making the language more complex than necessary.

The specification can be summarised in the following bullet points, that we will develop after. However, it is advisable for anyone interested in the topic to read the full document linked at the bottom of the article. We are assuming that the reader is familiar with basic Go concepts like functions, types, and interfaces.

Functions and types can have an additional type parameter list in front of the normal ones using square brackets to indicate the generic types used. These type parameters can be used like any other parameter in the rest of the definition and body.
The type parameters are defined using constraints, that are interface types. Constraints define the methods required and types permitted for the type argument and describe the methods and operations available for the generic type.
We can use type inference which will often permit omitting type arguments.
We have a special constraint named any which behaves similarly to interface{}, and a new package named constraints which will have commonly used constraints.

Defining and using generic functions

Functions can take an extra list of parameters surrounded by brackets instead of parenthesis, and they can be used as part of the definition and or the body. These type parameters behave like normal parameters and they follow the same rules as the traditional parameter. These parameters will have an “interface” named constraint as a type, or the special interface any. Types can also have type parameters when defined.

// [https://go2goplay.golang.org/p/Z9e7O8ony21](https://go2goplay.golang.org/p/Z9e7O8ony21)
type queue[T any] []T

q := new(queue[int])

Functions’ type parameters can be used in the body of the function, and types using type parameters can be used in the module without restriction . The requirement to use them is to pass a type argument that fulfils the interface. It is like assigning a variable of interface type: the type argument must implement the constraints of the type parameter, and the generic code can use only the operations permitted for the constraint or permitted for any type.

// [https://go2goplay.golang.org/p/s8JCfu5qBKz](https://go2goplay.golang.org/p/s8JCfu5qBKz)
func Print[T any](s []T) {
    for _, v := range s {
        fmt.Print(v)  
    }
}

strings := []string{"Hello ", "world"}
Print[string](strings)
// Output: "Hello world"

nums := []int{1,2,3}
Print[int](nums)
// Output: 123

Defining constraints

Constraints are interfaces. You can expect the same features of interfaces on constraints, like embedding one constraint in other. Constraints have one addition to interfaces. Constraints may list explicitly types that may be used as type arguments by using the type keyword followed by a list of comma-separated types.

// [https://go2goplay.golang.org/p/qWeRkYjjtKP](https://go2goplay.golang.org/p/qWeRkYjjtKP)
type SignedInteger interface {
    type int, int8, int16, int32, int64
}

Constraints can be defined and exported as libraries, and the Go team stated that they would likely define and export a new standard library tentatively named constraints that would contain commonly used constraints.

The “any” constraint

The any type is like the type interface{}. It is a constraint that whatever type can fulfil. However, it still has a few rules it needs to abide. Once you assign it a type to it, you need to keep using the same one. You can declare variables, pass, or return variables to other functions, take the addresses… but always the same type. You can convert or assign values of those types to the type interface{} and use type assertion to convert them back. You can also use the type as a case in a type switch.

// Vector is a name for a slice of any element type.
type Vector[T any] []T
func (v *Vector[T]) Push(x T) { *v = append(*v, x) }

// T is []int
var v Vector[int]

// func (v *Vector[int]) Push(x int) { *v append(*v, int) }
v.Push(1)

// Output: [1]

Type inference in generics

In many cases, we can use type inference to avoid having to explicitly write out some or all the type arguments. If you pass an argument to a function and other types depend on it, they can be inferred without explicitly saying it. It works in the same way as when you use a variable of a certain type as a parameter instead of a function which has an interface as an argument.

func Map[F, T any](s []F, f func(F) T) []T { ... }  

var s []int 
f := func(i int) int64 { return int64(i) } 
var r []int64

// Can be used in all these ways

// Specify both type arguments explicitly. 
r = Map[int, int64](s, f) 

// Specify just the first type argument, for F, 
// and let T be inferred. 
r = Map[int](s, f)

// Don't specify any type arguments, and let both be inferred.
r = Map(s, f)

This part gets extremely messy extremely fast, so I cannot stop recommending to real the whole specification where this section is explained in deep detail. The important part to understand is that in many cases we will not need to specify all the type parameters explicitly.

Disclaimer and references

This article is based on the following article, thread, and document. As it is a draft, it might change since the moment of publishing this article. To ensure corrected in all the examples, they have been extracted from the specification or from the Go 2 playground, where you can already head to if you want to test them by yourself.

This article was originally published here

Embedding files natively in Go 1.16

Alberto de Murga — Fri, 25 Dec 2020 10:12:42 +0000

Gophers with a wrench by Renee French

One of the most commonly noted upsides of Go is the compilation to a single binary. This makes deployments and dependency requirements easier to handle compared to other languages that require to install in the target system the individual dependencies which can potentially conflict with other software running or require to install duplicated packages.

However, sometimes Go programs not always can be reduced to a single file. Assets like templates or images are not included as part of the binary and they need to manage and deployed independently. Although this has its benefits, like customising templates without having to recompile the whole program, it loses the benefits of a single unit when you do not want or do not expect to make a change in the assets, like with games.

Traditionally, we have relied on third-party packages like go-bindata or statik to embed static assets in Go binaries. These tools essentially require to run a command against the assets we want to embed to create a Go file which contains a binary representation of them. Later, you import this generated file in your code and you access the files using some key based on the path or a virtual file system.

These solutions have some issues in terms of development experience. They require an extra step to add/update assets every time they change and having the tool available in each environment in some concrete version. It is also an external dependency, which might be complicated to adopt in certain corporate environments. Also, to keep the component “go-getable”, you need to commit the generated files, which is not ideal either.

In version 1.16 (not available yet as of December 2020), the Go team has introduced a new package named embed which solves these trade-offs by embedding the files during the building of the binary. Hence, we don't need to run additional commands before running go build or to track generated files. The go build system will recognise the directives and populate the variables with the matching files.

How it works

General conditions

If any patterns are invalid or have invalid matches, the build will fail.
The directive must immediately precede a line containing the declaration of a single variable. Only blank lines and comments are permitted between the directive and the declaration.
Patterns must not contain . or .. path elements nor begin with a leading slash.
To match everything in the current directory, use *.
Patterns must not match files outside the package’s module, such as .git/ or symbolic links.
Each pattern in a line must match at least one file or non-empty directory.

Embedding a file as a string

The files are stored as string or []byte.
You can use a single go:embed directive per variable.
The directive must refer to a single file.
You can use a blank import.

package mypackage

import _ "embed"
import "fmt"

//go:embed README.md
var r string

//go:embed image.png
var img []byte 

func main() {
    fmt.Println(r);
}

Embedding several files as a file system.

The files are stored as embed.FS
embed.FS is read-only and safe to use from different goroutines concurrently.
embed.FS implements fs.FS, so it can be used with any package that understands file system interfaces
You can use a single or multiple go:embed declarations. Each declaration can refer to one or multiple paths separated by spaces.
If a pattern names a directory, all files in the directory are embedded recursively, except that files with names beginning with . or _ .
If you use * after the directory, it will add also files prefixed with . and _ .

package mypackage

import (
    "embed"
    "net/http"
    "log"
)

// It will add the specified files.
//go:embed favicon.ico robots.txt index.html
// It will add all non-hidden file in images, css, and js.
//go:embed image/ css/ js/
// It will add all the files in downloads, including hidden files.
//go:embed downloads/*
var static embed.FS

func main() {
    http.Handle("/", http.FileServer(http.FS(static)))
    log.Fatal(http.ListenAndServe(":8080", nil))
}

For more information, check the references below. Do you have any feedback? You can reach me on Twitter or leave a comment below.

References

Changelog

2020–02–01: As pointed in the Medium comments, the article had a typo in the code directives, which should not contain a space.

This post was originally published at Medium