General

VSCode Keyboard Proficiency

Nov 2, 2022

31 min read

Introduction

The tools used in the programming craft are varied and the ones developers use depend on the kind of work they are doing. However, two of these tools are omnipresent: the keyboard and the text editor. As such, learning how to use these tools effectively is crucial.

This blog is an introductory guide on using and configuring VSCode (one of the most popular IDEs among programmers) to maximize your productivity and proficiency with the keyboard. Here are some notes about what you should expect from it:

We will be using a fresh installation of VSCode for this guide.
We will be configuring the keybindings for the Mac keyboard. It is up to you to set it up to your liking in your OS of choice.
This guide is not a comprehensive guide to VSCode, but an introduction to maximizing keyboard usage in VSCode.

That being said, let's get started!

The Keyboard Shortcuts Editor

The first command we will learn is the command to open the keyboard shortcuts editor. The command's name is workbench.action.openGlobalKeybindings, and it is bound to Cmd+K Cmd+S by default.

Let's try it. Press Cmd+K Cmd+S, and you should see the keyboard shortcuts editor open up. This is where you can modify the default keybindings of VSCode.

This command opens the keyboard shortcuts editor, which is a JSON file that contains all of the keybindings that are currently in effect. The keybinding is the key combination that triggers the command. The command is the name of the action performed when the keybinding is pressed.

The When column contains the conditions that must be met for the keybinding to be active.

Finally, the Source column contains the extension's name that defines the keybinding. If an extension includes the keybinding, the source will be the extension's name. If VSCode determines the keybinding, the source will be Default.

Movements

Cursor movements are the most common actions we perform when reading or writing code. The cursor movement could be done in a single file between multiple files, between consecutive lines, or from one line to another located 100 lines away.

This is the skill you will use the most and, therefore, where we will lose the most time if we use the mouse. The following are the most common ways to move the cursor around the text.

Single unit cursor movement -- Arrow Keys

The beginning of this journey starts with the arrow keys. We are most tempted to use this all the time since it is the most intuitive of the movements with nearly zero mental overload.

However, the arrow keys are not the actual name of this movement. We are actually referring to four movements: cursorLeft, cursorRight, cursorUp, and cursorDown. These are the commands that are bound to the arrow keys by default.

Horizontal Movement. Word cursor movement

Although moving the cursor one character at a time was not a big deal for that contrived example, let's see what happens if we try to hit the 🎯 on a long line.

Please give me the mouse! Just kidding, we are not going to use the mouse. We are locked with the keyboard, but even I was tempted. Then, how do we get faster?

We can use the word cursor movements to improve our efficiency. The main two cursor word movements are the cursorWordLeft and cursorWordEndRight; they will allow us to move one word at a time. By default, movements are bound to Option+Left and Option+Right, respectively, but again feel free to customize everything to your liking.

As we can see on the Word Cursor Movements Configs image, we can use many more word movements. Feel free to explore them and see what they do.

Ok, no more talk, let's show our new movements.

That's better. Our speed of moving around in a line has improved significantly.

There are, however, some observations to make. Firstly, we move nearly to the end of the "visible" line one word at a time. If we started from the end of the line, we would have to make fewer movements. Secondly, we have no idea where the line ends because it overflows out of the editor's viewport.

To fix the line overflow, we need to change a configuration setting. The setting is editor.wordWrap, which is set to off by default.

Much better. Now we can actually tell where the cursor is at any moment.

Horizontal Movement. Line start/end cursor movement

Now that we can visualize where the cursor can be placed at any moment in the line, we can optimize our previous movement by moving the cursor to the end of the line before reaching the 🎯.

We will use the cursorEnd and cursorHome commands. By default they are bound to Cmd+Right and Cmd+Left respectively.

Yes, that was a lot better. We can now move the cursor to the end of the line and then move one word at a time to the 🎯.

However, we know that's not really the end of the line. That's the end of the editor viewport. We have some movements if we really need to move to the end or start of the line.

The cursorLineEnd and cursorLineStart commands do exactly that. They are bound to Ctrl+A and Ctrl+E, respectively.

Let's see it in action.

I don't use these movements very often because I spend most of my time editing code which is usually formatted to fit the editor viewport width. For that reason, I have overridden one of these commands with something more valuable to me that I'll show you later.

Horizontal Movement. Bonus and Sneak Peek

We have covered so far the most common horizontal movements. However, there is another helpful movement that I'll cover next, but I guess I can tell you something about it now. The workbench.action.gotoLine lets you move the cursor to a specific line, and a particular character or column.

Alright, that covers up the horizontal movements. Now practice them until you can do them without thinking.

Vertical Movement. Lines cursor movement

Horizontal movements are great, but after wrapping your lines and formatting the code, the text will fit the editor's viewport making vertical movements the most common type.

The most basic form of vertical movement is the cursorUp and cursorDown commands using the arrow keys, as shown in the first movement section. But as we have seen before, this is very inefficient.

Don't believe me? I'll show you. Let's take this example to the ThisDot Open Source repository.

Ugly! And that's just a few lines. Imagine if we had to move the cursor 100 lines up or down. We would be here all day.

Luckily for us, there are some more efficient ways to move the cursor up and down.

Vertical Movement. Top and Bottom of the file

As with the line start/end movements, we can move the cursor to the top or bottom of the file. The commands are cursorTop and cursorBottom and by default they are bound to Cmd+UpArrow and Cmd+DownArrow respectively.

These are primarily useful when you know that the line you are looking for is near the top or bottom of the file. But in long files, this is not always the case.

Vertical Movement. Go to Line

Until now, we still don't have an efficient way to move across lines. Lucky for us, we can move the cursor to any line in the file with the global goto line movement.

The command is workbench.action.gotoLine, and is bound to Ctrl+G by default.

With this movement, we can move the cursor to any line in the file in just a few keystrokes. We can also move the cursor to a specific character or column on that line.

And we can further optimize. The workbench.action.gotoLine command requires us to type the global line number. For long files with hundreds or thousands of lines, the number of digits to type increases along with the frequency of typos. Additionally, we must look carefully at the line number before moving the cursor to the line.

Vertical Movement. Go to relative line

Relative line numbers and a relative goto movement would solve these problems. However, the relative goto feature is not available out of the box in VS Code, but we can add it with the Relative Goto extension.

This extension does a few things for us:

It turns on the relative numbers setting.

And it adds a keybinding called relative-goto.goto, bound to Cmd+G by default.

But first, we need to change the default keybinding. The reason is that the Cmd+G keybinding is already used by the editor.action.nextMatchFindAction command.

I like to use Cmd+L for this command because it is an excellent mnemonic for Line.

Before anything, yes, I used the mouse to change the keybinding. I know I'm a terrible person.

With that out of the way, let's see how it works.

Yes, much better! We have reduced the overhead of moving the cursor to a global line. And if you notice, we can move to a previous line using negative numbers.

Hydration Pause -- Selection

Let's take a break from our keyboard mastery path and use this pause to cover something intrinsically related to cursor movement: text selection.

All the movements that we have covered so far have a selection counterpart. For example, the cursorLeftSelect command selects the character to the left of the cursor. The cursorWordEndRightSelect command selects the word to the right of the cursor. And so on.

The relative goto movement also has its selection counterpart. It is the relative-goto.select command. The command is bound to Cmd+S, an apparent mistake because it collides with the save keybinding. In my case, I have changed it to Cmd+Option+L. Why not Cmd+Shift+L? This is because I use that keybinding for the expandLineSelection command.

Let's see them all in action to make clear what I mean.

There are many more selection movements, but that clip exemplifies what's possible.

Vertical Movement. Scrolling Editor

Often, we need to go to a line outside our current page. We could try to find a word (Cmd+f) that we know is in that line. Or we could try to go directly to a symbol near that line if we know the symbol's name (Cmd+Shift+O). But we likely won't know where the line is, and will scroll to find it. USING THE MOUSE. Well, not anymore.

Scrolling is also possible using the keyboard! We can use one line scroll commands by using scrollLineUp and scrollLineDown bound to Ctrl+PageUp and Ctrl+PageDown by default. Additionally, we can use one page scroll commands by using scrollPageUp and scrollPageDown bound to Cmd+PageUp and Cmd+PageDown by default.

Fantastic, with these movements, we are now mouse free when scrolling through the file.

However, when scrolling large files, the relative line goto will have the same problems the global line number goto had.

A tool to solve this issue is the Scroll with Stationary Cursor extension. This extension adds two new keybindings that keep the cursor static to the editor viewport while scrolling. The commands are extension.scrollWithCursorUp and extension.scrollWithCursorDown bound to Ctrl+Option+Cmd+UpArrow and Ctrl+Option+Cmd+DownArrow by default.

Since it is my primary way of scrolling the editor, I have changed the keybinding to Ctrl+PageUp and Ctrl+PageDown, replacing the regular line scroll commands.

The last scrolling trick is the Scroll to Cursor extension. This extension adds a new command called scrollToCursor bound to Ctrl+L by default. This command will scroll the editor, so the cursor is near the top of the viewport.

That's all for scrolling; make sure that you explore all the other extensions and keybindings that VS Code provides for scrolling. There are many more that I didn't cover here.

Multiple Groups Movement

So far, all the examples we have seen use a single group or panel. To maximize my efficiency, I usually work with two or three VSCode groups side by side.

The next set of movements will focus on interacting with VSCode groups. For simplicity, we will focus on two vertical groups, but the same concepts and techniques will apply to having several vertical or horizontal groups.

The easiest and quickest way to create a new group is by using the workbench.action.splitEditor command. This command is bound to Cmd+\ by default, and it will split the current group in two, creating the new one to the right of the current group and moving the focus and the cursor to the newly created group.

This technique is beneficial when we want to work over two different sections of the same file. But what if we want to work on a different file? For that, we can use the workbench.action.focusSecondEditorGroup command.

This command is bound to Cmd+2 by default, and it will create a new group if there is only one and move the focus to the newly created group. If there are already two groups or more, it will move the focus to the second one from left to right. It removes the overhead of needing a command for the creation and another for focus.

Now let's learn how to move between groups. For that, we can use the workbench.action.focusRightGroup and workbench.action.focusLeftGroup commands. These commands are bound to Cmd+K Cmd+Right and Cmd+K Cmd+Left by default, but since I don't use the next and previous editor commands I have changed it to Cmd+Option+Right and Cmd+Option+Left.

There is one detail. These commands are not circular, which means that if you are in the last group to the right, Cmd+Option+Right will not move the focus to the first group. Just keep that in mind.

Fantastic! But what if we want to move a file from one group to another? VSCode has you covered, with the workbench.action.moveEditorToNextGroup and workbench.action.moveEditorToPreviousGroup commands. These commands are bound to Ctrl+Cmd+Right and Ctrl+Cmd+Left by default. Additionally, if we don't have a second group, these commands will create one and move the file.

Code Interactions

Everything we have covered until this point has been navigating our files and groups. It is time to learn new keyboard shortcuts to improve how we interact with our code.

Quick Fix

The editor.action.quickFix command is one of the essentials of VSCode. This command is bound to Cmd+. by default and will show the current word, line, or symbol's quick fix suggestions.

It is helpful for compilation or linting errors and typos or missing imports. It replaces the need to use the mouse to click on the light bulb that appears in the gutter.

Hover and Peek

As the "quick" in "quick fix" implies, sometimes VSCode is not intelligent enough to understand how a given problem could be fixed. Or sometimes, the solutions can be ambiguous without knowing what the problem is, and its context. In these cases, our first instinct is to hover over the error and see what the problem is. But what if I tell you that you can do that without moving your hands from the keyboard?

For that, the editor.action.showHover command exists. This command is bound to Cmd+K Cmd+I by default, and it will show the hover information for the current line. I simplified its keybinding, and made something more memorable for me; I changed it to Ctrl+H and removed the other conflicting keybindings.

This command is not only beneficial for errors, but also for inspecting any piece of code. But if we want to focus on an error, we have another command. The editor.action.marker.nextInFiles will walk us around the current file's errors, warnings, and other markers in sequential order.

The command is bound to F8 by default, but I hooked it to Ctrl+E to make it easier for me. If we want to move to the previous marker, we can use the editor.action.marker.prevInFiles command bound to Shift+F8 by default, and again I modified it to Ctrl+Shift+E.

Adding to the list of things you would never imagine doing without the mouse, I bring you the editor.action.showContextMenu command. This command is bound to Shift+F10 by default, and will show the current line's contextual menu.

Like with the hover command, I tried to assign a more memorable keybinding. I changed it to Ctrl+M.

Refactor

