These generators usually rely on some form of directory structure to make sense of your website. They also try to be very generic and provide as much functionality as possible out of the box. In this quest for broad utility they all end up making generating a static site more complicated than it should be. There’s many functions, many taxonomies, you need to learn their templating language (or use a javascript frontend framework which is then prerendered), know which block thingy to wrap your html around, etc.

All this rigmarole is simply a waste of time. All you wanted to do was render some html and display some information but now you’re forced to understand all this machinery, possibly debug why you can’t get it to do exactly what you wanted, and they might’ve broken the API and now you’re forced to go and update your website’s template just because of someone else’s whims.

You do not need a general purpose static site generator

What you want is to be able to write some markdown or some other format of your choice and have it be translated to the verbose html equivalent with a little bit of styling. Static site generators are glorified string appenders. You can write your own in half an hour and just add more functionality as you need them.

The initial set up might be slightly annoying but once you have the base built, building on top of it is way easier. There’s no more arbitrary breaking changes because of things you never even cared about. You no longer have to spend time digging documentation and forums for answers on how to do something, you can just do it. You’re in total control.

How your regex is ran

To be run, your regex first goes through a few steps:

1. Tokenizing - the regex is read and converted into tokens
2. Parsing - the tokens are converted into a syntax tree that can be walked through and more easily worked with by code
3. Compilation - the syntax tree is read and compiled into instructions for a regex virtual machine
4. Optimization (optional) - the instructions are ran through an optimizer and then turned into more efficient code

By the time all of this is done your program has run through a couple thousand lines of code. Now you have a compiled regex expression and can run it through the regex virtual machine.

Regex is bad

From a performance standpoint, doing all those steps already is much slower than calling any small function. Running through a virtual machine means at least a few levels of indirection which is likely to thrash the cache and just runs a lot more code to do the same thing. So just by using regex, you’re letting go of performance. But ok, you don’t care about performance. I get it, no one cares about performance anymore. So let’s look at the other reason why regex is bad.

Regex is unmaintainable

Comprehending any reasonable complex regex expression is a huge waste of time. Let’s look at this example I copied from stackoverflow:

"^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d]{8,}$"

Can you guess what it does at a glance without opening the link, seeing a comment or using one of those regex explainer tools? Probably not. Here’s what it does:

Minimum eight characters, at least one letter and one number

Now look at what the alternative is:

// note: isAlphanumeric, isNumber and isAlpha are not real javascript functions
// but they're here to prove a point not to write absolutely correct code
function isValidPassword(password: string): bool {
  if (password.length < 8) {
    return false;
  }

  let charCount = 0;
  let numCount = 0;

  for (const c of password) {
    if (!c.isAlphanumeric()) {
      return false;
    }

    if (c.isNumber()) numCount += 1;
    if (c.isAlpha()) charCount += 1;
  }

  return charCount >= 1 && numCount >= 1;
}

It is more “verbose” but you can actually understand what it’s doing and if you wanted to update the validation you can easily change it and reason about it. Meanwhile for the regex version it might take you a couple tries and you might even need to completely scrap your current implementation. Even if you were a regex wizard, other people aren’t. So your regex is just objectively harder to understand and maintain.

Regex can’t give good error messages

The only thing you get from using a regex is a match or not a match. You can’t really give good error messages with it. If you write the parser yourself and you know what is and isn’t expected, you can give more meaningful error messages than “password doesn’t match regex” or whatever.

Regex is good actually

Regex is not a good tool for validation and parsing. People use them as such but they’re not a good tool for that. It’s not a replacement for knowing how to parse. If your program requires user interactivity to do matches, then regex is a good tool. Things like search functionality in text editors, the find tool on browsers and so on are good use cases, for a regex engine in your program.

But if you already know the shape of the thing you want to match against and it’s not supplied by the user, then you’re probably better off writing your own validation/parser. You’ll get better performance, better errors and more understandable and maintainable code.

This is a compiled list of flags you might want to use. Heavily inspired by Compiler Options Hardening Guide for C and C++. I felt that this adaptation was needed because that post suffered from “too much yapping”.

The Essentials

No matter what you do, always enable -Wall -Wextra -pedantic, these flags are actually a group of other flags that enable other errors. If you want to see what they can do you can check the manpage for them:

