sglavoie.com – Tag: Software

Reading notes: A Philosophy of Software Design, 2nd Edition

Sébastien Lavoie — Sun, 30 Mar 2025 11:18:00 -0600

Nature of complexity

“Change amplification: The first symptom of complexity is that a seemingly simple change requires code modifications in many different places.” (e.g., refactoring a project to inject dependencies in tests, because the system was hard to test in the first place)
“Cognitive load: The second symptom of complexity is cognitive load, which refers to how much a developer needs to know in order to complete a task.” (e.g., close a file where it is opened whenever possible, instead of leaking context and pushing the responsibility onto the caller)
“Unknown unknowns: The third symptom of complexity is that it is not obvious which pieces of code must be modified to complete a task, or what information a developer must have to carry out the task successfully.”
“One of the most important goals of good design is for a system to be obvious.”

Strategic vs. tactical programming

“it’s worth taking a little extra time to find a simple design for each new class; rather than implementing the first idea that comes to mind, try a couple of alternative designs and pick the cleanest one. Try to imagine a few ways in which the system might need to be changed in the future and make sure that will be easy with your design”

Modules should be deep

Modular design
- “In general, if a developer needs to know a particular piece of information in order to use a module, then that information is part of the module’s interface.”
Abstractions
- “The key to designing abstractions is to understand what is important, and to look for designs that minimize the amount of information that is important”
A deep module is one in which the interface is small and the implementation is large.
- “Deep modules such as Unix I/O and garbage collectors provide powerful abstractions because they are easy to use, yet they hide significant implementation complexity.”
Shallow modules
- “A shallow module is one whose interface is complicated relative to the functionality it provides.”

Information hiding

“If a piece of information is hidden, there are no dependencies on that information outside the module containing the information, so a design change related to that information will affect only the one module”
Information leakage
- “If the affected classes are relatively small and closely tied to the leaked information, it may make sense to merge them into a single class.”
- “When designing modules, focus on the knowledge that’s needed to perform each task, not the order in which tasks occur.”
- “it’s important to avoid exposing internal data structures as much as possible”
“The best features are the ones you get without even knowing they exist.”
“As a software designer, your goal should be to minimize the amount of information needed outside a module; for example, if a module can automatically adjust its configuration, that is better than exposing configuration parameters”
“think about the different pieces of knowledge that are needed to carry out the tasks of your application, and design each module to encapsulate one or a few of those pieces of knowledge. This will produce a clean and simple design with deep modules.”

General-Purpose Modules are Deeper

“specialization leads to complexity”
Generality leads to better information hiding
“Eliminate special cases in code”

Different Layer, Different Abstraction

“A pass-through method is one that does nothing except pass its arguments to another method, usually with the same API as the pass-through method. This typically indicates that there is not a clean division of responsibility between the classes.”

Pull Complexity Downwards

Figure out complexity in the library instead of pushing it up to the user.
"[…] you should avoid configuration parameters as much as possible. Before exporting a configuration parameter, ask yourself: will users (or higher-level modules) be able to determine a better value than we can determine here?"

Better Together Or Better Apart?

“Bring together if information is shared”
“Bring together if it will simplify the interface”
“Bring together to eliminate duplication”
- Use goto to exit nested code blocks early as long as it’s not too complex.
On Splitting long methods: “If you make a split of this form and then find yourself flipping back and forth between the parent and child to understand how they work together, that is a red flag (“Conjoined Methods”) indicating that the split was probably a bad idea.”
“If the caller has to invoke each of the separate methods, passing state back and forth between them, then splitting is not a good idea.”

Define Errors Out Of Existence