I already gave you a sneak peek of the following command. The refactor command allows us to... well, refactor our code. It is bound to Ctrl+Shift+R by default, and will show the current line's refactor menu. It might not be as powerful as WebStorm refactoring capabilities, but I hardly ever need more than VSCode offers.

Go to Definition

One of the most common actions when interacting with code is visiting the definition of a given symbol. With the editor.action.revealDefinition command, we can explore an element's declaration, type, implementation, and documentation and learn more about it. This command is bound to F12 and includes a hidden trick few people know. If executed over the definition of the symbol, it will show us its references instead.

Since I use this command very often, I have to change the keybindings to Cmd+Enter. That way, we don't have to move our fingers from the center of the keyboard.

Go Back and Go Forward

With all the commands learned so far, we will be jumping through code all the time, reading, and editing. What happens if we want to return to a previously visited point?

Fortunately, the editor keeps track of the current cursor positions allowing us to navigate forward and backward the cursor history. This ability is attached to two commands, workbench.action.navigateBack and workbench.action.navigateForward. These commands are bound to Ctrl+- and Ctrl+Shift+- by default, but I changed such useful commands to something I would remember. I use Ctrl+[ and Ctrl+] respectively.

Folding regions

Sometimes we want to focus on substantial parts of the file or the function we are working on, avoiding the cognitive burden of everything that might happen in a file.

VSCode will help identify foldable blocks out of the box based on the syntax used. Then the fold and unfold commands can collapse and expand these regions allowing us to focus. These commands are editor.fold and editor.unfold, respectively, and are bound to Cmd+Option+[ and Cmd+Option+] by default.

The result is what we wanted, but to get there, we had to move a lot across the code and execute the command several times. A better way is to use the editor.foldAll and editor.unfoldAll commands, bounded to Cmd+K Cmd+0 and Cmd+K Cmd+J by default.

That was a bit better but still not ideal. Why can't we fold everything but the block we are standing on? Well, we can; there is a command for that. It is called editor.foldAllExcept and is bound to Cmd+K Cmd+- by default.

To have even more control, VSCode added the possibility to create custom fold regions. Consider it homework to learn how to do it.

Deleting Code

I have a serious question: Is there anything more fun than deleting code? Ok, I know that is not a serious question, but I am serious about the answer. Deleting code is the best! And VSCode makes it even better with the editor.action.deleteLines command. This command is bound to Cmd+Shift+K by default and will delete the line under the cursor.

Yes, we can do the same with Cmd+X, but the difference is that Cmd+X will copy the deleted line into the clipboard, and Cmd+Shift+K will not. If you want to see the line disappear and prefer your clipboard clean, Cmd+Shift+K is the way to go.

There is another difference. See where the cursor is after executing both commands.

The entire line is too much? Instead, we can remove everything to the left or right of the cursor. The editor.action.deleteAllLeft and the editor.action.deleteAllRight commands will do exactly that. These commands are bound to Cmd+Backspace and Cmd+Delete by default.

What else can we delete? Words! We can delete words. The deleteInsideWord command will delete the word below the cursor. This command has no keybindings by default, but I like to assign it to Ctrl+Backspace. But that's not all, the editor.action.deleteWordLeft command will delete the word to the left of the cursor, and the editor.action.deleteWordRight command will delete the word to the right of the cursor. If the cursor is in the middle of a word, it will partially delete it. These commands are bound to Option+Backspace and Option+Delete by default.

Moving and Cloning lines

Maybe mayhem is not your thing; maybe you feel more joy when moving things around like a house decorator or a creative Minecraft player. VSCode has you covered with the editor.action.moveLinesUpAction and editor.action.moveLinesDownAction commands. These commands are bound to Alt+UpArrow and Alt+DownArrow by default and will make you happy.

Are you more of the scientific type? What about cloning some lines? The commands editor.action.copyLinesUpAction and editor.action.copyLinesDownAction will do just that. These commands are bound to Shift+Alt+UpArrow and Shift+Alt+DownArrow by default.

Multiple Cursors

This section covers one of my favorite features of VSCode, the multiple cursors. This feature is not unique to VSCode and was implemented successfully in other editors like Sublime Text and Atom. However, VSCode has nailed it, and it's something I feel I couldn't live without.

Insert cursor on next line

There are some instances where you have similar lines of code next to each other, and you want to make a change in all of them. For example, if you have a list of private properties that you want to make protected, you could find and replace all of them, but that would be a bit tedious, especially if the file has other properties that you don't want to modify. Or maybe you have several objects with a similar signature and want to add a new property to all of them. You can use the editor.action.insertCursorBelow command in these cases. This command is bound to Cmd+Option+DownArrow by default.

I hope you appreciate the power of this command. There is a caveat, though. We saw in a previous chapter that VSCode has two representations for what a line of code is.

The first is the actual line of code represented by the lack of a line break in a set of text, and the second is the artificial line created by VSCode when the wrap text setting is on. The editor.action.insertCursorBelow command will only work on the first type of line. To insert a cursor below in an artificial line, you can use the cursorColumnSelectDown command. This command is bound to Cmd+Option+Shift+DownArrow by default.

The following example shows the differences between the two commands and, in this case, using the editor.action.insertCursorAbove and cursorColumnSelectUp variants.

Selecting next occurrence

Returning to our first example of changing the visibility of a property, there are a couple of things that we can do better. For example, with the editor.action.insertCursorBelow, we are dependent that the lines we want to edit are one below to other. Additionally, we had to create the cursor and select the visibility keyword. We can do better. The editor.action.addSelectionToNextFindMatch command will select the next occurrence of the word under the cursor. This command is bound to Cmd+D by default.

This gives a low extra grip on what we want to edit. The words could be at any position, and the command would still work. Its broader version is the editor.action.changeAll, which will select all word occurrences under the file's cursor. This command is bound to Cmd+F2 by default, but since I like it so much, I have changed it to Option+Shift+D.

There are some variations of this command that I'll mention, but let you find and customize to your liking.

The editor.action.addSelectionToPreviousFindMatch command will select the previous occurrence of the word under the cursor; it is unbound by default.

The editor.action.moveSelectionToNextFindMatch command will move the cursor to the next word occurrence under the cursor. This command is bound to Cmd+K Cmd+D by default. The editor.action.moveSelectionToPreviousFindMatch command will move the cursor to the previous occurrence of the word under the cursor. This command is unbound by default.

Cursor Undo

To close this section, I want to show you how to undo a mistake with multiple cursors. The cursorUndo command will undo the last cursor operation. This command is bound to Cmd+U by default, which is advantageous when handling many cursors simultaneously.

