vscode on tkainrad

Automatically add `-tags with a Single Regex`

Fri, 04 Dec 2020 00:00:00 +0000

Introduction

Until about a year ago, I had the same approach to regular expressions as most developers: Doing trial and error until the damn thing was working.

Then came KeyCombiner and with it some very specific challenges around parsing text that contains keyboard shortcuts. One of these challenges is writing blog posts about KeyCombiner:

These posts contain a lot of keyboard shortcuts that should be highlighted via <kbd> tags. By now, these tags are supported by most static site generators and blogging platforms, such as DEV.to. However, typing them in manually is extremely tedious. Initially, I felt quite smart when I added a user snippet in VSCode:

"kbd": {
    "scope": "markdown",
    "prefix": "kbd",
    "body": [
        "<kbd>$0</kbd>"
    ],
    "description": "Insert HTML kbd tags"
},

This lets me type kbd, press ctrl+space and hit enter to put my cursor in-between an opening and a closing <kbd> tag. However, it does not help with copy-pasted text, which is an essential use case for me. I write the first draft of my posts in Notion, as described in my post about personal knowledge management. Even if this were not an issue, it’s still quite a lot of keys to hit for just adding two tags. Another solution would be to write a script in some interpreted language and do all kinds of fancy things to this text. The problem is, this script will likely end up like many single-purpose scripts do: Abandoned and buggy.

So, I needed a better, more timeless solution: Regular Expressions.
Fear not, I won’t try to teach you general regex syntax. Instead, I will show how to use it for this particular use case. I will explain in detail how and why this works, but you can also just copy-paste the final regex and apply it for yourself. One of the best tools for putting the regex to work is Visual Studio Code, but any editor that supports regex-based replace operations will do.

How-To

Suppose we have the following text:

Modifier keys, such as ctrl, shift, alt, and cmd do nothing by themselves but can be used in combination with other keys. To paste without the original formatting, use ctrl+shift+v. Debugging is controlled via f5, f6, f10, and f11.

What we want to have is this:

Modifier keys, such as ctrl, shift, alt, and cmd do nothing by themselves but can be used in combination with other keys. To paste without the original formatting, use ctrl+shift+v. Debugging is controlled via f5, f6, f10, and f11.

The next sections will describe how we get there.

Modifiers and F-keys

We can already go pretty far with this regex that uses or operators (|) to match a predefined set of strings:

(f1|f2|f3|f4|f5|f6|f7|f8|f9|f10|f11|f12|backspace|tab|enter|shift|ctrl|cmd|alt|capslock|pageup|pagedown|ins|del|option|meta)

Putting the expression in brackets () means that it is a capture group. Capture groups are an essential concept when working with regular expressions. One of their greatest features is that we get to reference them by number in the replacement string:

<kbd>$1</kbd>

This means we will replace a match of the first capture group with itself ($1) surround by the desired tags.

The above text will become:

Modifier keys, such as ctrl, shift, alt, and cmd do nothing by themselves but can be used in combination with other keys. To paste without the original formatting, use ctrl+shift+v. Debugging is controlled via f5, f6, f10, and f11.

This is a good start, but we are not quite there yet. Non-modifier keys that are part of key combinations do not yet have the proper tags. We will deal with them in the next section. But before, we can shorten our expression a bit, by switching out the f-keys with a single sub-expression: f([2-9]|1[0-2]?). This will match any f-character followed by either 2-9 or a sequence of 1 and 0-2. It is equal to typing out the f-keys, but a little more fun. So we end up with this expression:

(f([2-9]|1[0-2]?)|backspace|tab|enter|shift|ctrl|cmd|alt|capslock|pageup|pagedown|ins|del|option|meta)

Regular keys in combinations

Matching regular keys is a bit more tricky. We cannot just match any v characters in our text. One approach is to match any single alphanumeric character that is preceded by a +-sign. To do this, we need to use something called Lookarounds, more more specifically, a Lookbehind: (?<=\+) The nice thing about lookarounds is that they do not increase the matched character sequence. Instead, they specify what must (or must not) come before or after the matched part, which is very useful when applying replacement operations. Adding this to our expression results in the following:

((?<=\+)[\w\d]{1}|f([2-9]|1[0-2]?)|backspace|tab|enter|shift|ctrl|cmd|alt|capslock|pageup|pagedown|ins|del|option|meta)

Using this expression, we end up with the desired text already:

Modifier keys, such as ctrl, shift, alt, and cmd do nothing by themselves but can be used in combination with other keys. To paste without the original formatting, use ctrl+shift+v. Debugging is controlled via f5, f6, f10, and f11.

However, we shouldn’t celebrate too early. There are still some issues and special cases to take care of:

What happens if a modifier appears within another word, such as ins in insert?
What happens if we apply this to text that already has some <kbd> tags?

The answer to both questions is clear: Terrible things will happen. We will have to go a bit deeper.

Avoiding False Positives

Now that we already know the Lookaround concept, this is relatively easy. We will ensure that the expression only matches occurrences surrounded by one of these characters: [\+ .,\n].

(?<=[\+ .,\n])(backspace|tab|enter|shift|ctrl|cmd|alt|capslock|pageup|pagedown|ins|del|option|meta|f([2-9]|1[0-2]?)|(?<=\+)[\w\d]{1})(?=[\+ .,\n])

Achieving Idempotence

An idempotent operation is one that can be applied more than once without changing the outcome. To achieve idempotence, we will make use of another advantage of our beloved lookarounds: They can be stacked one after another. All we have to do is make sure that our matches are not already preceded by a <kbd> tag, using a negative Lookbehind:

(?<!<kbd>)(?<=[\+ .,\n])(backspace|tab|enter|shift|ctrl|cmd|alt|capslock|pageup|pagedown|ins|del|option|meta|f([2-9]|1[0-2]?)|(?<=\+)[\w\d]{1})(?=[\+ .,\n])

We could add a negative Lookahead for the closing tag, too, but it is not needed.

Final regex

That’s it. We have a regular expression that we can use in VSCode and other editors to automatically surround all occurences of keys with <kbd> tags. To use it, search for this expression with the Use Regular Expression (alt+r)-toggle enabled:

(?<!<kbd>)(?<=[\+ .,\n])(backspace|tab|enter|shift|ctrl|cmd|alt|capslock|pageup|pagedown|ins|del|option|meta|f([2-9]|1[0-2]?)|(?<=\+)[\w\d]{1})(?=[\+ .,\n])

Then, replace all occurrences string:

<kbd>$1</kbd>

If you want to go one step further, you could even apply this in a build pipeline, e.g., after pushing to GitHub Pages or GitLab Pages. Personally, I like to do it myself in VSCode. These are very satisfying 30 seconds of work before publishing a new blog post.

Conclusion

Hopefully, I could help a bit to improve the bad reputation of regular expressions. But I will let you in on a little secret. Just like everyone else, I have a hard time remembering the syntax. The good thing is, I have a superpower to overcome this: KeyCombiner’s instant shortcut lookup. Whenever I press super+c, I have instant access to the shortcuts of the active application, all other shortcuts that I like to use, and even regex syntax:

Instant shortcut lookup of KeyCombiner’s free to use desktop app.

Learning all VSCode shortcuts evolved my developing habits

Sun, 15 Nov 2020 00:00:00 +0000

Preface

I spent a few hours spread over the last couple of weeks to learn every single one of VSCode’s keyboard shortcuts, specifically the 149 shortcuts from the official keyboard shortcuts reference. These are also present in KeyCombiner’s searchable table of VSCode shortcuts.

Admittedly, I started this challenge to write a blog post about it afterward and as a way to promote KeyCombiner via content marketing. The blog post I had in mind would be similar to my previous one, documenting my process of learning 50 new web application shortcuts in 42 minutes.

But, as it usually happens only in romantic comedies, my intentions changed over time. This article turned out much different. It is not about the learning process but about how this challenge changed some of the developing habits I had for many years. Workflows that I grew used to during many projects, different IDEs, and even varying programming languages suddenly evolved.

In case you do want to see how detailed statistics about how KeyCombiner helped me to learn all VSCode shortcuts, have a look at this overview. It shows a timeline of how my knowledge evolved. It took 205 practice runs (=205 minutes ~ 3.5 hours) until I mastered the complete collection.

Habits are Hard to Break

As software engineers, we like to think that we are continually learning and improving our skills. This is certainly true when it comes to the technologies we are using. However, our development habits, such as which features of our IDEs we use, are much more rigid. I believe most of our core workflows are formed early on and very hard to change. I don’t have data to back this up, but when I look at myself, my co-workers, and other developers I know, this certainly seems true. If you think about it, it is not surprising, the same thing happens in other areas of life. For this very reason, you will find that developers who have studied or worked together will often use similar shortcuts, similar IDE features, and have similar limitations in their workflows.