-Wall
  This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with
  macros.  This also enables some language-specific warnings described in C++ Dialect Options and Objective-C and Objective-C++ Dialect Options.

  -Wall turns on the following warning flags:

  -Waddress -Waligned-new (C++ and Objective-C++ only) -Warray-bounds=1 (only with -O2) -Warray-compare -Warray-parameter=2 -Wbool-compare -Wbool-operation -Wc++11-compat
  -Wc++14-compat  -Wc++17compat  -Wc++20compat -Wcatch-value (C++ and Objective-C++ only) -Wchar-subscripts -Wclass-memaccess (C++ and Objective-C++ only) -Wcomment -Wdangling-else
  -Wdangling-pointer=2 -Wdelete-non-virtual-dtor (C++ and Objective-C++ only) -Wduplicate-decl-specifier (C and Objective-C only) -Wenum-compare (in C/ObjC; this is on by default in
  C++) -Wenum-int-mismatch (C and Objective-C only) -Wformat=1 -Wformat-contains-nul -Wformat-diag -Wformat-extra-args -Wformat-overflow=1 -Wformat-truncation=1 -Wformat-zero-length
  -Wframe-address -Wimplicit (C and Objective-C only) -Wimplicit-function-declaration (C and Objective-C only) -Wimplicit-int (C and Objective-C only) -Winfinite-recursion
  -Winit-self (C++ and Objective-C++ only) -Wint-in-bool-context -Wlogical-not-parentheses -Wmain (only for C/ObjC and unless -ffreestanding) -Wmaybe-uninitialized -Wmemset-elt-size
  -Wmemset-transposed-args -Wmisleading-indentation (only for C/C++) -Wmismatched-dealloc -Wmismatched-new-delete (C++ and Objective-C++ only) -Wmissing-attributes -Wmissing-braces
  (only for C/ObjC) -Wmultistatement-macros -Wnarrowing  (C++ and Objective-C++ only) -Wnonnull -Wnonnull-compare -Wopenmp-simd (C and C++ only) -Woverloaded-virtual=1 (C++ and
  Objective-C++ only) -Wpacked-not-aligned -Wparentheses -Wpessimizing-move (C++ and Objective-C++ only) -Wpointer-sign (only for C/ObjC) -Wrange-loop-construct (C++ and
  Objective-C++ only) -Wreorder (C++ and Objective-C++ only) -Wrestrict -Wreturn-type -Wself-move (C++ and Objective-C++ only) -Wsequence-point -Wsign-compare (C++ and Objective-C++
  only) -Wsizeof-array-div -Wsizeof-pointer-div -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-overflow=1 -Wswitch -Wtautological-compare -Wtrigraphs -Wuninitialized
  -Wunknown-pragmas -Wunused -Wunused-but-set-variable -Wunused-const-variable=1 (only for C/ObjC) -Wunused-function -Wunused-label -Wunused-local-typedefs -Wunused-value
  -Wunused-variable -Wuse-after-free=2 -Wvla-parameter -Wvolatile-register-var -Wzero-length-bounds

  Note that some warning flags are not implied by -Wall.  Some of them warn about constructions that users generally do not consider questionable, but which occasionally you might
  wish to check for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. Some of
  them are enabled by -Wextra but many of them must be enabled individually.

-Wextra
  This enables some extra warning flags that are not enabled by -Wall. (This option used to be called -W.  The older name is still supported, but the newer name is more descriptive.)

  -Wabsolute-value (only for C/ObjC) -Walloc-size -Wcalloc-transposed-args -Wcast-function-type -Wclobbered -Wdangling-reference (C++ only) -Wdeprecated-copy (C++ and Objective-C++
  only) -Wempty-body -Wenum-conversion (only for C/ObjC) -Wexpansion-to-defined -Wignored-qualifiers  (only for C/C++) -Wimplicit-fallthrough=3 -Wmaybe-uninitialized
  -Wmissing-field-initializers -Wmissing-parameter-name (C/ObjC only) -Wmissing-parameter-type (C/ObjC only) -Wold-style-declaration (C/ObjC only) -Woverride-init (C/ObjC only)
  -Wredundant-move (C++ and Objective-C++ only) -Wshift-negative-value (in C++11 to C++17 and in C99 and newer) -Wsign-compare (C++ and Objective-C++ only) -Wsized-deallocation (C++
  and Objective-C++ only) -Wstring-compare -Wtype-limits -Wuninitialized -Wunterminated-string-initialization -Wunused-parameter (only with -Wunused or -Wall)
  -Wunused-but-set-parameter (only with -Wunused or -Wall)

  The option -Wextra also prints warning messages for the following cases:

  *   A pointer is compared against integer zero with "<", "<=", ">", or ">=".

  *   (C++ only) An enumerator and a non-enumerator both appear in a conditional expression.

  *   (C++ only) Ambiguous virtual bases.

  *   (C++ only) Subscripting an array that has been declared "register".

  *   (C++ only) Taking the address of a variable that has been declared "register".

  *   (C++ only) A base class is not initialized in the copy constructor of a derived class.