That's the perfect closing for this chapter. See you in the next one.

Main Sidebar Tools

The VSCode main sidebar contains some of the most essential tools for a developer. The Explorer, the Search, the Source Control, the Extensions, and many others could be native, or added through extensions.

This is our final chapter. Here we will cover the Explorer and the Search tools since these are probably the most used ones. The knowledge we will gain in this chapter can be applied to any other side menu tool.

Explorer

The explorer is possibly the most used tool in VSCode. It is where we can see all the files and folders in our project. It is also where we can create, rename, delete, and move files and folders.

Our natural instinct when seeing a file explorer is to use the mouse to navigate through the files and folders. However, VSCode has a powerful keyboard navigation system that will allow us to navigate through the explorer without touching the mouse.

First things first, how do I open it? The workbench.view.explorer command is what you want. The command is bound to Cmd+Shift+E by default, but additionally to this, I have also included the Ctrl+1 keybinding. That way, I can have a unified way to open all my sidebar tools.

That's cool. Now let's start moving around. The explorer has a tree structure, so we can move up and down the tree using the list.focusUp, and list.focusDown commands.

These commands are default bound to Up and Down. Additionally, we can expand or collapse a subtree using the list.expand and list.collapse commands. These commands are default bound to Right and Left. Notice that if one of the focus commands on a collapsed subtree, it focuses on the collapsed node. But if the subtree is expanded, the actions will focus on one of its children.

From the movement perspective, this can be all you need, but there are two other movements that I like to use. These are the list.focusFirst and the list.focusLast, which will move the focus to the first and last node in the explorer, respectively.

These commands are default bound to Home and End. However, I like to use Cmd+UpArrow and Cmd+DownArrow for these actions, and keep consistency with what I use in the editor.

However, these new keybindings are in conflict with other commands. Therefore, I removed the conflicting commands.

For the Cmd+UpArrow keybinding are the list.collapse and list.scrollUp
For the Cmd+DownArrow keybinding are the explorer.openAndPassFocus, list.select and list.scrollDown

Lovely, now that we can move around the explorer, the next step is to preview a file content without opening it and losing focus of the explorer. This is helpful when we are unsure of the content of the files of a project. The command VSCode exposes for us to do this is the filesExplorer.openFilePreserveFocus, which is bound to Space by default.

However, we sometimes need to open a file and immediately switch focus to start working on such a file.

The explorer.openAndPassFocus command opens the focused file on the explorer and switches focus to the editor. This command is bound to Cmd+DownArrow by default, but we removed that binding earlier in this section. It is up to you to configure this keybinding in a way that makes the most sense, but I like using Cmd+Enter for this action.

Similarly, we can open a file in a new editor group using the explorer.openToSide command defaulted to Ctrl+Enter.

That's all we need to know about opening files to be effective with the keyboard.

The big missing part is creating, renaming, deleting, and moving files and folders. Let's start with creation.

We can use the explorer.newFile command to create a new file on the focused folder. This command is unbound by default, so I have reassigned it to Option+Cmd+N.

Of course, sometimes we just want to create a folder where we can drop files later. The command that enables folder creation is the explorer.newFolder command. This command is unbound by default. You can use whatever makes sense to you. I got accustomed to using Cmd+N+F.

Files and folders can get created and also get destroyed. We can use the moveFileToTrash command to delete a file or folder. This command is bound to Cmd+Backspace by default.

You might notice that when deleting a file or folder in your IDE, you will be prompted to confirm the action. I have checked the not ask again option, and that's why the prompt is not showing on the video.

Excellent, creating and deleting files are prevalent tasks; it is great we covered them, but sometimes we don't want to delete a file. We just want to rename it. The explorer.rename command will allow us to rename a file or folder. This command is bound to Enter by default.

That's superb. To complete this section, we must cover how to move and copy files and folders.

Copying a file or folder is as simple as using the filesExplorer.copy command. This command is bound to Cmd+C as you would expect to do in Finder. But copying is just the first half of the equation; we also need to paste. The filesExplorer.paste command will allow us to paste the copied file or folder. This command is bound to Cmd+V by default.

Although there are different ways of moving a file, the easiest and more intuitive way is similar to copying and pasting.

You might imagine how by now. You are right, the old cutting and pasting. We can use the filesExplorer.cut command to cut a file. This command is bound to Cmd+X by default. And the paste command is the same one we already saw.

And this closes the cycle. Using the keyboard, we can now create, rename, delete, move and copy files and folders. There might be better ways of achieving the same results, let me know on Twitter what you find, but this gives us a good starting point and free us from the mouse.

Search

Let's take a moment to appreciate the road covered so far. I could say that at this moment, we could spend 95% of our time in VSCode using the keyboard.

This final module would even improve on that number. We are going to learn about the search functionality of VSCode.

I don't remember a day that has passed without me performing a global search in VSCode. This feature allows us to perform a filter-rich text search across all the files in a project.

The first thing to do is open the search view. The command that does this is the workbench.action.findInFiles command. This command is bound to Cmd+Shift+F by default. Once the search input is focused, we can start typing our search query.

This is exciting, but we need to be able to move around the search results. There are different ways to achieve this, but the easiest is using the search.action.openResult command. This command is bound to Cmd+DownArrow by default, and will move the focus to the search results list. You will notice that iterating over the search results is very similar to iterating over the explorer nodes, with the difference that the files will preview automatically. To open the focused search result and move the focus to the editor, use the search.action.openResult bound to Enter by default.

Fantastic, that's all we need to solve the most significant part of our search needs. But we can do some other things with the search view that are worth mentioning. Are you ready for something special?

It is a secret; I need you to trust me for a second. First, go to your keybindings configuration and set the search.action.openNewEditor to the command you prefer. I'm using Cmd+Shift+f replacing the workbench.action.findInFiles and workbench.view.search.focus set to that keybinding by default.

Ready? Let's give it a try.

You might ask yourself: "What is that, and how does it work?" The why is Search Editors, a feature that was added to VSCode in version 1.43, that's February of 2020. Crazy, right, that was there all this time, and nobody knew. Well, maybe some people knew, but I didn't. It works by opening the global search results in a full-sized editor, allowing us to use all the tricks we learned so far to move our cursor around a file, but in this case, that file contains the search results.

Let's open our editor again and use relative lines goto move to place the cursor over the desired search result.