“The key overall lesson from this chapter is to reduce the number of places where exceptions must be handled; in some cases the semantics of operations can be modified so that the normal behavior handles all situations and there is no exceptional condition to report […].”
“The best way to eliminate exception handling complexity is to define your APIs so that there are no exceptions to handle: define errors out of existence”
E.g., the Java substring method could remove its IndexOutOfBoundsException by automatically rounding the index to the nearest valid value.
"Exception masking doesn’t work in all situations, but it is a powerful tool in the situations where it works. It results in deeper classes, since it reduces the class’s interface (fewer exceptions for users to be aware of) and adds functionality in the form of the code that masks the exception. Exception masking is an example of pulling complexity downward."
“The idea behind exception aggregation is to handle many exceptions with a single piece of code; rather than writing distinct handlers for many individual exceptions, handle them all in one place with a single handler.” (e.g., a web server dispatching different types of requests and catching all sorts of errors).
“In most applications there will be certain errors that are not worth trying to handle. Typically, these errors are difficult or impossible to handle and don’t occur very often. The simplest thing to do in response to these errors is to print diagnostic information and then abort the application.” (e.g., out-of-memory errors).

Design it Twice

“The initial design experiments will probably result in a significantly better design, which will more than pay for the time spent designing it twice”
“The process of devising and comparing multiple approaches will teach you about the factors that make designs better or worse. Over time, this will make it easier for you to rule out bad designs and hone in on really great ones.”

Why Write Comments? The Four Excuses

Good code is self-documenting. Comments serve as precisions on abstractions.
I don’t have time to write comments. The benefits of having documentation quickly offset the cost of writing it.
Comments get out of date and become misleading. Keep the documentation close to where it needs to be, so you update it.
All the comments I have seen are worthless. Be the change you want to see.
Benefits of well-written comments
- “The overall idea behind comments is to capture information that was in the mind of the designer but couldn’t be represented in the code.”
- “One of the purposes of comments is to make it it unnecessary to read the code.”

Comments Should Describe Things that Aren’t Obvious from the Code

Don’t repeat the code
“Lower-level comments add precision”
- Focus on what the variable represents, not how it is modified (the latter is explained by the code).
“Higher-level comments enhance intuition”
- “What is the simplest thing you can say that explains everything in the code? What is the most important thing about this code?”
Interface documentation
“Implementation comments: what and why, not how”
- Describe at a more abstract level to help understand what is happening and why. The code tells the how.
Cross-module design decisions
- One possible solution is to use a designNotes.md file or similar to jot down all major decisions, and point to it from the code (e.g., See topic in designNotes).

Choosing names

Great names are “precise, unambiguous, and intuitive.”
Use names consistently: make it so that a concept is expressed in the same words regardless of the context in which it is found if it makes sense to do so.
Avoid extra words: no more Hungarian Notation with modern IDEs.

Use comments as part of the design process

Delayed comments are bad comments
- You won’t remember exactly what you had in mind and why you did things if you delay writing documentation: design decisions will get lost.
Write the comments first
- No backlog of unwritten comments.
- “it produces better comments.”
Comments are a design tool
- Writing them at the beginning “improves the system design.”
- “If a method or variable requires a long comment, it is a red flag that you don’t have a good abstraction.”
Early comments are fun comments
- “If you are programming strategically, where your main goal is a great design rather than just writing code that works, then writing comments should be fun, since that’s how you identify the best designs.”
- “I’m looking for the design that can be expressed completely and clearly in the fewest words. The simpler the comments, the better I feel about my design.”
Are early comments expensive?
- “Writing the comments first will mean that the abstractions will be more stable before you start writing code.”
- “In contrast, if you write the code first, the abstractions will probably evolve as you code, which will require more code revisions than the comments-first approach.”

Modifying existing code

“Whenever you modify any code, try to find a way to improve the system design at least a little bit in the process. If you’re not making the design better, you are probably making it worse.”
Maintaining comments: keep the comments near the code
- “The farther a comment is from its associated code, the less likely it is that it will be updated properly.”
- “In general, the farther a comment is from the code it describes, the more abstract it should be (this reduces the likelihood that the comment will be invalidated by code changes).”
Comments belong in the code, not the commit log
- “An example is a commit message describing a subtle problem that motivated a code change. If this isn’t documented in the code, then a developer might come along later and undo the change without realizing that they have re-created a bug.”
Maintaining comments: avoid duplication
Maintaining comments: check the diffs
- Review changes during the pre-commit phase to make sure documentation stays up-to-date with the code changes.
Higher-level comments are easier to maintain
- Most helpful comments do not repeat the code, they provide an abstraction that can’t be expressed easily by the code alone.

