3 ms·

Maybe diff should change to suit programs, rather than programs change to suit diff.

by fire_lake 2y ago

benatkin 2y ago
Indeed. That’s why prettier ain’t pretty.
slooonz 2y ago
You want diff to know the syntax and semantics of every programming language out there ?
- benatkin 2y ago
  It would be like a syntax highlighter. It’s doable.
  - slooonz 2y ago
    But diff does not exists in a vacuum. It would need to be integrated to IDEs, editor, merge tools, PR tools. You now have to have `patch` understand and depend on the details of the syntax of your language. In a way that may break between different versions of diff and patch. Not even starting with variants of a language, different interpretations of how to handle the preprocessor/macros system, different editions of the same language. All that, just to not have to add a trailing comma ?
    - benatkin 2y ago
      Most things like patch would still use line diff. I think I would want this semantic diff in the merge request review and the logs. It could have definitions distributed with the syntax highlighters in language plugins in an editor/IDE, git CLI, and git forge.
      - from-nibly 2y ago
        So GitHub, git lab, gutbucket, gittea (and its 50 forks), fossil, and all the other tools should change, not the formatting of the code?
        benatkin 2y ago
        No, having a concise separator is still preferable to saving a line in a diff.
- knubie 2y ago
  This is possible already with tools like difftastic. https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic
  - DarkPlayer 2y ago
    Difftastic would not solve the issue described by madeofpalk because it still highlights the added comma. You need a diff tool that can distinguish between optional and required syntax. So far I am not aware of any tool that supports this, except the one I am working on (SemanticDiff).
    - benatkin 2y ago
      I'm pretty sure this counts. https://github.com/afnanenayet/diffsitter https://github.com/afnanenayet/diffsitter Certainly the idea has been suggested many times. I think people end up formatting both before/after and doing a diff on formatted before against formatted after. I've done that.

Maybe diff should change to suit programs, rather than programs change to suit diff.

benatkin 2y ago

Indeed. That’s why prettier ain’t pretty.

slooonz 2y ago

You want diff to know the syntax and semantics of every programming language out there ?

benatkin 2y ago
It would be like a syntax highlighter. It’s doable.
- slooonz 2y ago
  But diff does not exists in a vacuum. It would need to be integrated to IDEs, editor, merge tools, PR tools. You now have to have `patch` understand and depend on the details of the syntax of your language. In a way that may break between different versions of diff and patch. Not even starting with variants of a language, different interpretations of how to handle the preprocessor/macros system, different editions of the same language. All that, just to not have to add a trailing comma ?
  - benatkin 2y ago
    Most things like patch would still use line diff. I think I would want this semantic diff in the merge request review and the logs. It could have definitions distributed with the syntax highlighters in language plugins in an editor/IDE, git CLI, and git forge.
    - from-nibly 2y ago
      So GitHub, git lab, gutbucket, gittea (and its 50 forks), fossil, and all the other tools should change, not the formatting of the code?
      - benatkin 2y ago
        No, having a concise separator is still preferable to saving a line in a diff.
knubie 2y ago
This is possible already with tools like difftastic. https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic
- DarkPlayer 2y ago
  Difftastic would not solve the issue described by madeofpalk because it still highlights the added comma. You need a diff tool that can distinguish between optional and required syntax. So far I am not aware of any tool that supports this, except the one I am working on (SemanticDiff).
  - benatkin 2y ago
    I'm pretty sure this counts. https://github.com/afnanenayet/diffsitter https://github.com/afnanenayet/diffsitter Certainly the idea has been suggested many times. I think people end up formatting both before/after and doing a diff on formatted before against formatted after. I've done that.