The usual way to combat this is reading books, blog posts, attending conferences, well, everything that is used in our industry to extend our knowledge. However, with fundamental developing habits, I have found that this works poorly. You might read about a neat feature of your IDE, or see someone demo their workflow, but when you are eventually sitting in front of your screen and writing code, it is easy to fall back to what we already know, what is already set up, and proven to work.

After this experiment, I am convinced that keyboard shortcuts are the main factor in how we form our developing habits, and they can also stop us from evolving our habits. Even before this challenge, I felt that I was good with shortcuts. I knew quite a few refactoring shortcuts, knew how to pause and stop program executing during debugging, was decent at jumping around between files, searching through my project, and all the other usual stuff. When I saw a co-worker using a shortcut that I didn’t know, I was quick to incorporate it into my workflow, too. After all, I was enough into shortcuts that I built a whole side-project around learning them. The thing is, all new shortcuts that I learned were the ones that would augment my existing habits.

This is a hen and egg problem; if you don’t know the shortcuts, you will not start to change your habits and use new IDE features because, without shortcuts, they are too tedious to use or not at all usable. But if you don’t form new habits, you will not learn the shortcuts.

Without intending it, I think I found a way to break out of this cycle: Learning all IDE shortcuts very well before getting back to work. By learning all shortcuts, you are not limited to what somebody shows you and might not be compatible with your situation. You can naturally include what makes sense, in addition to your existing skills.

The next section shows how this worked for me.

Evolving my Habits

I started the learning process as it is usually done with KeyCombiner: By importing some shortcuts from the public collection of VSCode shortcuts into a personal collection. Intuitively, I started with the ones I already knew and some additional that seemed most useful to me. Back then I was still trying to show that I could learn all shortcuts very quickly with KeyCombiner. I didn’t expect that shortcuts that had nothing to do with my existing workflows will be the real deal.

Some of the first combinations that I picked and that I did not know previously were alt+w/r/c for toggling find options (match whole word, regex, case sensitivity) because I was already using those features. This went on for a few days. I did a couple practice runs every day and added new shortcuts whenever KeyCombiner was saying that I mastered all of the previous ones.

Eventually, I knew all shortcuts that seemed useful for how I was using VSCode back then. So I had to start adding shortcuts that had nothing to do with my existing habits. This brought up an interesting misconception. Often keyboard shortcuts are seen as a way to do things faster, compared to using the mouse. While that is true, I think there is an even more important aspect to shortcut usage in IDEs: Many features are not used at all, if you don’t know the shortcut!

As I was learning new VSCode shortcuts every day, I started to use features that I previously didn’t even know of. One of the first things that suddenly made a lot of sense was Select all Occurences of Find Match with Alt+Enter as default binding, especially when combined with regex search. I was so excited about it, that I even tweeted a Gif showing how I use it to modify the CSV files that are the source for KeyCombiner’s public collection tables.

The process worked both ways: Sometimes, while I was practicing a shortcut on KeyCombiner, it seemed apparent that this was useful and that I should include it into my workflow. Sometimes it hit me while coding that I had just learned a shortcut that can make the current task more efficient.

In the following, I describe the most significant changes in my daily development habits. The list is far from complete though; there are many more small things that I picked up and frequently use now.

Editor and Panel Management
Since knowing all the shortcuts to switch focus between panels and move editors around, I am using VSCode’s powerful layouting capabilities much more. I have 3-5 editor panels open at pretty much all times, seeing many related pieces of code at once. Working this way by using the mouse is very impractical. I switch between editor panels with keyboard shortcuts and move editors from one group to the other.

There is one negative side-effect, though: I am starting to get annoyed when I use other IDEs (PyCharm, Eclipse), because they lack far behind VSCode when it comes to using multiple editors.

Multi-cursor Editing
If you don’t know the shortcut to add additional cursors, I doubt you will ever use this incredibly powerful feature of VSCode. It is a typical feature that only blends into your habits once you know the shortcuts. The basic commands are Ctrl+Alt+Up/Down for adding cursors above/below. However, I found the commands to Insert cursor at end of each line selected (Shift+Alt+i), and the above-mentioned Select all Occurences of Find Match (Alt+Enter) even more powerful. These commands are why I frequently paste text snippets into VSCode, apply a few operations, and then copy-paste it back into whatever application I was using.