Consistency

Similar things are done in a similar way.
“Consistency creates cognitive leverage: once you have learned how something is done in one place, you can use that knowledge to immediately understand other places that use the same approach.”
Ensuring consistency
- Document most important conventions.
- “the value of consistency over inconsistency is almost always greater than the value of one approach over another.”

Code should be obvious

“the best way to determine the obviousness of code is through code reviews”
“If someone reading your code says it’s not obvious, then it’s not obvious, no matter how clear it may seem to you”
Things that make code more obvious
- Good names
- Consistency
- Judicious use of white space
- Blank lines
- Comments
Things that make code less obvious
- Event-driven programming
- Generic containers
- Different types for declaration and allocation

Software trends

Object-oriented programming and inheritance
- “In order for an interface to have many implementations, it must capture the essential features of all the underlying implementations while steering clear of the details that differ between the implementations; this notion is at the heart of abstraction.”
- “Class hierarchies that use implementation inheritance extensively tend to have high complexity.”
- “Before using implementation inheritance, consider whether an approach based on composition can provide the same benefits.”
Agile development
- May encourage a more tactical approach to programming. Balance is required.
Test-driven development
- “it focuses attention on getting specific features working, rather than finding the best design”
- “One place where it makes sense to write the tests first is when fixing bugs. Before fixing a bug, write a unit test that fails because of the bug.”
Design patterns
- “As with many ideas in software design, the notion that design patterns are good doesn’t necessarily mean that more design patterns are better.”
Getters and setters
- “It’s better to avoid getters and setters (or any exposure of implementation data) as much as possible.”

Designing for performance

How to think about performance
- “The key is to develop an awareness of which operations are fundamentally expensive.”
Measure before (and after) modifying
- “the goal is to identify a small number of very specific places where the system is currently spending a lot of time, and where you have ideas for improvement.”
- “If the changes didn’t make a measurable difference in performance, then back them out (unless they made the system simpler).”
Design around the critical path
- “When redesigning for performance, try to minimize the number of special cases you must check.”
“Complicated code tends to be slow because it does extraneous or redundant work.”

Decide what matters

Minimize what matters
How to emphasize things that matter
- “important things should appear in places where they are more likely to be seen, such as interface documentation, names, or parameters to heavily used methods.”
- “repetition: key ideas appear over and over again.”
- “The things that matter the most should be at the heart of the system, where they determine the structure of things around them.”
Mistakes
- “treat too many things as important. When this happens, unimportant things clutter up the design, adding complexity and increasing cognitive load.”
- “fail to recognize that something is important. This mistake leads to situations where important information is hidden, or important functionality is not available so developers must continually recreate it.”
Thinking more broadly
- “the best way to make a document easy to read is to identify a few key concepts at the beginning and structure the remainder of the document around them. When discussing the details of a system, it helps to tie them back to the overall concepts.”
- “Focusing on what is important is also a great life philosophy: identify a few things that matter most to you, and try to spend as much of your energy as possible on those things.”

Conclusion

“The reward for being a good designer is that you get to spend a larger fraction of your time in the design phase, which is fun. Poor designers spend most of their time chasing bugs in complicated and brittle code.”

Systematic reviews

Sébastien Lavoie — Sun, 14 May 2023 15:58:00 -0600

Introduction

I used to think that merely using better or more sophisticated tools would magically make me more productive, blaming external factors and technology on my own lack of ability to achieve my dreams. But I’ve come to realize that it was only an escape into the procrastination playground to avoid facing hard work. Working on a system is not the same as working in a system. The former is a form of procrastination, while the latter is the actual work that needs to be done.

While there are great approaches including Zettelkasten and the Getting Things Done methodology, I have found that I work optimally with simpler systems that are easier to maintain, which reduce cognitive load and friction (less to think about and no complicated setup when inputting information either). I used to be an avid user of Todoist where I would implement GTD almost as a pure devotee, making the most of all its (relatively) advanced features, but that was a double-edged sword as dealing with timezone and synchronization issues was more than enough to derail me from the path, sometimes with dire repercussions when tasks would suddenly disappear or be scheduled at the wrong time.