-pedantic
  Issue all the warnings demanded by strict ISO C and ISO C++; diagnose all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++.
  This follows the version of the ISO C or C++ standard specified by any -std option used.
  
  Valid ISO C and ISO C++ programs should compile properly with or without this option (though a rare few require -ansi or a -std option specifying the version of the standard).
  However, without this option, certain GNU extensions and traditional C and C++ features are supported as well.  With this option, they are diagnosed (or rejected with
  -pedantic-errors).
  
  -Wpedantic does not cause warning messages for use of the alternate keywords whose names begin and end with __.  This alternate format can also be used to disable warnings for
  non-ISO __intN types, i.e. __intN__.  Pedantic warnings are also disabled in the expression that follows "__extension__".  However, only system header files should use these escape
  routes; application programs should avoid them.
  
  Some warnings about non-conforming programs are controlled by options other than -Wpedantic; in many cases they are implied by -Wpedantic but can be disabled separately by their
  specific option, e.g. -Wpedantic -Wno-pointer-sign.
  
  Where the standard specified with -std represents a GNU extended dialect of C, such as gnu90 or gnu99, there is a corresponding base standard, the version of ISO C on which the GNU
  extended dialect is based.  Warnings from -Wpedantic are given where they are required by the base standard.  (It does not make sense for such warnings to be given only for
  features not in the specified GNU C dialect, since by definition the GNU dialects of C include all features the compiler supports with the given option, and there would be nothing
  to warn about.)

Some people recommend adding -Werror which turns every warning into an error, but I don’t really think that’s reasonable. When you’re iterating on a project, being forced to fix any minutia slows you down. If you’re going to enable it at all, I suggest you enable it for release builds.

Sanitizers

Sanitizers are your friend. They’ll help you with detecting memory leaks, undefined behavior and other common bugs. They can be enabled with the -fsanitize flag. Also don’t forget to add -g when compiling to add debug symbols, otherwise the sanitization errors might not be as useful. (You can also use valgrind but I won’t get into it in this post).

There’s many sanitizers you can use. I recommend looking at the manpage and seeing what sanitizers are available. Bear in mind that not all sanitizers can be used together. So you might have to compile your code and test it with each sanitizer individually. As far as I know, you can use -fsanitize=leak,undefined,address and these 3 can work together just fine. So I recommend using this at least on your debug builds. (do not that if you use a library that has many leaks and was never used with sanitizers, you might have to add an ignore list so that you can sanitize your own code, it’s just the state of things sadly)

C Standard

A lot of people swear by C89 but personally I’m not a fan. I recommend C99+. C99 is a nice standard if you want to support as many compilers as possible and/or you don’t need atomics. If you do need atomics, C11 is fine, Linux for example defaults to it (technically gnu11, but still).

I recommend you always set your standard with -std=c99 or whatever version you’re using. GCC defaults to their own dialect which has a bunch of extensions. I’d rather use the standard and not a dialect, only use it if you know you need the extensions (for some reason).

Compiler Flags

The following are flags that you might benefit from, they either add compile-time or runtime checks to make the compiler/program even stricter.

Flags that enable compile-time checks:

Flags that enable runtime checks:

I suggest you read the manpages and search online for the flags you’re interested in using.

• Using function-like macros

#define vector_push(vector, item) vector.buf[vector.idx++] = item;

Con: This will cause everything to be inlined and loosely typed.

• Using void pointers

void vector_push(Vector vec, void *item);

Con: You rely on type erasure to achieve generics, so you’ll have to recast everything back to access them. You might also run into UB.

• Dispatch specializations through a function-like macro

#define DECLARE_VECTOR(type) \
  void vector_push(Vector##_##type, type item) {\
    // do stuff here \
    }

DECLARE_VECTOR(int)

Con: Everything is wrapped in a macro and might break autocomplete

The approach I recommend is not really novel, but it’s the one I’ve found to be the nicest to use and to work better with existing tooling. Since it doesn’t rely on type erasure and everything isn’t wrapped in macros.

Pros:

• Type safe
• Doesn’t have to use pointers
• Minimal use of Macros
• Can be deduplicated by linkers
• Can be entirely put in a single file to reduce changes triggering compilation for multiple files

