DEV Community: Dylan Irlbeck

Kitty Sessions

Dylan Irlbeck — Tue, 05 May 2020 16:36:54 +0000

Kitty is a super-fast, customizable, and GPU based terminal emulator. I recently switched over to Kitty from iTerm, and I could not be more satisfied. However, Kitty's speed is not the only great thing about it; in fact, Kitty has built-in support for tmux-like sessions and windows, allowing you to create powerful setups with no extra tools!

Sessions

One of the best features about Kitty are startup sessions. Sessions allow you to create one or more tabs on startup (or with the kitty --session command) and customize each tab with a unique terminal configuration. For example, my current startup.conf looks like this:



# startup.conf
new_tab tailwind_ppx
cd ~/Code/reason/tailwind_ppx
title vim
launch zsh -c 'nvim'
launch zsh -c 'esy watch'
launch zsh
enabled_layouts tall:bias=50;full_size=1
layout tall

new_tab other
cd ~
launch zsh
enabled_layouts tall:bias=50;full_size=1
layout tall

which sets up two tabs when I launch Kitty: the first is a Reason native project (in particular, tailwind-ppx) and the second is a new tab that I can use for whatever I need to. This configuration looks like this:

"Dynamic" Sessions

Normal startup sessions are great if you've hard-coded the desired working directory for the session into the .conf file, but what about when you want to start a session and you don't know the directory? With a little help from zsh, we can implement what I'm calling "dynamic" Kitty sessions. Essentially, we're going to create a command that allows you to launch a new Kitty session given the path to a project. For example,



$ kt-native ~/tailwind_ppx # Launch a Reason native session
$ kt-js ~/some_js_project # Launch a JavaScript session ```

As you can start to see, there's a lot of customization we can do in the middle, but hopefully you get the basics of what we're trying to do.

Defining our session configurations

Let's start by defining our session. Personally, I've
created one session file per type of project I work with (Reason native, BuckleScript, JavaScript, etc.), and it's worked well for me thus far.

Note that you can put your session files wherever you'd like, so long as you properly provide the path in your .zshrc (see the section on aliases below)

For example, here's my session for a Reason native project:



// ~/path/to/reason_native.conf

new_tab reason_native
cd ${PROJECT_DIR}
title vim launch zsh -c 'nvim'
launch zsh -c 'esy watch'
launch zsh
enabled_layouts tall:bias=50;full_size=1
layout tall

Notice the PROJECT_DIR environment variable above --- this variable will be set automatically before Kitty is launched, so stay tuned.

Creating launch aliases

Now that we've created the session configuration files, we'll move on to creating shortcuts in zsh so instead of doing this:



$ export PROJECT_DIR=/path/to/reason_native_project
$ kitty --session ~/path/to/reason_native.conf

we can just do



$ kt-native /path/to/reason_native_project

Since these shortcuts will take in an argument (namely, the path to a project), all we need to do is add a function in our .zshrc that will act as our alias.



// ~/path/to/.zshrc

# Kitty functions
function kt-native() {
  export PROJECT_DIR=$1
  kitty --session ~/path/to/reason_native.conf
}

And that's it! Now you can launch a new Kitty session based on the type of project, without hard-coding all the file paths of your projects into separate .conf files beforehand.

Hopefully this tutorial/intro was useful! If you're curious in learning more, I'd check out the Kitty docs. In addition, I've published my personal Kitty setup, along with the rest of my dotfiles, on GitHub. Cheers!

Intro to PPXs, for Reason newcomers

Dylan Irlbeck — Tue, 28 Apr 2020 21:52:43 +0000

ReasonML (also known as Reason) has gotten very popular these days. It's a new syntax for OCaml that looks a lot like JavaScript, allowing you to develop with a rock-solid type system while still having strong interop with JavaScript and its strong ecosystem.