Needless to say, I have since moved on to a simpler system that is more robust and that I can trust. I am not technologically turning back, but I have found Todoist’s weekly review process to be quite effective and easy to follow, so I have decided to adopt it as a basis for my own system, which I will be describing briefly in this post.

A whirlwind tour of the system

What follows is nothing revolutionary, but the simplicity of it just stuck with me. From prior research on the topic as I was building a todo application, it really stood out to me that the most effective systems were the simplest ones, especially when the different components can be neatly decoupled from each other while working well together as a whole. Arguably, the Apple ecosystem has done a great job at this – although I’m still enthusiastic about creating a single software destination to manage one’s life even more efficiently ;).

In reality, I just stuck with the default offerings for maximum compatibility and ease of use, but the truth is that the existing applications I have been in touch with do not fully address all my needs. As I’m not willing to try to bend reality to my will, I have decided to bend my will to reality for the time being and work with what I have. But I digress.

PlantUML source of this diagram

So the main idea here is very simple: twice a day, a daily review occurs and once a week, a more thorough weekly review is performed. Then, at the end of every month and every year, an even more thorough exploration happens both to reflect on the past and plan for the future.

Daily review

PlantUML source of this diagram

The purpose behind the daily review is twofold:

To make sure that the day is planned out and that the most important tasks are completed.
To do a mindful check on one’s wellbeing and re-adjust as needed.

Point 1. is self-explanatory. It serves as a good reminder that task estimation skills are not perfect and that one should not be too hard on oneself if things do not go as planned. Point 2. is a bit more subtle, but it is important to frequently take a step back and reflect on one’s current state of mind and body. That may include taking a break, going for a walk, or even taking a nap. The point is to be mindful of one’s current state and to take action to improve it if needed. In that department, I like to exercise early in the morning, both to expose my eyes to sunlight and to get my blood flowing (more on this in the excellent Huberman Lab podcast!). Besides sleeping well and eating healthy, I have found that this is the best way to ensure that I am in a good state of mind to tackle the day’s challenges.

Make relevant context accessible

One thing I like to do to stay on top of priorities is to “pin” a couple of active notes I’m using from Apple Notes directly inside the list of widgets shown when swiping left with two fingers on the touch pad (or clicking on the clock in the top-right corner). There, I quickly see notes like Working notes (to accompany the projects I’m currently working on), Standup so I can share updates with my team, @next_action which contains a list of stuff I plan to work on next without having to clutter my todo app and another one such as Ideas which I use as a scratchpad to empty my mind of any thoughts that might be distracting me from the task at hand or that might be useful later on.

Another major component of the way I organize tasks (currently with Apple Reminders) is to rely on smart lists and split them by areas of responsibilities. So while I may create tasks under specific lists, I tend to simply schedule everything that’s either recurring or that will need attention in the near future, storing the remaining ideas and potential tasks in Apple Notes.

So in this case, everything being scheduled for today or that has been flagged manually will appear in the Today list. Anything else that has a deadline in the near future will appear in the Scheduled list. Then, I simply divide my set of work in progress (WIP) tasks into work and personal and will drag and drop tasks from other lists/projects as needed to re-prioritize them. To avoid having a large list of items in the WIP lists, I use two separate lists to keep track of the Next actions: these are tasks that do not require immediate attention but used to be scheduled as being more urgent, since priorities will often need to shift under a set of constantly new circumstances.

These tasks will be dragged out of other lists as needed – either from the backlog of tasks or from the WIP tasks to declutter other lists. They will be prioritized as the Next actions to ensure that once the WIP is done, there is a continuity to the system. Just as with other lists, order matters, so that the most important tasks are at the top and the least important ones are at the bottom. This is a simple way to ensure that the most important tasks are always visible and that the least important ones are not forgotten.

Weekly review