Cons:

• Relies on a macro trick
• Can be a bit verbose

Achieving generics through header instantiation

The way this works is, you instantiate a specialization for a type by defining your type and possibly a suffix if that type is not a valid identifier name. To do this, we’ll have to rely on a small macro trick, but other than that, everything is quite straight forward. The header instantiation should look like this:

#define VEC_ITEM_TYPE long long
#define VEC_SUFFIX num
#include "vector.h"

With the VEC_SUFFIX being optional.

Once instantiated this would give you a vector_push_num function you could use. To do this we need to be able to append _num to our symbol names. So we create a G function-like macro.

#define G(name) name##_##VEC_ITEM_TYPE

Except, this doesn’t work. You can’t just expand and append them like that. We need to expand the definitions first and then append them, so we’ll rely on the following trick:

#define __G(name, type) name##_##type
#define _G(name, type) __G(name, type)
#define G(name) _G(name, VEC_ITEM_TYPE)

It works now! Now we can wrap our identifier names in a G macro so that they’re name mangled for the types they’re for.
We can use it to define our functions and structs like this: struct G(something), void G(do_something)().

Enforcing type definition and allowing custom suffixes

#ifndef VEC_ITEM_TYPE
  #error VEC_ITEM_TYPE was not defined
#endif

#ifndef VEC_SUFFIX
  #define VEC_SUFFIX VEC_ITEM_TYPE
#endif

Now we can emit an error if VEC_ITEM_TYPE is not defined.

This fixes wrong uses of the header but what if we want to use something like long long or atomic int? It won’t work. So we have to introduce a way of programmatically overriding the suffix that’s added to functions. So we’ll introduce a VEC_SUFFIX:

#ifndef VEC_ITEM_TYPE
  #error VEC_ITEM_TYPE was not defined
#endif

#ifndef VEC_SUFFIX
  #define VEC_SUFFIX VEC_ITEM_TYPE
#endif

#define __G(name, type) name##_##type
#define _G(name, type) __G(name, type)
#define G(name) _G(name, VEC_SUFFIX)

Now we’re free to implement our library. For example, here’s a generic vec_pop implementation:

bool G(vec_pop)(G(Vector) *vec, VEC_ITEM_TYPE *dest) {
   if (!vec->vec || vec->len <= 0 || vec->capacity <= 0) {
      return false;
   }

   vec->len--;
   if (dest) {
      *dest = vec->vec[vec->len];
   }
   G(vec_fit)(vec);
   return true;
}

As you can see, every time we call anything generic we need to wrap it in G so that it can properly call the generic function.

The elephants in the room

Redeclaration error

You can try and use this implementation but unless you only have one C file and nothing else, you’re likely to eventually run into a redeclaration error especially if you’re using this generic library on .c and .h files.

A potential fix is to make everything static but then you would end up duplicating everything throughout many translation units in your program.

The actual fix is to be able to choose when to forward declare and when to use the implementation:

#ifndef VEC_IMPLEMENTATION
  bool G(vec_pop)(G(Vector) *vec, VEC_ITEM_TYPE *dest);
#else
  bool G(vec_pop)(G(Vector) *vec, VEC_ITEM_TYPE *dest) {
     if (!vec->vec || vec->len <= 0 || vec->capacity <= 0) {
        return false;
     }

     vec->len--;
     if (dest) {
        *dest = vec->vec[vec->len];
     }
     G(vec_fit)(vec);
     return true;
  }
#endif

You can then just include the header in header files

// included like any other header
#define VEC_ITEM_TYPE int
#include "vector.h"
#include <stdio.h>
#include <stdlib.h>

And then on your C files you can tell it that you need the implementations, not the declarations.

#define VEC_IMPLEMENTATION
#define VEC_ITEM_TYPE int
#include "vector.h"

Side Note: if you include the header in another header, you can still just call #define VEC_IMPLEMENTATION without reincluding the generic header library to get the implementation. Which is a nice side effect of this approach to generics, but it can end up looking a bit implicit because the include is hidden in another include.

Example:

#define VEC_IMPLEMENTATION
#include "flag.h"

Multiple includes inheriting types

Since we’re relying on preprocessor definitions to define our types. If we do:

#define VEC_ITEM_TYPE int
#include "vector.h"
#include "vector.h"

We’ll have a redeclaration error, because both includes see VEC_ITEM_TYPE as int. We can fix it by undefining it at the end of our generic vector header:

#undef VEC_ITEM_TYPE
#undef VEC_SUFFIX

