Yeah it’s probably impossible to get a perfect diff in every case, but that’s irrelevant in the same way that the halting problem is true yet formal verification still exists. We don’t need perfect, we need “good most of the time”.

For example the “slider” problem has existed in Git forever, and apparently there are algorithms that mostly solve it (indent-new), yet Git still doesn’t use them. That repo is 9 years old. I can’t remember what led me to that but I think it was one of the new VCS’s saying they do well on that benchmark (can’t find any reference to it now though).

Pijul should also give better diffs in theory because it actually tracks lines as objects, so it has more information to work with. In the first example in diff-slider-tools it would know the difference between /* and /*. I haven’t actually tried it though.

There are also a few semantic diffing tools that understand syntax that could be integrated - notably Difftastic and Diffsitter.

Point is, it could easily be better than it is.

Yeah even though it definitely has flaws (awful CLI, dumb diff/conflict algorithms) and half-arsed parts (submodules, LFS), it really is pretty great software.

Still, I’m hopeful for the next generation VCS’s - Pijul, Sapling and Jujutsu.

I’m all for JSON configuration for really low-down dirty stuff, but for something as simple as this? Eugh, no!

I totally agree. But it’s difficult to see why that would be a deal breaker tbh. It still works… and Python is too shit to use for the kinds of stuff you just have a single “run” for anyway (e.g. desktop apps or games).

You can do it in launch.json. In fairness it easily the weakest part of VSCode - I wouldn’t call editing JSON “comfortable”. I tend to just use the integrated terminal instead.

I think the bigger argument for Pycharm is refactoring. VSCode still has fairly weak support for refactoring, whereas in IntelliJ you can move classes and methods around, extract functions etc and it all works quickly and reliably (in Java at least; I dunno about Pycharm - Python is trash so it might not be possible to do refactoring reliably).

Really? I find Pylance to be great. Pretty quick error checking, Pyright is fairly sound, and auto-complete/go-to-definition work reliable. When you have types of course - the biggest problems with Python development are still the communities disinterest in type hints, and the godawful tooling.

Obviously Codium also wouldn’t exist without VSCode.

Google does basically the same with Android. It’s the standard way of locking you into a free “open” standard platform.

Definitely annoying but IMO the trade-off is worth it. Would you rather VSCode didn’t exist at all? Because that’s the alternative.

IMO if you’re doing something that complex you shouldn’t be using sed, but yeah you can probably do this something like:

while read REGEX; do
  sed "$REGEX" << EOF
your test string
EOF
done <list_of_regexes.txt

I strongly recommend you don’t do that though. It will be absolutely full of quoting bugs. Instead write a script in a proper language to do it. I recommend Deno, or maybe even Rust.

If you use Rust you can also use RegexSet which will be much faster (if you just want to find matches anyway). Here’s what ChatGPT made me. Not tested but it looks vaguely right.

use regex::RegexSet;
use std::fs::File;
use std::io::{self, BufRead};
use std::path::Path;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Define the fixed input string
    let input_string = "This is a test string for regex matching.";

    // Path to the file containing the regexes
    let regex_file_path = "regexes.txt";

    // Read regexes from the file
    let regexes = read_lines(regex_file_path)?
        .filter_map(Result::ok) // Filter out errors
        .collect::<Vec<String>>();

    // Create a RegexSet from the regexes
    let regex_set = RegexSet::new(&regexes)?;

    // Find the regexes that match the input string
    let matches: Vec<_> = regex_set.matches(input_string).into_iter().collect();

    // Print the matches
    if matches.is_empty() {
        println!("No regexes matched the input string.");
    } else {
        println!("Regexes that matched the input string:");
        for index in matches {
            println!(" - {}", regexes[index]);
        }
    }

    Ok(())
}

// Helper function to read lines from a file
fn read_lines<P>(filename: P) -> io::Result<io::Lines<io::BufReader<File>>>
where
    P: AsRef<Path>,
{
    let file = File::open(filename)?;
    Ok(io::BufReader::new(file).lines())
}

https://github.com/microsoft/vscode/issues/205125

Also I found this duplicate: https://github.com/microsoft/vscode/issues/211508

There’s probably more…

They’ve been doing that for about the last 6 releases. I wish they’d fix some of the long-standing annoying bugs like the fact that you can’t respect .gitignore and search in a subdirectory at the same time. Or the fact that you can’t stage a submodule unless you also have that submodule open.

Or how about a less annoying way to configure Run/Debug than launch.json?

Still, can’t complain. It’s mostly free and still very good overall. I’ll definitely be watching Zed… but maybe not too closely until it supports opening large files.

I used to use Git stash but I found in the end I found just making “real” commits was better.

I’ve tried this. Unfortunately it isn’t anywhere near as good as Git Graph, or at least it wasn’t when I tried it a few months ago. I’ll stick with Git Graph until it stops working I think.

I haven’t actually used this site (found it after I already learnt Git), but it gets posted a lot, and one issue I feel like it has is it shows you the Git graph using a tool that you have to immediately throw away after you’ve finished this tutorial.

I think it would be better if it had an actual real Git tool shown. I would say VSCode’s Git Graph extension would be ideal but unfortunately it has a stupid license.

Not many people back up continuously, so this is still useful.

Well yeah I think the point is you’re human and you might make a mistake.

It is slightly surprising no? I can’t see any real reason for it to record this information.

That said, your rough timezone is probably going to leak just from the fact that people generally don’t make commits in the middle of the night. If you want HN paranoia levels of anonymity you need to schedule your commits to be automatically pushed at exactly midnight UTC every day.

I’m pretty senior, having been in the industry for some time, so I tend not to be asking the questions that will have a million examples out there

Me too, but this was C++ where there isn’t a strong culture of making high quality libraries available for everything (because it doesn’t have a proper package manager, at least until very recently), so you do end up having to reinvent the wheel a fair bit.

And sometimes you just need things a bit different to what other people have done. So even though there are a gazillion expression parsers out there (so the LLM understood it pretty well) there are hardly any that support 64-bit integers. But that’s a small enough difference that it can deal with it.

It really depends on the domain. E.g. I wrote a parser and copilot was tremendously useful, presumably because there are a gazillion examples on the internet.

Another case where it saved me literally hours was spawning a subprocess in C++ and capturing stdin/out. It didn’t get it 100% right but it saved me so much time looking up how to do it and the names of functions etc.

Today I’m trying to write a custom image format, and it is pretty useless for that task, presumably because nobody else has done it before.

Well this isn’t a standard library either then. But seeing as it is literally called that I’d say your unusually restrictive definition is nonsense.

Yeah in order to access native features that Node supports and you can’t do on the web, like running processes and opening TCP connections.