The weekly review is a bit more involved, but it is still quite simple. The main idea is to take a step back and reflect on the past week, while planning for the next one. This is where I like to take a look at my calendar and make sure that I have not forgotten anything important. Given the current set of tools I use, I don’t really implement timeboxing as I find that I just tend to miss stuff I put into the calendar if it’s not an “all-day” event. Brace yourself, here it goes.

PlantUML source of this diagram

This probably looks more intimidating than it really is. I usually go through the whole process in under an hour. That may sound like a lot, but it really helps to declutter my mind while giving me the assurance I did my best to plan for the upcoming week. I also like to do this on Sunday mornings, so that I can start the week with clear focus. All in all, I find that this is a great investment and it becomes especially true if I adhere to doing it in the mornings right after I have a delicious cup of freshly ground coffee (but at least 90 to 120 minutes after waking up: again, see Huberman to get fantastic explanations on why this is ideal).

Automatic reviews

Once more, nothing too fancy is happening here, but having smart lists makes it very easy to review what is coming up. In this case, it’s mostly empty as it excludes all the work in progress, which makes it more useful as well since these are already accessible from their own lists, so the review section really highlights anything that is salient and non-recurring.

Monthly and yearly reviews

I can see the benefit in asking more questions and taking more time to plan ahead up to a point, but life is totally unpredictable and I find that it is not worth spending too much time planning for the future. Ultimately, everything is ephemeral: interests, hobbies or even relationships come and go. So my current approach is simply to repeat the weekly process with an emphasis on the things I might have neglected a bit more, such as planning new projects, dissolving old ones that no longer require attention and making sure that I am still on track with my goals at a higher level.

These moments also form a great opportunity to look at finances and make sure that I am not spending too much money on things that do not bring me joy or that I do not need. They also serve as a reminder to take a step back and reflect on the bigger picture, taking a break to look at all the progress that has been made so far. This becomes easier when things are tracked down by writing, and so I maintain a private GitHub repository called life-trail in which I write down a summary of my weekly reviews, keep track of the most important lessons I have learned and main events that happened in my life. This is heavily inspired from having gone through the Self Authoring Program, which I highly recommend to anyone interested in bringing more meaning into their life.

While (I think) I’d love to know for sure where I spend every minute of the day, I tend to track my time with Toggl only when I’m at the computer or reading books on my pretty old Nook e-ink reader. It doesn’t paint the full picture, yet it is not cumbersome to use and provides the kinds of insights I am looking for while forcing me to be more mindful about the actions I take moment to moment.

Conclusion

I have tried many different methodologies to get more organized and, after getting no further than where I used to be, I have reached the following conclusion, which can be elegantly summed up with Nike’s tagline: Just Do It. While one might have lofty goals, it all means nothing if one does not take action towards attaining them. This is why I have decided to adopt a more systematic approach in all aspects of life. This is not to say that I will not be using any tools, but rather that I will be using them with a focus on pragmatism and manifesting actual results.

More resources and references

Huberman Lab podcast - Andrew Huberman.
ProductiviDo - GitHub.
Self Authoring Program - Jordan Peterson.
Solving the Procrastination Puzzle: A Concise Guide to Strategies for Change - Timothy A. Pychyl.
The Weekly Review - Todoist.
Timeboxing - MindTools.
Toggl - Toggl Time tracking.
Work Notes by Sam Matla - Sam Matla.

My Current Set of Tools and Customizations

Sébastien Lavoie — Sat, 06 Jun 2020 10:41:00 -0500