Then we can use the editor.action.revealDefinition command to open the result file. This command is bound to Cmd+Enter as seen before.

For the results "Go to definition" command to work, you might need to remove the keybinding for search.action.openInEditor or change it to something different.

Among the actions, I use the most with the search is the search.action.focusQueryEditorWidget command, which would take the focus back to the search input and is bound to Esc by default. The search.action.focusNextSearchResult will show us to move the focus to the following search result, which is bound to F4 by default, although I like to bind it to Cmd+Option+Enter. And the search.action.focusPreviousSearchResult will move the focus to the previous search result, and it is bound to Shift+F4 by default, but I modify it to Shift+Cmd+Option+Enter.

To delete a search result from the IDE we use search.searchEditor.action.deleteFileResults command. This command is bound to Cmd+Shift+Backspace by default, and it is handy to remove results that are not relevant anymore.

The last two commands I want to mention are the toggleSearchEditorCaseSensitive and toggleSearchEditorWholeWord commands. These commands are bound to Cmd+Option+C and Cmd+Option+W by default and will toggle the search's case-sensitive and whole word options.

And that's all we will cover in this article, but there is a lot more. For example, as seen we the case sensitive and whole word options, we could also toggle the regex mode. I recommend you also play with the Search Editor: Apply changes Extension that persists the modifications made to the search results visible code in the original files.

Conclusions

The road to achieving keyboard proficiency in VSCode starts with you. What we have covered in this article is necessary to escape the tyranny of the mouse in the most common scenarios. However, there is still much to learn and master inside VSCode. More than that, VSCode itself will show you its limitations with time if you push hard enough. Luckily, we, as developers, can extend VSCode behavior and create our own extensions to bypass these limitations. Nevertheless, if you are truly passionate about becoming a keyboard wizard, I encourage you to explore other IDE like the Vim family.

I hope this helped.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Nacho Vazquez

Front-end architect, tech writer, meetup speaker, scuba diving lover. Passionate about Software architecture and sharing knowledge.

@nacho_vazquez14 @NachoVazquez

Web Scraping with Deno

Maybe you've had this problem before: you need data from a website, but there isn't a good way to download a CSV or hit an API to get it. In these situations, you may be forced to write a web scraper. A web scraper is a script that downloads the HTML from a website as though it were a normal user, and then it parses that HTML to extract information from it. JavaScript is a natural choice for writing your web scraper, as it's the language of the web and natively understands the DOM. And with TypeScript, it is even better, as the type system helps you navigate the trickiness of HTMLCollections and Element types. You can write your TypeScript scraper as a Node script, but this has some limitations. TypeScript support isn't native to Node. Node also doesn't support web APIs very well, only recently implementing fetch for example. Making your scraper in Node is, to be frank, a bit of a pain. But there's an alternative way to write your scraper in TypeScript: Deno! Deno is a newer JavaScript/TypeScript runtime, co-created by one of Node's creators, Ryan Dahl. Deno has native support for TypeScript, and it supports web APIs out of the box. With Deno, we can write a web scraper in TypeScript with far fewer dependencies and boilerplate than what you'd need in order to write the same thing in Node. In this blog, we’re going to build a web scraper using Deno. Along the way, we’ll also explore some of the key advantages of Deno, as well as some differences to be aware of if you’re coming from writing code exclusively for Node. Getting Started First, you'll need to install Deno. Depending on your operating system, there are many methods to install it locally. After installation, we'll set up our project. We'll keep things simple and start with an empty directory. ` Now, let's add some configuration. I like to keep my code consistent with linters (e.g. ESLint) and formatters (e.g. Prettier). But Deno doesn't need ESLint or Prettier. It handles linting and formatting itself. You can set up your preferences for how to lint and format your code in a deno.json file. Check out this example: ` You can then lint and format your Deno project with deno lint and deno fmt, respectively. If you're like me, you like your editor to handle linting and formatting on save. So once Deno is installed, and your linting/formatting options are configured, you'll want to set up your development environment too. I use Visual Studio Code with the Deno extension. Once installed, I let VS Code know that I'm in a Deno project and that I'd like to auto-format by adding a .vscode/settings.json file with the following contents: ` Writing a Web Scraper With Deno installed and a project directory ready to go, let's write our web scraper! And what shall we scrape? Let's scrape the list of Deno 3rd party modules from the official documentation site. Our script will pull the top 60 Deno modules listed, and output them to a JSON file. For this example, we'll only need one script. I'll name it index.ts for simplicity's sake. Inside our script, we'll create three functions: sleep, getModules and getModule. The first will give us a way to easily wait between fetches. This will prevent issues with our script, and the owners of the website we’ll contact, because it's unkind to flood a website with many successive requests. This type of automation could appear like a Denial of Service (DoS) attack, and could cause the API owners to ban your IP address from contacting it. The sleep function is fully implemented in the code block below. The second function (getModules) will scrape the first three pages of the Deno 3rd party modules list, and the third (getModule) will scrape the details for each individual module. ` Scraping the Modules List First, let's write our getModules function. This function will scrape the first three pages of the Deno 3rd party modules list. Deno supports the fetch API, so we can use that to make our requests. We'll also use the deno_dom module to parse the HTML response into a DOM tree that we can traverse. Two things we'll want to do upfront: let's import the deno_dom parsing module, and create a type for the data we're trying to scrape. ` Next, we'll set up our initial fetch and data parsing: ` Now that we're able to grab the contents of the first three pages of Deno modules, we need to parse the document to get the list of modules we want to collect information for. Then, once we've got the URL of the modules, we'll want to scrape their individual module pages with getModule. Passing the text of the page to the DOMParser from deno_dom, you can extract information using the same APIs you'd use in the browser like querySelector and getElementsByTagName. To figure out what to select for, you can use your browser's developer tools to inspect the page, and find selectors for elements you want to select. For example, in Chrome DevTools, you can right-click on an element and select "Copy > Copy selector" to get the selector for that element. ` Scraping a Single Module Next we'll write getModule. This function will scrape a single Deno module page, and give us information about it. If you're following along so far, you might've noticed that the paths we got from the directory of modules look like this: ` But if you navigate to that page in the browser, the URL looks like this: ` Deno uses redirects to send you to the latest version of a module. We'll need to follow those redirects to get the correct URL for the module page. We can do that with the redirect: 'follow' option in the fetch call. We'll also need to set the Accept header to text/html, or else we'll get a 404. ` Now we'll parse the module data, just like we did with the directory of modules. ` Writing Our Data to a File Finally, we'll write our data to a file. We'll use the Deno.writeTextFile API to write our data to a file called output.json. ` Lastly, we just need to invoke our getModules function to start the process. ` Running Our Script Deno has some security features built into it that prevent it from doing things like accessing the file system or the network without granting it explicit permission. We give it these permissions by passing the --allow-net and --allow-write flags to our script when we run the script. ` After we let our script run (which, if you've wisely set a small delay with each request, will take some time), we'll have a new output.json file with data like this: ` Putting It All Together Tada! A quick and easy way to get data from websites using Deno and our favorite JavaScript browser APIs. You can view the entire script in one piece on GitHub. In this blog, you've gotten a basic intro to how to use Deno in lieu of Node for simple scripts, and have seen a few of the key differences. If you want to dive deeper into Deno, start with the official documentation. And when you're ready for more, check out the resources available from This Dot Labs at deno.framework.dev, and our Deno backend starter app at starter.dev!...