This way we still get a “VEC_ITEM_TYPE is not defined” error if we include the vector again and forget to tell it what type we want instantiated.

NOTE: We don’t undefine VEC_IMPLEMENTATION so that we can just declare it once in our .c files for convenience’s sake.

Include guards

You might be asking about the missing include guard, but you don’t need it! The reason is that we actually want to be able to include the same header multiple times. Each time with a different type.

You might still want to have an include guard for a section of the header if you want to declare some types or code that is not generic in the header. A good example of this would be if your allocator would receive an allocator context which does not care about types. For example, you might want to have something like this:

#ifndef VECTOR_H
#define VECTOR_H

typedef struct vec_allocator {
   void *(*malloc)(size_t);
   void (*free)(void *);
} VecAllocator;

#endif

That way, every single vector could still share the same allocator type.

Putting everything together

The final header should look something like this:

#ifndef VEC_ITEM_TYPE
   #error VEC_ITEM_TYPE was not defined
#endif

#ifndef VEC_SUFFIX
   #define VEC_SUFFIX VEC_ITEM_TYPE
#endif

#define __G(name, type) name##_##type
#define _G(name, type) __G(name, type)
#define G(name) _G(name, VEC_SUFFIX)

#include <math.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#ifndef VEC_IMPLEMENTATION

typedef struct G(vec_vector) {
   size_t capacity;
   size_t len;
   VEC_ITEM_TYPE *vec;
} G(Vector);

G(Vector) * G(vec_new)(void);
bool G(vec_push)(G(Vector) *vec, VEC_ITEM_TYPE item);

#else

// Initializes a new vector with items of sizeof(T)
G(Vector) * G(vec_new)(void) {
   G(Vector) *vector = malloc(sizeof(*vector));
   if (!vector) {
      return NULL;
   }

   *vector = (G(Vector)) {
      .capacity = 0,
      .len = 0,
      .vec = NULL,
   };

   return vector;
}

// Resizes vector to fit length
bool G(vec_fit)(G(Vector) *vec) {
   const size_t power = ceilf(log2f(vec->len + 1));
   const size_t new_capacity = sizeof(vec->vec[0]) * powf(2, power);

   if (new_capacity < vec->capacity || new_capacity > vec->capacity) {
      void *tmp = realloc(vec->vec, new_capacity);
      if (!tmp) {
         return false;
      }
      vec->vec = tmp;
      vec->capacity = new_capacity;
   }
   return true;
}

// Pushes a value to vector
bool G(vec_push)(G(Vector) *vec, VEC_ITEM_TYPE item) {
   if (vec->len == 0 && vec->capacity == 0) {
      vec->vec = malloc(sizeof(vec->vec[0]));
      if (!vec->vec) {
         return false;
      }

      vec->vec[0] = item;
      vec->len = 1;
      vec->capacity = sizeof(vec->vec[0]);
      return true;
   }

   G(vec_fit)(vec);
   vec->vec[vec->len] = item;
   vec->len++;
   return true;
}

#endif

#undef VEC_ITEM_TYPE
#undef VEC_SUFFIX

The low-hanging fruits

Basic Motions

The main difference between Helix and Vim is that Helix is selection based and reverses the motions. A lot of the actions are actually the same. So for example de in Vim is ed in Helix, ce is ec and so on. The reason for this is that Helix selects text before doing anything with it.

You can think of the Helix binding as just Vim but entering visual mode before doing anything. So de would be ved and ce would be vec, the end result on Vim would be the exact same as what would happen on Helix.

Doing selections

A cursor in Helix is essentially a one character selection, so if you attempt to use dd or cc or yy or any other double verb to apply it to the entire line, it just won’t work. You have to do a selection before. Here’s the most common selections:

• x: select the current line (if you keep pressing it it’ll keep adding more lines to the selection)
• %: select the entire file
• e, E, b, B, w, W: essentially the same as in vim, select from the current cursor position until where they stop

Helix modes and macros

Macros

Macros can be recorded by pressing Q, then after you’ve done whatever you wanted to record, you can press Q again to stop. By default macros are recorded into the @ register, you can change where your macros are recorded if you want to store and use multiple macros. For example you could do "mQ to record a macro in a custom register m. "<register> is the syntax for changing registers.

You can also delete all macros by doing :clear-register. Registers can also be used to save your selection (text) so if you use d, y and so on, they’re also saved in registers. This also allows you to have multiple things saved at once by just changing the register before doing something.
Helix also has a few special registers. If you want to know more about registers you can check the documentation.