Category	#1 tool	Alternatives
3d animation	blender
audio editing	audacity
backup (script)	rsync
clipboard manager	copyq	clipman
cloud	dropbox-cli	google drive
code completion	coc.nvim	ale
code snippets	github gists	gitlab snippets
cursor hider	unclutter
desktop environment	xfce	gnome
diagram generation	plantuml	mermaid-js
dotfiles management	git bare repo
dynamic menu	dmenu	rofi
ebook manager	calibre
encrypted paste bin	paste.sh
file manager	thunar	pcmanfm, nautilus
file renamer	pyrenamer	thunar bulk rename
flowchart design	draw.io
fonts monospace	jetbrains mono	iosevka
fonts monospace	source code pro	inconsolata
fonts sansserif	lato	dejavu
gif screen recorder	peek
image editing (raster)	gimp
image editing (vector)	inkscape
interface design	figma
irc chat	hexchat	pidgin
latex typesetting	latex workshop	vimtex
linux distribution	xubuntu	debian, manjaro
memorizing	anki
mind mapping	freeplane	draw.io
music player	audacious	clementine
note-taking	vimwiki
notifications	xfce	dunst
office suite	libreoffice
operating system	gnu/linux	macOS
paragraph formatter	par
partition manager	gparted
password manager	keepassxc
pdf editing (minimal)	pdfarranger
pdf viewer	atril	evince, zathura
publishing	scribus
python documentation	sphinx
python formatter	black
python ide	pycharm
python linter	pylint
python refactoring	rope
python test suite	pytest
python virtualenv manager	venv module	virtualenvwrapper.sh
screen locker	slock	xflock4
screen recorder	obs studio	simplescreenrecorder
screenshot software	flameshot	xfce4-screenshooter
security	gnupg2
sound system	pulseaudio
source code explorer	sourcetrail
sql client	dbeaver
sql database	postgres	mysql, sqlite
sql viewer	sqlitebrowser
static website generator	pelican
task management	todoist	google keep
terminal calculator	ipython	bc
terminal clipboard	xclip
terminal coursera downloader	coursera-dl
terminal disk usage	ncdu
terminal emulator	kitty	st, xfce4-terminal
terminal file archiver	p7zip
terminal file lister	exa
terminal file lister tree-style	tree
terminal file manager	vifm	nnn
terminal file manager (minimal)	lf
terminal file viewer	bat	cat
terminal fuzzy finder	fzf
terminal markup converter	pandoc
terminal network downloader	wget
terminal network tool	curl
terminal partition manager	parted
terminal search tool	the silver searcher	locate
terminal session recorder	asciinema
terminal shell	zsh	bash
terminal system monitor	bashtop	glances, htop
terminal youtube downloader	youtube-dl
text editor	neovim	vim, vs code
torrent	transmission	deluge
version control stats	gitstats
version control system	git
video player	smplayer	vlc
visual plotting	geogebra
wallpaper browser/setter	nitrogen	feh
web browser	google-chrome	firefox, brave
window manager	i3	dwm
window manager status bar	i3blocks	i3status

For a more granular selection of open source projects I’ve used and like (Vim plugins, color schemes, command-line tools, etc.), you can also have a look at the GitHub repositories I’ve starred over time.

Suckless: Minimalist Tools That Work Great

Sébastien Lavoie — Sun, 12 May 2019 22:50:00 -0500

What are Suckless tools?

From the official website:

Home of dwm, dmenu and other quality software with a focus on simplicity, clarity, and frugality.

There are also other incredible pieces of software that are worth mentioning, including st.

Here, I will only go over the tools I use frequently, but keep in mind that everything from Suckless… Sucks less.

st — Simple Terminal

I did not know what to expect from this terminal and I found it delivers what I need! Configuring it is quite different than other terminals like Konsole or GNOME Terminal: you just edit a text file and compile the software before you can even use it. It may seem tedious at first, but compiling such a small piece of software is very fast and it needs to be done on seldom occasions when you may want to adjust a setting.

I have experienced rendering issues when scaling the text with other terminals (including Konsole), where some weird flickering would happen at certain font sizes. Simple Terminal just works without hassle. It doesn’t have much bells and whistles out of the box, but it can be patched to extend its functionality if you know what you are doing. I don’t, so my compiled version remains pretty basic although I must say I like the simplicity of it very much.

Configuration

I didn’t have to adapt the configuration file very much. I ended up changing mainly the following lines:

 cpp
 
 
 
static char *font = "Consolas:pixelsize=18:antialias=true:autohint=true";

static char *shell = "/bin/zsh";