Opening views by shortcut
I sometimes tried to do this before, but it never stuck. Now I finally switch to all views (Explorer, Debug, Search, Problems, etc.) with dedicated keyboard shortcuts. These shortcuts translate very nicely to other IDEs. After learning the VSCode default bindings, which are Ctrl+Shift+<char>, I set the same bindings also for Eclipse and PyCharm. Especially Ctrl+Shift+e for switching to the explorer view and Ctrl+Shift+d for switching to the debug view are among my most used shortcuts now.

Making Selections
I hate to admit it, but I did not use shortcuts to expand and shrink AST selections before. AST stands for abstract syntax tree, which means that the IDE will take the current language’s syntax into account for modifying the selection. Finally, I picked up Ctrl+Shift+left/right to shrink and expand selections. Not all IDEs handle this in the same way, which can be a bit annoying, but it works well for the most frequent tasks, such as expanding the selection to enclose the current string, method, class, or HTML tag.

Folding
I have started to use folding much more. For years, I have rarely used this feature that all IDEs support to a great extent. Now, I do it frequently. Folding is one of these things that are just not feasible with the mouse. Of course, if you need to fold code, chances are that you need to structure your code better. Many organizations even apply automatic code linters that will complain when methods or classes are too long. However, I have never seen someone recommend splitting up blog posts into multiple files. The same goes for other non-code file types, such as JSON. All we have there is folding.

I am not saying these are the things you should start to learn now, far from it. These are the things I personally integrated deep into my workflows after doing this challenge, without choosing them deliberately, but naturally. Who knows what you will pick up.

Of course, some of the shortcuts I learned still seem a bit, let’s say nonessential, but a little useless knowledge never killed nobody.

More Unexpected Benefits

In addition to finally breaking out of old habits and experiencing a real evolution of my IDE usage, there were some other, less significant, but still delightful second-order effects.

As a shortcut enthusiast, I often had the problem that I needed to decide which binding to use for a particular operation and application pair. KeyCombiner’s public shortcut search helps to find out which binding is the convention for a particular operation, but it can still be tricky. For example, take the frequently used Step Over operation used for debugging. KeyCombiner shows that VSCode, Eclipse, and JetBrains IDEs all use a different default binding(F6,F8,F10). Learning every single VSCode shortcut has freed me from this mental load of deciding what the best binding for a particular IDE operation is. I simply use VSCode’s bindings everywhere. There are good arguments for why VSCode is a good reference. With the rise of GitHub CodeSpaces and its thriving extensions marketplace, I think it is likely that it will emerge as the industry standard of IDEs within a few years. That’s the topic for a future post, though.

Another effect is that I rarely use the mouse anymore when working in VSCode. This is not ideological for me. I hold no grudges against mouse usage. It just so happens that the need to touch it rarely comes up anymore. I guess most people that can do this use Vim or some Vim extension for their IDE. I can say confidently that it also works to learn all the default shortcuts. However, if you aim to eliminate the mouse completely while using VSCode, you should probably still go for one of the popular Vim emulators.

And finally, maybe most importantly, VSCode feels like home now. As someone who also uses other IDEs daily, it’s hard to develop a feeling towards a particular one that this is your professional tool: The place where the magic happens. Now that I have a complete picture of VSCode’s feature set, I feel that I have truly made it my own.

Conclusions

Of course, you don’t have to learn all shortcuts of your IDE. I never thought I would either. You can pick up a new shortcut here or there. Read blog posts where developers show off their selection of favorite shortcuts or exchange favorites with your co-workers. That’s a perfectly fine approach, and it is how a large majority of developers tackle this topic. It is even a core idea of my own project KeyCombiner to build collections of selected keyboard shortcuts that can be learned, shared, and organized.

But, you can also invest a few hours spread over a couple of weeks, stop making compromises, and learn all the shortcuts. There is no way of knowing beforehand how this will influence your habits, how it will amend your existing workflows, and which entirely new possibilities will open up for you.

vscode on tkainrad

Automatically add -tags with a Single Regex

Introduction

How-To

Modifiers and F-keys

Regular keys in combinations

Avoiding False Positives

Achieving Idempotence

Final regex

Conclusion

Learning all VSCode shortcuts evolved my developing habits

Preface

Habits are Hard to Break

Evolving my Habits

More Unexpected Benefits

Conclusions

Automatically add `-tags with a Single Regex`