Space mode

Helix heavily relies on pickers to provide a lot of interactive features all of these can be accessed by pressing space:

• <space>b: Buffer picker
• <space>e: File explorer
• <space>s: Symbol search
• <space>/: Global search
• <space>d: LSP diagnostics
• <space>a: Code actions

Space mode has a few other features as well. You can check what else it can do here.

Goto mode

Moving around the file is very common. Vim users are used to using g to move around. Helix also has this keybinding.

Besides these, there’s other ways to move around, for example jumping around references, definitions, or between buffers, they all happen through the goto mode. One of the most useful ones for moving around is gw, this creates labels in your text that once you type them, your cursor jumps straight to where the label was.

If you want to learn more about gotos you can check the docs here

Window mode

Window mode allows you to manage splits in Helix, you can enter window mode with <space>w. Once in window mode, to create the splits you can use s for vertical splits and v for vertical splits. Then you can use window mode to manage your splits. Such as moving between them (using hjkl in window mode), swapping them (using HJKL),
You can change windows between vertical and horizontal using t (t stands for transpose), and you can quit the window with q.

Match mode

Match mode allows you to select text, in Vim you would usually use gi and ga for this, match mode is the Helix equivalent. To enter the window mode you can press m while in normal mode.

For example giw would be miw in helix (though for this case going back and forth or the other way around with the w, b and e keys is one less keystroke). If you’re inside of a () or a {} or some other pair and you have an LSP configured you can do mim to select everything inside of a pair or mam to select everything including the pair. If you don’t have an LSP or you want to match something else you can just type one of the pairs for example you could do mi( to match everything inside of a parenthesis.
You can also swap a (), {} or any pair with the syntax mr<original_pair><new_pair> so for () to {} you can do mr({. Or you could delete the pairs md(.

Command mode

Basic commands are mostly the same as in Vim. You can enter the command mode with :.

Common commands shared by Helix and Vim:

• :q: quit
• :q!: force quit
• :w: save
• :w!: force save
• :x: save and quit
• :|: pipe selection to command and substitute with command output
• :o/:open: open file

Common commands that are different:

• :!: required a space in helix as it’s an alias to :sh
• :lsp-restart: (re)start LSP
• :lsp-stop: stop LSP
• :log-open: read logs
• set-language: equivalent to :lang in Vim
• :format: format text with language formatter

Multicursors

Helix supports multiple cursors. These can be created by using <shift>C the cursors can be disabled with ,.

But the most powerful thing about it is being to spawn multiple cursors on certain locations based on their content. To do this you can do a selection of the region where you want the cursors to spawn then you press s and type what you’re looking for, after you’ve matched the content you can press enter and continue editing.

To disable a selection you can use ;.

If you want to learn more give the official docs a try. You might also want to try the helix tutor by running helix --tutor.

Handling errors

If you only care about one case in an error, instead of being forced to match against all errors, do this:

if let Some(val) = returns_option() {
    // do something
}

If the value that is returns doesn’t matter, then you can do this:

if returns_option().is_some() {
    // do something
}

There’s corresponding versions for the other values as well: Result::{is_err, is_ok}, Option::{is_some, is_none}

If you expect the error to never happen, or if it happens you can’t handle it, you can just unwrap or expect it.

• unwrap just panics over an error. So if you do this:

let x = returns_option().unwrap();

that would be equivalent to this:

let x = match returns_option() {
    Some(x) => x,
    None => panic!("some reason why it errored here"),
};

• expect allows you to change the panic message, you should write there what your expectation was for that error

let retcode = execute_file("path/to/file").expect("file should be executable");

Propagating errors

fn func(x: &str) -> Result<&str, Error> {
    // instead of:
    let x = match returns_result(x) {
        Ok(other) => other,
        Err(err) => return err,
    };

    // do:
    let x = returns_result(x)?;
}

Sometimes though, the Result or Option returns by the function might not be 1-to-1 with the functions you’re propagating the error from, in those cases you can either use let else idiom:

let Ok(other) = returns_result(x) else {
    return None;
}

Or you can also convert from a Result to an Option or vice versa with these methods: Result::{ok, err} and Option::ok_or to convert to the appropriate type

fn func(x: &str) -> Option<&str> {
    let other = returns_result().ok()?;
}

If these are not sufficient, you might want to change the Error or Ok values so you can “massage” it into working, these functions are Result::{map_err, map_ok} and Option::map_or. You can use them like this:

let other = returns_result().map_err(|e| /* massage the value here */)?;