/* Terminal colors (16 first used in escape sequence) */
static const char *colorname[] = {

 /* 8 normal colors */
 [0] = "#1c1c1c", /* black */
 [1] = "#ff005b", /* red */
 [2] = "#70e502", /* green */
 [3] = "#fcdd11", /* yellow */
 [4] = "#00a0ea", /* blue */
 [5] = "#bd1efc", /* magenta */
 [6] = "#14ecfc", /* cyan */
 [7] = "#ededed", /* white */

 /* 8 bright colors */
 [8] = "#666666", /* black */
 [9] = "#ff00a0", /* red */
 [10] = "#5dff00", /* green */
 [11] = "#ff9f00", /* yellow */
 [12] = "#71a9fc", /* blue */
 [13] = "#d571fc", /* magenta */
 [14] = "#6cf2fc", /* cyan */
 [15] = "#fcfcfc", /* white */

 /* special colors */
 [256] = "#0a0500", /* background */
 [257] = "#e0e0e0", /* foreground */
};

/*
 * Default colors (colorname index)
 * foreground, background, cursor
 */
unsigned int defaultfg = 257;
unsigned int defaultbg = 256;
static unsigned int defaultcs = 257;
static unsigned int defaultrcs = 256;

/*
 * Colors used, when the specific fg == defaultfg. So in reverse mode this
 * will reverse too. Another logic would only make the simple feature too
 * complex.
 */
static unsigned int defaultitalic = 7;
static unsigned int defaultunderline = 7;

/*
 * Default shape of cursor
 * 2: Block ("█")
 * 4: Underline ("_")
 * 6: Bar ("|")
 * 7: Snowman ("☃")
 */
static unsigned int cursorshape = 2;

/*
 * Default columns and rows numbers
 */

static unsigned int cols = 80;
static unsigned int rows = 24;

dmenu

dmenu can be configured in the same way as Simple Terminal by editing a text file and compiling the software. I like to use many keyboard shortcuts, but I find that for launching applications I don’t use that often or to launch custom Bash or Python scripts on the fly, nothing beats the simplicity of dmenu.

Configuration

This one is very easy to configure and doesn’t really require any attention at all besides defining where you want it to appear on the screen and what colors you prefer. Here are some smalls changes I made to the configuration in config.h before compiling it:

 cpp
 
 
 
static int topbar = 1; /* -b option; if 0, dmenu appears at bottom */
/* -fn option overrides fonts[0]; default X11 font or font set */
static const char *fonts[] = {
	"Consolas:size=12"
};
static const char *prompt = NULL; /* -p option; prompt to the left of input field */
static const char *colors[SchemeLast][2] = {
	/* fg bg */
	[SchemeNorm] = { "#D8D8D8", "#000000" },
	[SchemeSel] = { "#000000", "#ff7400" },
	[SchemeOut] = { "#000000", "#00ffff" },
};
/* -l option; if nonzero, dmenu uses vertical list with given number of lines */
static unsigned int lines = 0;

/*
 * Characters not considered part of a word while deleting words
 * for example: " /?\"&[]"
 */
static const char worddelimiters[] = " ";

slock

What can be said about slock? It just works and never gets in your way. Set it and really forget it. From the official page:

This is the simplest X screen locker we are aware of.

Again, its simplicity is charming and nothing really needs to be changed in config.h apart from colors and setting the correct username and group name to lock and unlock the screen.

Conclusion

This was a lighting fast overview of some of the tools I now use on a daily basis. Suckless tools caught my attention and kept it! They offer other specialized software like a web browser, a tool for presentation from the terminal, IRC client and others… but the ones described here are really those which I now can’t live without.

I was originally inspired to seek out those tools thanks to Luke Smith, a fantastic YouTuber.

Surfing with qutebrowser — a Keyboard-Driven Web Browser

Sébastien Lavoie — Mon, 11 Feb 2019 14:46:00 -0600

What is qutebrowser?

qutebrowser is a web browser that makes great use of Vim commands to navigate. From its website:

qutebrowser is a keyboard-focused browser with a minimal GUI. It’s based on Python and PyQt5 and free software, licensed under the GPL. It was inspired by other browsers/addons like dwb and Vimperator/Pentadactyl.

Why use it?

Perfect companion to any Vim user

The first notable feature of qutebrowser is obviously how well the use of keyboard shortcuts is integrated with the experience of using the software (there is a useful key binding cheatsheet on the homepage). Search bindings (/, n/N, ?), visual mode (v), tabs (gt, T), copy (yy), open URLs (o/O), J and K for switching tabs, etc. Many key bindings will look familiar to Vim users.

It even features a command mode, accessible by typing :, just like with Vim. Settings can be set from there directly, help can be accessed by typing :help [command/setting], the configuration file can be customized on the fly, the position and size of tabs can be set in many ways, history and settings page can be accessed and navigated through like any other page (hjkl, Ctrl + d, Ctrl + u, gg, G), etc.

Even though it is based on Python which is a “slow” language, most of the libraries and the web engine rely on C++ and the end result is a fast and powerful browser that’s totally customizable… Not unlike Vim.

Minimal interface ⇒ more space

Until I upgrade my laptop to a larger screen (≥ 17 inches), my current setup with its 15 diagonal inches benefits tremendously from configuring all applications to use pixels as efficiently as possible — which is why I now use exclusively [i3 as a window manager](/posts/2019/01/08/using-i3-as-a-window-manager-for-increased-pr oductivity/).

qutebrowser doesn’t even have a menu bar. By default, it only displays a small tab bar at the top (which can be moved to another side or removed) and a thin status bar at the bottom to see the URL, the current position in the page expressed in percentage, the number assigned to the current tab, etc. There is also a fullscreen mode available like in most other web browsers with the key F11, which will remove any window decoration and leave you in a (possibly) productive mode.

History, bookmarks and quickmarks

The history page (:history), while being minimal like all the rest, loads extremely fast and is a joy to navigate. The bookmarks page (Sb) is equally simple yet useful. The way I like to open a bookmark is in a new tab by typing gB (go bookmark as a mnemonic. Note that usually all uppercase letters open or do some action in a new space, such as a window or a tab).

Where qutebrowser shines in my opinion is with quickmarks. This is a simple but genius way to find what you are looking for: you type b (or B for new tab) to open a list of pages that are defined with a keyword, you type that keyword (or can type anything to search for a page), move around with arrow keys if necessary to select a page, type Enter and there you go. As far as I know, Google Chrome doesn’t offer the equivalent (only keywords for search engines). Firefox allows to add keywords for any bookmark that you have, but there is no good way to search around for keywords, define them quickly, remove them quickly, etc. qutebrowser comes with a set of commands that serve just this purpose (:quickmark-add, quickmark-del, etc.), apart from adding them very quickly by typing m for quickmarks and M for bookmarks.

Hinting system

You may have tried extensions for other web browsers such as Vimium, Vimperator, or Vimium-FF that let you navigate with Vim shortcuts. They usually use the letter f for following links. Some text appear on the screen for each visible link and you type the letters that match the link you want to see. The best way to get how it works is just to try it out, really.

Well, qutebrowser takes those features and make them even greater! There is, for example, a rapid hinting mode you can access by typing f followed by Ctrl + r and it will open links in the background for as long as you type any matching hint provided as a letter or combination of two letters when there are many visible links on the page. This is especially useful when doing some research to avoid breaking the rhythm on the current reading while preparing more resources to be available.

What’s the best place to start learning about it?

The help page on the website contains all the information you really need. I did stumble upon the following resources, which I would recommend to read in order of appearance:

Quickstart Guide.
[Key bindings cheatsheet](https://raw.githubusercontent.com/qutebrowser/qutebrowser/ma ster/doc/img/cheatsheet-big.png).
FAQ, which is interesting but not indispensable. It did help me take a step forward in trying out qutebrowser though.
Open inside qutebrowser: default keybindings.
Open inside qutebrowser: settings page.
List of commands.

Conclusion

qutebrowser has been around for a while and is very stable. It is ideal for any Vim user and is a great option for anyone interested in efficiency and/or in trying out alternatives. Because I am very fond of relying on the keyboard as much as possible and because I love to program in Python, I have grown to like this web browser very quickly. This is clearly a tool designed for a specific type of user in mind and who knows, you might be one of those.