That was a mouthful, I know. For a proper introduction (if you aren't familiar), I'd highly suggest reading through the official Reason docs!

Now let's get into the point of this post - Reason PPXs.

What is a PPX and Why Do I Care?

A Pre-Processor eXtension (PPX) is a preprocessor that is applied to your code before it gets passed to the compiler. It allows for arbitrary manipulation of your code's Abstract Syntax Tree, rather than the code itself.

For example, if you have ever written GraphQL queries in your Reason code, chances are you've used [%graphql {|QUERY|}] to validate your queries - this is a PPX! In the case of graphql_ppx , your query will be validated and is guaranteed to be type-safe. The query is then transformed into a normal string before your code is compiled.

Another example is tailwind-ppx, a PPX I wrote to validate your Tailwind CSS classes at compile-time. Using this PPX, you can write your class names like <Component className=[%tw "flex flex-row"] /> and get validation for zero extra cost (in case there's a typo in a class name or you included a class name twice, for example).

PPXs are very powerful, but I found it rather difficult to get a barebones one up and running. Though I tried hello-ppx-esy and eventually found some success, it seemed that the process should be friendly to both Reason newcomers and PPX newcomers, rather than just the latter. Namely, I felt that (1) Reason newcomers should not have to use esy, (2) it should be more natural to run tests, and (3) publishing your PPX should be straightforward.

`hello-ppx-bucklescript`

hello-ppx-bucklescript is a small Github project I wrote a while back that provides the boilerplate for writing a Reason PPX. It takes care of configuring the BuckleScript compiler, hooking up tests, and generating your PPX executable. hello-ppx-bucklescript was inspired by hello-ppx-esy, but differs in that you do not need esy, running tests is simple with yarn test, and it includes a publish folder for making your PPX immediately available on the NPM registry.

Project structure

publish/ - basic setup for publishing your PPX to the NPM registry.
src/ - contains the source code for the PPX.
tests/ - a single test file that can be run with yarn test

PPX source code

The ppx included in the project essentially turns the [%hello] expression into the integer literal 42 at compile-time. The code to do this operation is this:

open Ast_mapper;
open Parsetree;
let expr = (mapper, e) =>  
   switch (e.pexp_desc) {
   /* If the expression is [%hello] */  
   | Pexp_extension(({txt: "hello", loc, _}, _payload)) =>    
     /* Then replace by 42 */
     Ast_helper.Exp.constant(Asttypes.Const_int(42))  
   | _ => default_mapper.expr(mapper, e)  
   }; 
let mapper = _ => {...default_mapper, expr}; 
let () = run_main(mapper);

Let's walk through each part.

open Ast_mapper;
open Parsetree;
Use the open directive to make the Ast_mapper and Parsetree modules directly accessible by the Hello module. See here for more information on modules.
let expr = (mapper, e) =>  
   switch (e.pexp_desc) {
   /* If the expression is [%hello] */  
   | Pexp_extension(({txt: "hello"}, _)) =>    
     /* Then replace by 42 */
     Ast_helper.Exp.constant(Asttypes.Const_int(42))  
   | _ => default_mapper.expr(mapper, e)  
   };

expr is a function that takes in a mapper and an expression and returns a new expression. For the [%hello] PPX, expr is the function that we care about most.

switch (e.pexp_desc) {
   ...
}

Here we're going to switch on the value of the pexp_desc property of the input expression. pexp_desc is of type expression_desc, and thus can have many different constructors (see its type here) - however, all we really care about is if it's a PPX extension (Pexp_extension) and the extension name is hello!

| Pexp_extension(({txt: "hello", _}, _)) =>
   ...

If we fall into this case our expression matches the Pexp_extension constructor, and as a result, we need to modify the AST! We can ignore the other properties of a Pexp_extension, since all we care about is that the txt (the extension name) is hello and not something like graphql or tw. We'll replace the AST with the integer literal 42, and then we're done!

| Pexp_extension(({txt: "hello", loc, _}, _payload)) =>
  /* Then replace by 42 */
  Ast_helper.Exp.constant(Asttypes.Const_int(42))

That's it! The rest of the code is just PPX boilerplate that doesn't need much conceptual understanding. Feel free to ask questions below if you're confused, though!

Sources

I could not have written this article, nor created hello-ppx-bucklescript or tailwind-ppx, without the following [%incredible] sources:

Thank you for reading! And please check out tailwind-ppx if you're thinking about building a new ReasonReact + TailwindCSS project!