It took little under a decade for the headline feature developer Jon Skinner added to Sublime Text’s second version to become one of the defining features of this decade’s software.
“Goto Anything” is how it started, a search pane to jump to other files. Open a folder, press
P, start typing to see a list of matching files, then press
Enterto jump to it. Seems simple enough: You think of a file you need, and without leaving the keyboard can switch to that file and continue work.
Within months, that search pane gained a companion: The now-famous Command Palette. “The Command Palette provides a quick way to access commands that don’t warrant a key binding, and would usually be hidden away in a menu,” explained Skinner. This time, you’d press
Pand get a search bar, only here you’d search through program features.
I’ve been lurking the fish shell for a couple of years now (and the nushell but it is another story for another time). Not so long ago, I decided to try it, and it’s simply… amazing. If I had to state one feature that makes me like to use it, it’ll be the autocompletion, hands down. It’s the first time I just take a shell and without customization it’s pleasing to use.
During an idle Sunday evening, a few weeks ago, I played with JetBrains’ Projector: it’s IntelliJ — one of the most powerful IDEs around — installed on a remote server and accessible through the browser.
I wanted to see how I might offload some heavy computing tasks, like training and evaluating large machine learning models, off of my local computer, without compromising my coding user experience.
It’s a surprisingly easy setup to build. It took me less than an hour, from hitting “Create instance” on AWS to having a fully-fledged AI project running on my iPad Pro.
It felt like magic.
Emacs grew support for displaying colour emojis recently (and this is included in the release branch, which will become Emacs 28.1 in some months). This includes support for the grapheme cluster emojis (that consist of a number of Unicode code points, joined together with zero-width joiners and magic).
So finally Emacs can display all of these things. You can thank Robert Pluim, who did all the actual work.
Imagine if someone summoned a magical genie and wished for a perfect code editor. Since it is perfect, does that mean it provides you everything you ever need to code the optimal solution? Or since it is perfect, does it enable you to accomplish the coding aspect instantly?
Thus, the paradox:
Does the perfect code editor mean that you spend nearly 100% of your work time using the editor or does it mean you spend nearly 0% of your work time using the editor?
What metric can we even use to measure the perfect code editor? How will we know if and when we have it? Are we close to reaching that point?
Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.
So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.
Here’s what I learned from starting to read the source code to fff - in particular, the main function.
fffis “a simple file manager written in Bash”. As I’m always on the lookout to learn more about Bash, that description got my attention immediately. It’s a small but perfectly formed offering, complete with man page and even a
Makefilefor installation. And the file manager executable* itself is a single Bash script.
*I use this term deliberately, and it does make me stop and think every time I see scripts in a
bindirectory (where “bin” stands for binary). But that’s a conversation for another time.
The author, Dylan Araps has produced other interesting pieces of software (such as neofetch) as well some great documents such as the pure bash bible as well as the pure sh bible. He’s also the creator of Kiss Linux. He has a reputation for writing great Bash code, so this seems like an opportunity too good to miss to learn from better programmers.
It seems that recently Dylan has disappeared off the radar, I don’t know what the situation is but I wish him well.
Where I can, I link to reference material so you can dig in further to Bash details that take your fancy. This reference material includes the following sites (and there are more of course):
Here is my short answer to that: There isn’t one right way for using Org mode features.
If this is obvious to you, you can skip the rest of this article. If not, you really should read this until the end. It may answer many questions you probably do have in your head. Especially when you’re rather new with the Org mode universe.
Of course, the same rationale is true for all kind of advanced software solutions that offer a certain level of flexibility to its users. However, my examples here are based on Emacs Org mode.
The concept of the staging area is one which many newcomers struggle with when starting to learn git, and the fact that this concept is barely mentioned in the official documentation (i.e. man pages) doesn’t help at all. Instead the official name is “the index” which has absolutely nothing to do with the way users interact with it. That’s the reason most people who teach git prefer to use the term “staging area” instead, and in fact that’s the term used in the best available documentation: the Pro Git book (which is not official), and also pretty much in all online documentation, including tutorials and blog posts (e.g. Atlassian saving changes, code refinery).
Attempts to move away from the incorrect term “the index” towards one that most native and non-native English speakers can grasp without the need for further explanation have been attempted for more than a decade, and even though there’s universal consensus that “staging area” is by far the best alternative, attempts to use it officially in the documentation and user interface have been blocked because one person cannot be convinced.
There’s a keyboard layout I’ve been using for the past 8 or 9 months. It’s called the workgirl layout. It may look familiar to some of you:
By no coincidence, this layout happens to have the exact same key placement as the workman keyboard layout. Rest assured though, it is not the same layout.
Oh, you’re still wondering what the difference is? The name, silly!
It is a well-known “fact”, in some circles, that running grep in the C locale is much faster than in UTF-8 locales, the latter being a common default on current client systems.
Indeed, just the other day, a colleague of mine was running something akin to:
grep ‘“event-type-id”:4727’ app.log
app.logis a multi-gigabyte file of JSON lines1, the goal being to quickly see whether a newly-added type of event is seen. Almost immediately, someone jumped in to recommend running grep in the C locale, instead of the default UTF-8 locale, for Guaranteed Extra Speediness™.
I wondered whether this was indeed good advice. (TL;DR: using the C locale does not help performance in general, or jump to conclusions.)
Alf is a modern, powerful implementation of relational algebra. It brings relational algebra where you don’t necessarily expect it: in shell, in scripting and for building complex software. Alf has an rich set of features. Among them, it allows you to:
Query .json, .csv, .yaml files and convert from one format to the other with ease,
Query SQL databases with a sounder and more powerful query language than SQL itself,
Export structured and so-called “semi-structured” query results in various exchange formats,
Query multiple data sources as if they were one and only one database,
Create database viewpoints (mostly read-only viewpoints for now), to provide your users with a true database interface while keeping them away from data they may not have access to,
Enjoy a rich set of relational operators and even define your own high-level and domain-specific ones.
Neorg is a tool designed to reimagine organization as you know it. Neo - new, org - organization. Grab some coffee, start writing some notes, let your editor handle the rest.
Why do we need Neorg? There are currently projects designed to clone org-mode from emacs, what is the goal of this project? Whilst those projects are amazing, it’s simply not enough. We need our own, better solution - one that will surpass every other text editor. One that will give you all the bragging rights for using Neovim. Here’s how we’ll do it:
Revise the org format - Simple, very extensible, unambiguous. Will make you feel right at home. Org and markdown have several flaws, but the most notable one is the requirement for complex parsers. I really advise educating yourself on just how bad markdown can get at times; what if we told you it’s possible to eliminate those problems completely, all whilst keeping that familiar markdown feel?
Enter the .norg file format, whose base spec is almost complete. The cross between all the best things from org and the best things from markdown, revised and merged into one.
Keybinds that make sense - vim’s keybind philosophy is unlike any other, and we want to keep that vibe. Keys form a “language”, one that you can speak, not one that you need to learn off by heart.
Infinite extensibility - no, that isn’t a hyperbole. We mean it. Neorg is built upon an insanely modular and configurable backend - keep what you need, throw away what you don’t care about. Use the defaults or change ‘em. You are in control of what code runs and what code doesn’t run.
Logic. Everything has a reason, everything has logical meaning. If there’s a feature, it’s there because it’s necessary, not because two people asked for it.
Everyone 1 and their dog 2 loves Git. I know I do. It works, it’s efficient, it has a brilliant data model, and it sports every feature under the sun. In 13 years of using it, I’ve never found myself needing a feature it didn’t have. Until recently.
But before I tell you about it, let’s talk about GitHub.
Even in the age of smartphones I still prefer to check the calendar on my computer and I’ve often been disappointed by the horrible default calendars that ship with some operating systems (e.g. macOS’s calendar accessible via its systray).
Fortunately for us, Emacs users, we always have access to a proper calendar regardless of our OS and desktop environment (if any) -
M-x calendar. By default it looks something like this:
A post-modern text editor.