Mar 24, 2023

6 mins

DenoVSCodeTipsTypeScript

Deep Dive into Node.js with James Snell

Node.js is one of the most used engines globally, and it is unique in the approach it follows to make our code work. As developers, we usually ignore how the underlying tools we use in daily work. In this article, we will deep dive into the Node.js internals using James Snell's talk as our guide, but we will expand in some areas to clarify some of the concepts discussed. We will learn about the Event Loop and the asynchronous model of Node.js. We will understand Event Emitters and how they power almost everything inside Node, and then we will build on that knowledge to understand what Streams are, and how they work. Event Loop We will begin our journey inside Node.js by exploring the Event Loop. The Event Loop is one of the most critical aspects of Node.js to understand. The Event Loop is the big orchestrator- the mechanism in charge of scheduling Node.js' synchronous and asynchronous nature. This section teaches how everything related to the scheduling mechanism works. When the Node.js process begins, it starts multiple threads: the Main process thread and the Libuv pool threads with four worker threads by default. The Libuv thread concern is handling heavy load work like IO by reading files from the disc, running some encryption, or reading from a socket. We can see the Event Loop as a glorified for/while loop that lives inside the main thread. The loop process happens at the C++ level. The Event Loop must perform several steps to complete a full back-around iteration. These steps will involve performing different checks and listening to OS events, like checking if there are any timers expired that need to be fired. It will check if there is any pending IO to process or schedule. These tasks run at the C++ level, but the event associated with the steps usually involves a callback like the action to execute when a timer expires, or a new chunk of a file is ready to be processed. When this happens, the callback executes in Javascript. Because the event loop exists in the process main thread, every time one of the steps of the event loop is processed, the event loop and the main thread are blocked until that step completes. This means that even if the Libuv is still executing the IO operations while the main thread is completing one-step tasks, the result of the IO operations is not accessible until the main thread is unblocked and iterates to the step that handles that result. "There is no such thing as asynchronous Javascript" James Snell But if asynchronous doesn't exist in Node and Javascript. What are promises for? Promises are just a mechanism to defer processing to the future. The power of Promises is the ability to schedule code execution after a specific set of events happens. But we will learn more about Promises later in this article. Step Execution Now that we understand the event loop high-level picture, it is time to go one level deeper and understand what happens in each step of the Event Loop. We learned that each step of the event loop executes in C++, but what happens if that step needs to run some Javascript? The C++ step code will use the V8 APIs to execute the passed Javascript code in a synchronous call. That Javascript code could have calls to a Node API named process.nextTick(fn), which receives another function as an argument. > "nextTick is not a good name because no tick is involved." James Snell If present, the process.nextTick(fn) appends its argument function in queue data structure. Later, we will find that there is a second queue where the Javascript code can append functions. But for simplicity, let's assume for now that there is only one queue: the nextTick queue. Once the Javascript runs and completes filling the queue through the process.nextTick method, it will return control to the C++ layer. Now it is time for Node to drain the nextTick Queue synchronously, in the order they were added, by running each of the functions added to the nextTick queue. Only when the queue is empty can the event loop move to the next step and start again with the same process. Remember everything described before runs asynchronously. > "Any time you have Javascript running, anything else is happening" James Snell Therefore, the key to keeping your Javascript performant is to keep your functions small, and use a scheduling mechanism to defer work. But what is the scheduling mechanism? The scheduling mechanisms are the instruments through which Node.js can simulate asynchronicity by scheduling the execution of a given Javascript function to a given time in the future. The scheduling mechanisms are the nextTick queue and the Microtask queue. The difference between these two is the order in which they execute. NodeJS will only start draining the Microtasks queue after the nextTick queue is empty. And the nextTick queue after the call stack is empty. The call stack is a LIFO (Last In, First Out) stack data structure. The operations from the stack are completely synchronous and are scheduled to run ASAP. The v8 API that we saw before runs the Javascript code sent from the C++ layer by adding and removing the statements into the stack, and executing them as corresponding. We saw how the nextTick queue is filled by the V8 execution when processing one statement from the stack, and how it drains as soon as C++ processes the Javascript stack. The Microtask queue is the one that process Promises continuation like events, catches, and finallies in V8. It is drained immediately after the nextTick queue is empty. Let's paint a picture of how this works. The following represents a function body executing several tasks. ` But the final order in which Node will execute this code looks more like ` Notice how nextTick is processed after the stack of operations is emptied, and the Microstask operations (the promise continuations) are deferred to just after the nextTick queue is emptied. However, there are other scheduling mechanisms: - Timers like setTimeout, setInterval, etc - Inmediates, the execution order of which is combined with timers, but they are not timers. A setInmediate(fn) registers a callback that will execute at the end of the current event loop turn, or just before the next event loop turn starts. - Promises, which are not the same as promises event continuation, which is what the Microstask handles. - Callbacks on the native layers this is something that is not necessarily available to the javascript developer. - Workers threads are separate node instances with their own process main thread, their own Libuv threads, and their own event loop. It is basically a complete Node instance running in a separate thread. Because it is a separate Node instance, it can run Javascript Node in parallel to the main Node instance. > "NextTick and Immediate names should be inverted because NextTick operations happen immediately after the Javascript stack is empty and Immediate functions will happen just before the nextTick start." To find complementary resources, you can go to the Node.js documentation. Event Emitter Event emitters are one of the first Node APIs ever created. Almost everything in Node is an event emitter. It is the first thing that loads and is fundamental to how Node works. If you see an object with the following methods, you have an event emitter. ` But how do these work? Inside the event emitter object, we have a map/look-up table, which is just another object. Inside each map entry, the key is the event name, and the value is an array of callback functions. The on method on the event emitter object receives the event name as the first argument, and a callback function as its second. When called, this method adds the on callback function into the corresponding array of the look-up table. The once method behaves like the on method, but with a key difference; instead of storing the once callback function directly, it will wrap it inside another function, and then add the wrapped function to the array. When the wrapper function gets executed, it will execute the wrapped callback function, removing itself from the array. On the other hand, emit uses the event name to access the corresponding array. It will create a backup copy of the array, and iterate synchronously over each callback function of the array executing it. It is important to highlight that emit is synchronous. If any of the callback functions on the array take a long time to execute, the main thread will be blocked. Emit won't return until all of functions on the array have executed. The asynchronous behavior of the emit is an illusion. This effect is caused because internally, Node will invoke each callback function using a nextTick, and therefore deferring the function's execution into the future. You can find more info about Event Emitter at the Node.js documentation. Streams (Node | Web) Streams are one of the fundamental concepts that power Node.js applications. They are a way to handle reading/writing files, network communications, or any end-to-end information exchange efficiently. Streams are not a concept unique to Node.js. They were introduced in the Unix operating system decades ago, and programs can interact with each other by passing streams through the pipe operator (|). For example, traditionally, when you tell the program to read a file, it is read into memory, from start to finish, and then you process it. You read it piece by piece using streams, processing its content without keeping it all in memory. The Node.js stream module provides the foundation upon which all streaming APIs are built. All streams are instances of EventEmitter. Node Streams There are four Node stream types: Readable, Writable, Duplex, and Transform. All of them are Event Emitters. Readable: a stream you can pipe from but not pipe into (you can receive data, but not send data to it). When you push data into a readable stream, it is buffered until a consumer starts to read the data. Writable: a stream you can pipe into but not pipe from (you can send data but not receive from it). Duplex: a stream you can both pipe into and pipe from. Basically a combination of a Readable and Writable stream. Transform: a Transform stream is similar to a Duplex, but the output is a transform of its input. Readable Stream The Readable stream works through a queue and the highwatermark in an oversimplified way. The highwatermark will delimit how much data can be in the queue, but the Readable Stream will not enforce that limit. Every time data is pushed into the queue, the stream will give feedback to the client code, telling if the highwatermark was reached or not, and transferring the responsibility to the client. The client code must decide if it continues pushing data and overflowing the queue. This feedback is received through the push method, which is the mechanism for pushing data into the queue. If the push method returns true, the highwatermark has not been reached, and you can push more. If the push method returns false that means that the highwatermark has been reached, and you are not supposed to push more, but you can. Events When data has been pushed into the queue, the internal of the Readable Stream will emit a couple of events. The on:readable is part of the pull model; it alerts that this stream is readable and has data to be read. If you are listening to the on:readable event, a read method can be called. When the client code calls the read() method, it will get a chunk of data out of the queue, and it will dequeue it. Then, the client code can keep calling read until there is no more data in the queue. After emptying the queue, the client code can restart pulling data when the on:readable event triggers again. The on:read event is part of the push model. In this event, any new chunk of data that is pushed using the push method will be synchronously sent to its listeners. That means we don't need to call the read method. The data will arrive automatically. However, there is another crucial difference; the sent data will never be stored in the queue. The queue is only filled when there is no active on:read event listener. This is called the "flow" mode because the data just flows, and it doesn't get stored. Other events are the end event that would notice that there is no more data to be consumed from the stream. The 'close' event is emitted when the stream and any underlying resources (a file descriptor, for example) have been closed. The event indicates that no more events will be emitted, and no further computation will occur. The 'error' event may be emitted by a Readable implementation. Typically, this may occur if the underlying stream cannot generate data due to an underlying internal failure or when a stream implementation attempts to push an invalid chunk of data. The key to understanding the Readable Streams and their events is that the Readable Streams are just Event Emitters. Like Event Emitters, the Readable Streams don't have anything built into it that is asynchronous. It will not call any of the scheduling mechanisms. Therefore they operate purely synchronously, and to obtain an asynchronous behavior, the client code needs to defer when to call the different event APIs like the read() and push() methods. Let's understand how! When creating a Readable Stream, we need to provide a read function. The stream will repeatedly call this read function as long as its buffer is not full; however, after it calls it once, it will wait until we call push before calling it again. If we synchronously call push after the Readable Stream called read and the buffer is not full, the stream will synchronously call read again, up until we call push(null), marking the end of the stream. Otherwise, we can defer the push calls to some other point in time, effectively making the Stream read calls operate asynchronously; we might, for example, wait for some File IO callback to return. Examples Creating a Readable Stream ` ` Using a Readable Stream ` Writable Stream The Writable Streams works similarly. When creating a Writable Stream, we need to provide a _write(chunk, encoding, callback) function, and it will be an external write(chunck) function. When the external write function is called, it will just call the internal _write function. The internal _write function must call its callback argument function. Let's imagine that we write ten chunks; when the first chunk is written, if the internal _write function doesn't invoke the callback function, what will happen is that the chunks will accumulate in the Writable Stream internal buffer. When the callback is invoked, it will grab the next chunk and write it, draining the buffer. This means that if the _write is calling the callback function synchronously, then all those writes will happen synchronously; if it is deferring invoking that callback, then all those calls will happen asynchronously, but the data will accumulate in the internal buffer up until the highwatermark is hit. Even then, you can decide to keep incrementation the buffer queue. Events Like the Readable Stream, the Writable Stream is an Event Emitter that will provide its events listeners with useful alerts. The on:drain event notifies that the Writable buffer is longer, and more writes are allowed. If a call to the write function returns false, indicating backpressure, the 'drain' event will be emitted when it is appropriate to resume writing data to the stream. The 'close' event is emitted when the stream and any underlying resources (a file descriptor, for example) have been closed. The event indicates that no more events will be emitted, and no further computation will occur. The 'error' event is emitted if an error occurs while writing or piping data. The listener callback is passed a single Error argument when called. The 'finish' event is emitted after the stream.end() method has been called, and all data has been flushed to the underlying system. Examples Creating a Writable Stream ` Duplex Stream Duplex streams are streams that implement both the Readable and Writable interfaces. We can see a Duplex stream as an object containing both a Readable Stream and a Writable Stream. These two internal objects are not connected, and each has independent buffers. They share some events; for example, when the close event emits, both Streams are closed. They still emit the stream type-specific events like the readable and read for the Readable Stream, or the drain for the Writable Stream independently. However, this doesn't mean that data will be available on the Readable stream if we write into the Writable Stream. Those are independent. Duplex streams are especially useful for Sockets. Transform Stream Transform streams are Duplex streams where the output is related to the input. Contrary to the Duplex streams, when we write some chunk of data into the Writable stream, that data will be passed to the Readable stream by calling a transform function and invoking the push method on the readable side with the transformed data. As with Duplex, both the Readable and the Writable sides will have independent buffers with their own highwatermark. Examples Creating a Transform Stream ` Web Streams In Web streams, we still see some of the concepts we have seen for Node Streams. There exist the Readable, Writable, Duplex, and Transform streams. However, they also have significant differences. Unlike Node streams, web streams are not Event Emitter-based but Promise-based. Another big difference is that Node streams support multiple event listeners at the same time, and each of those listeners will get a copy of the data, while Web streams are restricted to a single listener at a time, and it has no events in it; it is purely Promise-based. While Node streams work entirely synchronously because Web streams are Promise-based, they work entirely asynchronously. This happens because the continuation is always deferred to the MicroTasks queue. It is essential to highlight that Node streams are significantly faster than Web streams, while Web streams are much more portable than Node streams. So keep that in mind when you are planning to select one or the other. Readable stream To understand the underlying implementation of how this works, let's take the Readable stream and dissect it. The developer can pass the underlayingSource object to the constructor when creating a new Readable stream. We can define the pull(controller) function inside this object, which receives the Controller object as its first and only parameter. This is the function where the client code can push the data into the stream by defining a custom data pulling logic. The Controller object, argument of the pull() function, contains the enqueue() function. This is the equivalent to the Node Readable stream push() function, and it is used to push the callback function return data into the Readable stream. The reader object, is the element through which the Web Readable stream enforces a single listener or reader at the time. It can be accessed through the getReader() method of the stream. Inside the reader object, we can find the read() function, which returns a promise providing access to the next chunk in the stream's internal queue. When the client code of the stream calls read() from the reader object, this will look into the Controller data queue and check if there is any data. If there is data in the queue, it will only dequeue the first chunk of data from the queue and resolve the read promise. If there is no data in the queue, the stream is going to call the pull(controller) function defined in the stream constructor argument object. Then the pull(controller) function will run and as part of its execution, it will call the Controller function enqueue() to push data into the stream. After pushing the data in, the pull function will resolve the initial read() Promise with the data pushed in. Because the pull(controller) function can be an async function, and return a Promise, if it calls once and that Promise is not resolved yet, and the client code continues calling the read() function, those read promises are going to accumulate in a read queue. Now we have our data queue and the read queue, and every time a new data is enqueued into the data queue, the stream logic will check if there is some pending read promise in the read queue. If the read queue is not empty, the first pending Promise will be dequeued and resolved with the data enqueued in the data queue. We can see this process as the read queue and the data queue trying to balance each other out. Consequently, the read queue will not accumulate read promises if the data queue has data. And the opposite is also true; we will not accumulate data in the data queue if the read queue has unresolved promises. Example Creating a readable stream ` Conclusions There is immense beauty in the depths for those curious developers who are not afraid of diving into the deep waters of the Node.js inner mechanics. In this article, we barely start exploring some of the solutions chosen by the Node.js core contributors, and we have found how elegant and straightforward many of those solutions are. There is still much to learn about the internals of Node and the Browser engines, but I think this article and its companion Javascript Marathon are a great starting point. If you get here, thank you, and I hope you got inspired to continue digging into the tools that allow us to unleash our passion and creativity....

