Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Looking at OPs github issue you can clearly see the problem and what they're trying to solve.

    .., observableValue, -> .., observable[Event, observable]Value,
    .., observableValue, -> .., [observableEvent, ]observableValue, 
The new algorithm better represents the change that the coder actually made.

More generally, I'd say that the point of diffing in something like VSCode is to try to aide the reviewer (for any number of types of reviewer - looking at merge conflicts etc) in evaluating a change.

It's a tool for human understanding, and from that point of view, text diffing is kinda barbaric (don't get me wrong, I love it and use it all day long). You can rename a variable using an LSP, knowing that it's effectively a safe no-op on the code. But once it comes to review the PR, that change is just additional noise mixed in with everything else.

I use Neovim, where I have treesitter. I look at the amazing information in there and long for the day when I'll be able to use its power for reviews. Something like I described above - show me a version of the change with stuff that doesn't matter, like renames, removed. Now show me a diff that's the inverse of that, so I can skim it. I mentioned in another comment that `--color-moved=dimmed-zebra` is a useful tool to help focus on what matters.



It is a very interesting idea to decompose a diff into two diffs - one part that a computer understands (like renames, formatting changes), and one part that a computer does not understand, but that is as small as possible!

The referenced issue is only one example. There are many more (e.g. https://github.com/microsoft/vscode/issues/164574).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: