Forem: Yanis

Upcoming ECMAScript features I'm excited about

Yanis — Fri, 22 Jul 2022 13:35:33 +0000

ECMAScript spec train hasn't slowed down anyhow. There are still tons of great proposals waiting for their time.

Here are several of the upcoming ECMAScript features I'm particularly excited about.

Temporal

Docs, Cookbook, Polyfill

The date/time API has always been a weak point of JavaScript. Great libraries like moment.js (already deprecated) emerged to fix this, and they did great.

But now, finally, we got to a point where we can sum up our knowledge and experience and introduce a modern, robust date/time API into JavaScript standard library.

Temporal is a new global object which acts as a module packed with utility functions (like Math). The API is based on immutable objects, and there's excellent support for time zones and non-Gregorian calendars.

Here are some examples.

// parsing a string
const d = Temporal.Instant.from('1969-07-20T20:17Z')

// just plain date
Temporal.PlainDate.from({ year: 2000, month: 8, day: 2 });
// => 2000-08-02

// difference between two points
// in time in different time zones
const { from } = Temporal.ZonedDateTime

from('2020-03-08T11:55:00+08:00[Asia/Hong_Kong]')
  .until(from('2020-03-08T09:50:00-07:00[America/Los_Angeles]'))
  //=> PT12H55M

I recommend skimming through the cookbook to really realize the potential of this great API.

Array grouping

Proposal, Polyfill

This small proposal adds two group and groupToMap to the Array's prototype.

Both methods are used to group items in an array by certain criteria (the closest relative is lodash's groupBy).

  const users = [
    { name: "Jane" },
    { name: "John" },
    { name: "Tom" }
  ]
  users.group(u => u.name.toLowerCase().charAt(0))
  // {
  // "j": [{name: "Jane"}, {name: "John"],
  // "t": [{ name: "Tom" }]
  // }

The groupToMap works similarly but gives us a Map. It might come in handy when we need non-string keys.

Well, and there are other reasons to prefer Maps.

Array's change-by-copy (Stage 3)

Proposal, Polyfill

What's wrong with Array's methods like reverse, sort, or splice? Well, nothing, they are all great. The only problem is that they modify the array in place, making it harder to use them in an FP code.

This proposal introduces 4 new non-mutating methods on arrays (and also on typed arrays) which work similarly, but don't modify the source array: toReversed(), toSorted(), toSpliced(), and with().

The last one is used to replace a single element in an array:

['j', 'a', 'n', 'e'].with(2, 'd')
//=> ['j', 'a', 'd', 'e']

Records and Tuples

Proposal, Playground

Records and tuples are new primitive data structures similar to objects and arrays but deeply immutable.

const record = #{ name: "John", surname: "Smith" }
const tuple = #[1, 2, 3]

The syntax highlights the similarities between them and objects/arrays. All you have to do is to prefix it with #.

Records and tuples can only contain other primitive values (including other records/tuples).

This limitation allows them to be deeply immutable.

It allows makes the equality comparison === work for them like for other primitives. If two records/tuples are structurally deeply equal, the === will return true - and this is a big deal.

Introducing such data structures is a great way to improve the JavaScript functional capabilities (as immutability is crucial in the functional paradigm).

But this is quite a big topic, and I will return to it in a dedicated article.

Where to go next

Those were the great JavaScript proposals I can't wait for. Hope you like them too.

More proposals can be found on the official GitHub page.

Using Git From Vim

Yanis — Fri, 17 Sep 2021 15:59:53 +0000

Git. Everyone loves it. Everyone hates it. Hardly anyone can resist it.

You have just read my best article intro of all time.

Using Git from within Vim can be very beneficial: you don't need to switch context or jump between windows. With some help from our friends (plugins), we can do almost anything from Vim.

Commit message

You probably want to edit your commit messages in Vim.

To do it, add the EDITOR environment variable.

Put this into your .bashrc / .zshrc file.

export EDITOR=vim

As an alternative, set the editor in ~/.gitconfig (this option has a priority over $EDITOR):

git config --global core.editor nvim

The git config command writes the settings into the ~/.gitconfig file. You can edit that file directly as well.

Terminal and external commands

Modern Vim has a built-in terminal. That means you can always start :term and start using Git command-line interface like you're used to.

You can also start a specific command like :term git status or :term git add % (where % refers to the current file path).

For simple commands, even simple bang! command :! (see :help :!) would do. We can run any shell command like :!git status or :!git checkout %.

All those are excellent options, but we can do better.

airblade/vim-gitgutter

The Gitgutter's primary purpose is to show signs in the gutter on the left of what lines have been changed, added, or modified. Here's how it looks.

See those little pluses and minuses on the left. That's it.

While it's on its own quite a nice addition, it also comes with more useful stuff.

You can jump between "hunks" (modified pieces of code) with ]c / ]c.
While at a chunk, you either add/stage it with <leader>hs, or revert/undo it with <leader>hu.
To preview the change, press <leader>hp. That's handy when you need to figure out what has changed.

And it's not all, so check it out.

tpope/vim-fugitive

Tim Pope is the guy behind so many awesome Vim plugins, and this one is his most popular.

It's "so awesome, it should be illegal," as we all agree.

Here's how I use it.

Git without any argument brings up the summary screen. From there, you can use mappings to add files (s), unstage(u), toggle(-), and finally commit your changes(cc). = shows the current diff. There are many more mappings (press g? to see them all).

Git blame shows a commit hash and author near each line of code. Press enter at any lineg, and it will take you to that commit's diff. I use it so often I have it aliased to <leader>a.

You also do diffing, merging, and all the kinds of crazy stuff with fugitive. Have a look at the docs!

tpope/vim-rhubarb

Sometimes we need to open a file in a browser (using Github UI), look around, or send a link to a colleague.

With this plugin installed, it can be done by running :Gbrowse either in normal or a visual mode:

in normal mode, it will open the entire file in the web browser
in visual mode, it will open the file with the selected lines highlighted (with Github, it works by appending a hash to the file's URL, e.g. #L61-L62)

junegunn/gv.vim

This plugin by the FZF author adds a command :GV, which brgings on the Git commit log. Each commit can be viewed right in a split which is very handy.

As you can see, there are many great plugins that will make your life with Git much easier.

There are, of course, others, which you may want to check out as well (though I don't use them, so I can't say if they are any good).

mhinz/vim-signify highlights the changes similarly to git-gutter
lambdalisue/gina.vim another way to create/update commits
sodapopcan/vim-twiggy a fugitive extension for managing branches
jreybert/vimagit a full-blown alternative to fugitive

What's new in ECMAScript 2020

Yanis — Sat, 05 Sep 2020 19:35:45 +0000

ECMAScript 2020, the 11th installment of our favorite programming language, contains a handful of new features. Some are small ones, but others have the potential to change forever the way we write JavaScript.

This article is an attempt at a short and concise overview of those new features. Grab your cup of tea and let's go.

Dynamic import()

ES2015 introduced the static import syntax. Now you could export a variable from one module and then import it in another.

// utils.js
export function splitName(name) {
  return name.split(" ");
}

// index.js
import { splitName } from "./utils";

console.log(splitName("John Snow"));

That syntax is called static because you can't import a module dynamically (depending on some conditions) at runtime. Note that it's not necessarily a bad thing: static imports can be optimized at compile time, allowing for Tree Shaking.

Dynamic imports, on the other hand, when used wisely, can help with reducing bundle size by loading dependencies on-demand.

The new dynamic import syntax looks like a function (but it's not), and it returns a promise, which also means we can use async/await with it.

// ...
const mod = figure.kind === "rectangle" ? "rectangle.js" : "circle.js";
const { calcSquare } = await import(mod);
console.log(calcSquare(figure));

Nullish coalescing

The popular way of setting a default value with short-circuting has its flaws. Since it's not really checking for the emptiness, but rather checking for the falsyness, it breaks with values like false, or 0 (both of which are considered to be falsy).

ES2020 introduces a new operator ?? which works similarly but only evaluates to the right-hand when the initial value is either null or undefined.

Here's a quick example:

const initialVal = 0;

// old way
const myVar = initialVal || 10; // => 10

// new way
const myVar = initialVal ?? 10; // => 0

I wrote a detailed article about this feature and how it compares to the other methods for setting a default value.

Optional chaining

The new optional chaining operator aims to make the code shorter when dealing with nested objects and checking for possible undefineds.

const user = { name: "John" };

// Fails with `Uncaught TypeError: Cannot read property 'city' of undefined`
const city = user.address.city;

// Works but verbose
let city = "Not Set";
if (user.address !== undefined && user.address !== null) {
  city = user.address.city;
}

// Works and concise but requires a 3rd party library
const city = _.get(user, "address.city", "Not Set");

// 🤗
const city = user?.address?.city ?? "Not Set";

BigInt

BigInt is a new object that represents numbers higher than Number.MAX_SAFE_INTEGER (which is 2^53 - 1). While for normal folks, it may sound more than enough, for some math applications and machine learning, the new BigInt type comes in handy.

It comes with its own literal notation (just add an n to a number):

const x = 9007199254740991n;

// or it can be constructed from a string
const y = BigInt("9007199254740991234");

BigInts come with their own algebra, which is not translated to regular numbers by which we can't mix up numbers and BigInts. They should be coerced to either type first.

1 === 1n; // => false
1n + 1; // throws Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions
6n << 3; // nope
6n << 3n; // that works

String.matchAll

So here's an example. Imagine, you have a very long string of text, and you need to extract all the tags (that are words starting with #) out of it. Regular expressions to the rescue!

const tweet = "#JavaScript is full of #surprises. Both good and bad ones #TIL";

for (h of tweet.matchAll(/(#\w+)/g)) {
  console.log(h[0]);
}

// or

const tags = [...tweet.matchAll(/(#\w+)/g)]

matchAll returns an iterator. We could either iterate over it with for..of, or we can convert it to an array.

Promise.allSettled

Remember the Promise.all function? It resolves only when all of the passed promises get resolved. It rejects if at least one of the promises got rejected, while the others may still be pending.

The new allSettled behaves differently. It resolves whenever all of the promises finished working, that is, became either fulfilled or rejected. It resolves to an array that contains both the status of the promise and what it resolved to (or an error).

Thus, allSettled is never rejected. It's either pending, or resolved.

A real-world problem might be removing a loading indicator:

// const urls = [...]
try {
  await Promise.all(urls.map(fetch))
} catch (e) {
  // at least one fetch is rejected here, but there may others still pending
  // so it may be too early for removing the loading indicator
  removeLoading()
}

// with allSettled
await Promise.allSettled(urls.map(fetch))
removeLoading()

globalThis

In JavaScript, there's always one big context object that contains everything. Traditionally, in browsers it was window. But if you try accessing it in Node application, you'll get an error. There is no window global object in Node; instead there is global object. Then again, in WebWorkers, there is no access to window, but there is self instead.

The new globalThis property abstracts away the difference. Meaning that you can always refer to globalThis without caring in which context you are now.

Now, if you think that the naming is rather awkward, I'm totally with you, but note that naming it self or global could make some older code incompatible. So I guess we'll have to live with that.

What's next?

For your convenience, here are the links to the MDN documentation for each of the features mentioned in this article.

Dynamic imports
Nullish coalescing operator but also my own article
Optional chaining
BigInt
Promise.allSettled
globalThis

If you like articles like this, you can follow me on Twitter to get notified about the new ones.

Vim and Language Server Protocol

Yanis — Fri, 28 Aug 2020 14:40:15 +0000

In this article, we'll quickly talk about what is a language server, why we need the LSP protocol, and how to set up it with Vim.

But let's start from the beginning.

What is a language server?

The idea is quite simple. There's a dedicated process running in the background and analyzes your codebase. It's also a server meaning that clients (text editors like Vim, IDEs, what have you) can connect and request some information or ask to perform a certain action.

Language servers usually provide a whole set of operations that a modern IDE is capable of: things like intelligent code completion, auto-formatting, navigation("find the definition of that symbol under the cursor"), refactoring tools("rename that method"), and so on.

If an IDE is a text editor plus some sophisticated code analyzing and refactoring tools, a language server separates those concepts. Now each of the tools can focus on doing their job will - editors can focus on text editing and language servers on language-specific tooling. As long as there is an interface for them to interact with one another, we can benefit from both.

(If that rings a bell, that's because it resonates with the Unix philosophy: Write programs that do one thing and do it well, write programs to work together.)

Now what is a language server protocol?

Historically, every language server author come up his own API, and the client should implement it to make it work.

As you might imagine, that approach is not too extensible.

Imagine you created a new language server, and you want it to work with all the popular editors out there. How can you do that? Well, you now have to go and implement a plugin for each of those editors one by one because your server's custom API is not automatically compatible with a particular client.

That's where the Language Server Protocol (or simply LSP) comes under the spotlight. LSP is an open standard originally developed by Microsoft that governs how an interaction with a language server should look like. It is based on JSON-RPC and defines an interface for how LS clients and servers should interact.

Now we don't need multiple clients - one per each server, we just need one plugin, and since the protocol is the same for all language servers, we don't need anything else.

There are lots and lots of LSP-compatible servers for all sorts of programming languages out there. The quality of the tools (as this is still a nascent area), and the capabilities (some languages are easier to tame than the other) can vary quite a bit.

But for popular languages out there like Ruby, Python, or TypeScript the plank is high. Interestingly enough, the infamous tsserver does not comply with LSP (although it's similar), so we need a proxy to make it work.

Language Server Protocol with ALE

At the moment, ALE doesn't seem to be as popular as coc.vim, so I feel obliged to say a few words about why ALE, and not CoC.

First of all, ALE is so awesome at linting, it's an integral part of my setup anyway. And if I can make it work without introducing another plugin, I try to stick to it.
Second, ALE supports TypeScript (which is not LSP-compatible) directly, so there's no need for a proxy.
Finally (and that might be a bit personal), I find CoC a bit out of place in Vim ecosystem with its own plugin system, and with it's own configuration file (instead of .vimrc). Not to mention the expensive node process it needs to operate.

That being said, I've been using coc.vim as well, and it's a really sharp, high-quality tool. If you find it better for your needs, go ahead and use it.

How does ALE know which server to run?

ALE tries to be smart about your environment. If it's able to find an LSP executable for a specific file type, it will run it and make it work (same goes with linters, ALE doesn't make any difference between language servers, a regular linters in that aspect). For example, if you have typescript installed, and open a .ts file, it will start the tsserver server automatically. In :ALEInfo, you will find something similar to:

(executable check - success) /Users/yanis/projects/web/candl/node_modules/.bin/tsserver
(started) ['/bin/zsh', '-c', '''/Users/yanis/projects/web/candl/node_modules/.bin/tsserver''']

In case, ALE failed to recognise a language server, you can still define it manually (see :help ale-lint-language-servers).

  call ale#linter#Define('filetype_here', {
  \   'name': 'any_name_you_want',
  \   'lsp': 'stdio',
  \   'executable': '/path/to/executable',
  \   'command': '%e run',
  \   'project_root': '/path/to/root_of_project',
  \})

Note, that ALE doesn't support all of the LSP capabilities. So what can you do with the limited ALE's LSP functionality?

Jump To Definition

You can put your cursor on a cursor and run :ALEGoToDefinition, and it will take you to the place where it's defined. It happens in the same window, press <C-o> to jump back. There are also alternative commands, to make it work in a new tab (:ALEGoToDefinitionInTab), and in horizontal(:ALEGoToDefinitionInSplit) or vertical(ALEGoToDefinitionInVSplit) splits. I find the following mapping most natural:

nmap gd :ALEGoToDefinitionInTab<CR> " because I prefer tabs

Find references

Another useful feature is being able to find all occurrences of a function or a variable in the codebase. Again, after putting your cursor on a symbol type :ALEFindRefereneces. It will open up a preview window from which you can jump to any file.

Note that it's different from a simple text search. If you are looking for a class name User, and you also have a string "User" somewhere, the later will not appear in the search results. "Finding references" is aware of the semantics.

A useful shortcut:

nmap gr :ALEFindReferences<CR>

Hover

In modern IDEs, you can hover over a symbol to get a piece of useful information. For example, in TypeScript, it's very common to hover over a variable to see its type. LSPs define a special operation just for that, and you can invoke it through ALE with :ALEHover.

nmap K :ALEHover<CR>

Hover information can be displayed in a hovering window with let g:ale_set_balloons=1 (though it doesn't work in Neovim, as the API is a bit different).

Completion

ALE supports completion via LSP, and "just works" with Deoplete. If you don't use Deoplete, you need to enable

let g:ale_completion_enabled=1

You can also make it work through Omni-completion by setting ale#completion#OmniFunc as autocompletion function, for example:

set omnifunc=ale#completion#OmniFunc

Linting

Finally, linting is the primary purpose of ALE, so it definitely knows how to make it right. In the LSP world, it's called "Diagnostics" by the way.

For ALE, any LSP-compatible server is just one of the possible linting tools it knows hot to work with. So if you're familiar with ALE, there's nothing new here.

TypeScript-only bonus

ALE also defines a couple of useful actions that, at the moment, only work with TypeScript.

The first one is :ALEOrganizeImports, which orders your imports and also removes the unused ones.

The second one is :ALERename. You can rename any symbol, and it will again happen semantically, which is quite handy. By the way, renaming a symbol is something many language servers support, it's just that ALE can only do that for TypeScript. Hopefully, that will change in the future.

Downsides

ALE is a fantastic tool, and I'm very happily using it. It's not without it's drawbacks, and the most obvious one is the lack of full LSP support. It's also sad to see that its development has slowed down quite a bit recently, as the author seem to not have enough time. At the moment of writing, there are 113 pull-request awaiting to get reviewed. Hopefully, this situation will get better.

So personally, I'm very excited about the announced Neovim's built-in support for LSP (since version 0.5). That seems to be both a much more comprehensive solution, but also a native one, so that's probably a way to go if you're using Neovim.

Where to go next

Learn more about LSP on Microsoft page, and for the curious, the detailed specification
Popular Vim LSP clients include ale, coc.vim, LanguageClient-neovim, and vim-lsp).
A native LSP support introduced in Neovim since the version 0.5
Setting up Vim and LSP (among other things) for JavaScript, TypeScript, Ruby, and Python
ALE LSP capabilities :help ale-lsp

Vim for Python

Yanis — Wed, 08 Jan 2020 13:05:00 +0000

I started working on a Python project about a year ago. It was very annoying at first, as I was trying to embrace the Python style and figure out my workflow and the tooling. It took me some time until I finally set the things appropriately.

In this article, I'd like to share how I made a productive Vim-based environment for working with Python.

Disclaimer: For some you, my setup may seem like a bit too much. You don't have to install every plugin listed in this article or copy every configuration line. Pick up what you like.

Essentials

Let's start with a list of some general-purpose plugins which I find irreplaceable for any language.

vim-plug is a minimalistic plugin manager
scrooloose/nerdtree to navigate the file tree
junegunn/fzf.vim fuzzy search through the files (and much more, really)
tpope/vim-commentary ( or scrooloose/nerdcommenter ) — press gcc to comment out a line or gc to comment a selection in visual mode
liuchengxu/vista.vim which is a "tagbar" that learns from LSP servers

The other plugins I use include

jeetsukumaran/vim-pythonsense provides some Python-specific text objects: classes, functions, etc
jiangmiao/auto-pairs inserts closing quotes and parenthesis as you type

The colorscheme used on the screenshots is joshdick/onedark.vim, which is inspired by the Atom theme.

Syntax highlighting

Vim comes with syntax highlighting for many popular languages, including Python, though it is not always the best one.

There are several options to improve the default highlighting.

numirias/semshi, in my opinion, is the best. It works with Neovim only and requires the Python 3 support.
sheerun/vim-polyglot includes support for many languages including Python
python-mode/python-mode is also a decent one although it comes with a lots of other stuff beside highlighting which I don't quite like

My favorite color schemes (which I switch quite often) include junegunn/seoul256.vim and joshdick/onedark.vim (the one on the screenshots).

Indentation

You can set up indentation rules manually like this.

au BufNewFile,BufRead *.py
    \ set expandtab       |" replace tabs with spaces
    \ set autoindent      |" copy indent when starting a new line
    \ set tabstop=4
    \ set softtabstop=4
    \ set shiftwidth=4

A better alternative is Vimjas/vim-python-pep8-indent plugin. It does a much better job complying with the PEP8 style guide.

Folding

Folding (:help foldmethod) is when you collapse junks of code so that they don't distract you from the part that you are looking at right now.

The best approximation is to use the folding method indent though it doesn't work perfectly all the time.

au BufNewFile,BufRead *.py \
  set foldmethod=indent

To toggle a fold you can press za (:help fold-commands), and I have it mapped to Space for convenience.

nnoremap <space> za

Linting & Fixing

The fantastical dense-analysis/ale plugin can be used for linting (which essentially means checking for syntax errors) and auto-fixing extremely well. It's asynchronous, meaning that it won't block the UI while running an external linter, and it supports a great range of languages and tools.

ALE highlights problems with your code in the gutter. When you move the cursor to the problematic line, it shows the full error message at the bottom of the screen.

By default, ALE will use all possible linters it could find on your machine. Run :ALEInfo to see which linters are available and which are enabled.

It is better though to explicitly specify which ones you're going to use with a particular filetype:

let g:ale_linters = {
      \   'python': ['flake8', 'pylint'],
      \   'ruby': ['standardrb', 'rubocop'],
      \   'javascript': ['eslint'],
      \}

Some of the linters are also capable of fixing the problems in your code. ALE has a special command :ALEFix that fixes the whole file. So far, I'm only Google's YAPF as a fixer that formats the whole file when I press F10 or save the current buffer.

let g:ale_fixers = {
      \    'python': ['standardrb'],
      \}
nmap <F10> :ALEFix<CR>
let g:ale_fix_on_save = 1

The last option is a huge time saver — it will automatically fix (and thus format) your file on save.

I also have a little piece of configuration that shows the total number of warnings and errors in the status line. Very convenient.

function! LinterStatus() abort
  let l:counts = ale#statusline#Count(bufnr(''))

  let l:all_errors = l:counts.error + l:counts.style_error
  let l:all_non_errors = l:counts.total - l:all_errors

  return l:counts.total == 0 ? '✨ all good ✨' : printf(
        \   '😞 %dW %dE',
        \   all_non_errors,
        \   all_errors
        \)
endfunction

set statusline=
set statusline+=%m
set statusline+=\ %f
set statusline+=%=
set statusline+=\ %{LinterStatus()}

And here are a couple of alternatives to ALE:

vim-syntastic/syntastic very popular one but synchronous which can cause significant lags in UI
neomake/neomake asynchronous linting and make framework for Neovim/Vim (didn't try that one)

Jedi

Jedi is a "language server", which simply means that it's a separate process that runs in background and analyses your code. Other clients (editors or IDEs) can connect to it and request some information, like completion options, or "go to definition" coordinates.

In order to use it, you need to install it with pip install jedi, and then also add a client.

One option is davidhalter/jedi, which does a very decent job.

Here's what it can do:

Press ctrl + space for the completion options
<leader>d goes to definition
<leader>g goes to assignment
K shows the documentation
and more

Recently I have switched to neoclide/coc.nvim and coc-python. Coc is an "an intellisense engine" for Vim and Neovim and does a really good job when it comes to completion and communicating with language servers.

Coc (Conquer of Completion)

To me, the selling point is the usage of the new floating window API of Neovim, which makes it very convenient.

Coc-python can use both Jedi and the Microsoft's Python Language Server. The first time you run it, it will ask you to install the components it needs (like a linter).

Coc provides (with the help of Jedi) some basic IDE capabilities like

Going To definition

nmap <silent> gd <Plug>(coc-definition)

Displaying documentation (in the floating window!)

nnoremap <silent> K :call <SID>show_documentation()<CR>
function! s:show_documentation()
  if (index(['vim','help'], &filetype) >= 0)
    execute 'h '.expand('<cword>')
  else
    call CocAction('doHover')
  endif
endfunction

Smart rename (renames the exports across all files)

nmap <leader>rn <Plug>(coc-rename)

And of course the auto-complete menu (which you can see on the very first screenshot) appears as you type.

Basically, it's a very solid and comprehensive plugin which covers almost all of our needs.

Read to the wiki for more information about its capabilities.

The drawbacks of using Coc include:

An expensive Node process that Coc needs to run in order to operate
Own independent extension system and its own (JSON) configuration file
The aspiration to do everything

Still, it does the job well, and I continue using it (until there's a better option).

Where to go next?

Here are some other articles I learned from a lot:

And some more articles in the similar vein from this website:

Also, don't forget to Follow me on Twitter ;)

P.S.: I'm writing a book about the modern Vim setup for IDE-like experience. You can check it out here.

Awesome Command-Line Tools

Yanis — Tue, 03 Dec 2019 11:54:29 +0000

Most of the time, when I'm not using Vim, I'm probably hanging around in the command line. Thankfully, there is no lack of excellent CLI tools. Here I'd like to share some of them and how I use them.

For a TL;DR, scroll to the bottom where you'll find a short list with the links.

tldr

Man pages is a fantastic place to look for a documentation and learn how a program works but sometimes what we need is to quickly have a look at examples of how a particular tool should be used. For example I never remember how should to send a POST request with curl.

tldr does just that — prints a short description and then gives you the possible ways of usage. With the most common example at hand I can quickly copy what I need and run.

For Alfred users, here is the workflow for it.
And yes, there's a Vim plugin but somehow I don't find it too useful.

rupa/z

I can't imagine living without this little script. It tracks my most frequently used directories along with the frequency, and then it lets me jump to a directory by typing a partial path.

For example, when I want to get to ~/projects/web/vimfromscratch, I just type z vimf and then hit Enter.

I would also suggest changing the default command name from z to j (as this is much easier for your fingers). You can either create an alias, or set the global env variable:

export _Z_CMD="j"

I have to mention, there are some alternatives you can try:

diff-so-fancy

This tool is a drop-in replacement for diff or git diff. It does the same thing but does it with style. The default colors are much nicer, and the diff shows changes within the same line (see the screenshot).

In order to make it your default Git pager, run this:

git config --global core.pager "diff-so-fancy | less --tabs=4 -RFX"

Then also, you can replace your default diff by setting an alias:

alias diff="diff-so-fancy"

Bat

Now that we started talking about syntax highlighting, have you ever thought of how cat is a bit boring? Wouldn't it be nice if it was able to highlight the syntax of a file that it's printing out?

The answer to this question is bat. bat adds a syntax highlighting for a large number of languages. Plus, it is integrated with Git, so it will show what has changed in the file you're viewing.

You would want to replace your older model:

alias cat="bat"

You can colorize you man page by exporting:

export MANPAGER="sh -c 'col -bx | bat -l man -p'"

For other interesting integration, please have a look at the README.

ripgrep

Ripgrep is an alternative to ag (the silver searcher). It is significantly faster, and also it comes with some sane default behaviour, like respecting your .gitignore file.

As you can see on the screenshot, the output is clear, and the search pattern is highlighted in the output results which is nice.

exa

Another drop in replacement you can use instead of the build-in ls command is Exa. Again, as some other tools in this article exa provides color highlighting and some sane defaults but overall remains compatible with ls API.

alias ls="exa"

# I usually use this command instead
alias l="exa -lahF"

fd

By this time, you probably already figured out that if there is a replacement for some built-in command, I would probably have it installed.

Meet fd, a faster alternative to find. The problem with find is that as I can never remember how to use it. Should it be find myfile.py, or find --name myfile.py, or is it with a single dash? Should I add . before or after the search pattern? Argggh.

With fd, it's always straightforward fd myfile.py. Again that's about saner defaults and beautiful colorized output (see the screenshot).

Don't forget to

alias find="fd"

Fzf

Oh yes, I saved the coolest for the end. Fzf (fuzzy finder) is a super fast tool written in Go which does just one thing: It takes a list of lines as an input and then let's a user fuzzy search in them for some text.

While that may not sound too impressive, the fun part begins with the applications.

For example, try

vim $(fzf)

You'll be prompted with a list of files, and you can search among those. After you press enter, the selected file will open in Vim.

Or, you try pressing Ctrl+R (the command that runs the command history in the shell). You can now fuzzy search among your commands, then press enter to execute it.

While searching for a file, Fzf can give you a nice preview (see the screenshot), you just need to specify the preview command:

fzf --preview="bat {} --color=always"

Remember the rupa/z script? Fzf integrates with it nicely, so if you run z without arguments you can fuzzy search among your most frequently used directories.

Honestly, the list of possibilities how you can use it is really endless. Sky is the limit. Try browsing this page with examples.

What is this thing you're using?

In case you want to know, here is what my setup is based on:

iTerm2 terminal
Menlo typeface
Afterglow colorscheme
Z shell with oh-my-zsh configuration framework
Custom theme for oh-my-zsh
The numbers you see on the screenshots are ruby and node versions.

Tl;DR

tldr for quickly viewing the usage examples
rupa/z for jumping between directories
diff-so-fancy for better diffing
bat to replace cat with
ripgrep for searching pattern within text files
exa a colorful and fast ls
fd a drop-in replacement for find
Fzf for fuzzy search

P.S.: I'm writing a book on Vim for developers. Feel free to check it out.