May 24, 2022

16 mins

NodeJS

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

Rob Ocel and Jerome Hardaway continue their series on AI adoption by exploring the world of AI, focusing on small language models (SLMs) and large language models (LLMs). They compare the unique capabilities of SLMs against the vast knowledge encompassed by LLMs, and highlight the transformative potential of AI in driving creativity, problem-solving, and user-centric design in technology. SLMs are designed to excel at specific tasks, offering faster processing and cost-effectiveness due to their open-source nature. These models have proven to be invaluable in sectors like finance, where data security is of utmost importance. By leveraging SLMs, organizations can enhance their security measures and protect sensitive information. Moreover, SLMs provide a stepping stone for engineers to adapt to new technologies and incorporate AI into their work, ultimately improving user experiences. On the other hand, LLMs encompass a wide range of knowledge, making them incredibly versatile. These models have the potential to transform industries by providing insights, predictions, and solutions to complex problems. With advancements in AI chip technology by tech giants like Apple, Nvidia, Google, and Meta, LLMs are becoming even more powerful and efficient. Evaluating AI models based on factors like stability and industry support is crucial to harnessing the full potential of LLMs. The conversation also addresses some ethical questions related to AI implementation. While AI brings numerous benefits, concerns about job displacement cannot be ignored. As AI continues to evolve, it is essential to strike a balance between automation and human involvement. Engineers must focus on improving AI sophistication and seamless integration into user interactions, ensuring that AI enhances human capabilities rather than replacing them. Additionally, ethical guidelines and regulations must be established to address potential biases and ensure responsible AI implementation. Download this episode here....

Apr 23, 2024

2 mins

Engineering Leadership

Introduction

The Keyboard Shortcuts Editor

Movements

Single unit cursor movement -- Arrow Keys

Horizontal Movement. Word cursor movement

Horizontal Movement. Line start/end cursor movement

Horizontal Movement. Bonus and Sneak Peek

Vertical Movement. Lines cursor movement

Vertical Movement. Top and Bottom of the file

Vertical Movement. Go to Line

Vertical Movement. Go to relative line

Hydration Pause -- Selection

Vertical Movement. Scrolling Editor

Multiple Groups Movement

Code Interactions

Quick Fix

Hover and Peek

Context Menu

Refactor

Go to Definition

Go Back and Go Forward

Folding regions

Deleting Code

Moving and Cloning lines

Multiple Cursors

Insert cursor on next line

Selecting next occurrence

Cursor Undo

Main Sidebar Tools

Explorer

Search

Conclusions

Nacho Vazquez

Web Scraping with Deno

Deep Dive into Node.js with James Snell

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

Web Scraping with Deno

Deep Dive into Node.js with James Snell

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel