Category Archives: software development

VS Code: I cannot quite figure out how to search and replace in a selection

Gosh, search and replace in a selection of text in VS Code drives me nuts.

I can’t even describe how exactly it does so, but it works against my intuition.

It’s funny how in 2019 we haven’t quite settled on UX for that!

For me, it’s super hard to grasp how this (search and replace in a selection of text) is supposed to work in VS Code, as in: how would the people who designed this part of the product like me to use it? Which workflow did they have in mind? I don’t seem to understand the magic behind it. I often seem to end up replacing things in the entire document as opposed to in the selection that I just carefully created a second before. All I can conclude so far is that trial and error don’t seem to get me far :-).

Trying to understand the behavior based on docs and reading GitHub issues then reveals that this thing is complex, that it can be configured with a number of special configuration options, and that many users experience WTF moments on a daily basis. Users keep posting videos and GIFs of their weird experiences (thanks!). Two of these WTF moments are well captured in the GIFs in this comment: (from October 2019).

I can say that search and replace in a selection of text works much better, so much more intuitively, in Sublime Text 3 (by default).

In VS Code it turned out that setting editor.find.autoFindInSelection to true helps me quite a bit towards getting more predictable outcomes.

Feel free to leave a comment below if you have an anecdotal opinion about all this.

If you’d like to read along, I find these issues pretty entertaining:

I particularly agree with this statement from November 2019:

I appreciate all the work and attention that has gone into this, but I don’t think I will ever be truly comfortable with Find/Replace in VS Code. The issue for me is that the “find in selection” button looks and feels like a toggle switch, not a trigger (or “fire button”).

If you flip a toggle switch from one position to the other, and then back to the original position, it should be as though you had never flipped the switch at all. With this mental model, it is always a shock and a disappointment when flipping the switch irreversibly destroys my carefully crafted manual selection.




Bulma: sticky footer (flexbox solution)

Bulma is nice. I was looking for a way to get a sticky footer, though. Like many others, I was a little surprised that it’s not built-in:

It’s of course doable. I have created a demo / minimal working example based on the solution proposed here.

<!DOCTYPE html>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Footer at the bottom / sticky footer</title>
    <style type="text/css" media="screen">
      body {
        display: flex;
        min-height: 100vh;
        flex-direction: column;
      #wrapper {
        flex: 1;
    <div id="wrapper">
      <section class="hero is-medium is-primary is-bold">
        <div class="hero-body">
          <div class="container">
            <h1 class="title">
              The footer is at the bottom. Seriously. 🦠
            <h2 class="subtitle">
              By <a href="">Jan-Philip Gehrcke</a>
    <footer class="footer">
      <div class="content has-text-centered">
          I am down here.

I posted this in the GH thread, too:

GitHub: Y? Y!

I am not the type of person who remembers shortcuts/hotkeys. Only few valuable ones stick. Those that pass the test of time.

Before I share a GitHub link pointing to code I press y. This might be one of the most important hotkeys of my day-to-day work. And I would love to see more of you people out there doing that, too!

It makes the URL in the location bar point to the specific revision of the code you are looking at, as opposed to the head of the current branch (which often is master).

You have two options:

  1. Select the line of code, press y, copy the URL, share it (for example in a GitHub comment). In the future, that URL will either stop working or point to the file, line or code section you actually wanted to refer to. Either this or that. No room for misleading moving target effects (well, malicious intent excluded, but even that is hopefully close to impossible). It is quite likely that even after years the comment, prose, article or chat log in which you used that URL is still going to be perfectly meaningful. How cool is that?
  2. Select the line of code, copy the URL, share it. Lucky you, you have just saved yourself some work (did not press y). But: The URL you have just shared is quite likely to point to a moving target. In a busy project in a busy file, it might only take a day and it will not refer to quite the right thing anymore. On longer time scales it gets worse. Once you put this into a public GitHub comment, email, forum post or chat then your content might first start to look subtly wrong, and then very wrong in the far future. Especially in the spectrum in between not all future readers might realize what actually happened. That can be quite misleading.

Choose for yourself :-).

Given the role into which GitHub has evolved for how we do software engineering these days, I think it is pretty important to spread this. Tell your peeps!

Reference: Getting permanent links to files in the GitHub docs.