4 ms·

What do you do when you view a diff, and what you see there doesn't match your editor? Edit: I know emacs can probably view diffs. That's not the point, unless

by rlpb 13y ago

What do you do when you view a diff, and what you see there doesn't match your editor? Edit: I know emacs can probably view diffs. That's not the point, unless you expect every window to be the same width, and every tool to wrap everything exactly the same.

coldtea 13y ago
>What do you do when you view a diff, and what you see there doesn't match your editor? Mentally account for one more line or two?
dalore 13y ago
We should fix the diff tools too while we are at it. Why are we diffing by lines and not doing a semantic diff of the code? If the compiler doesn't care about it, why should the diff?
- spenczar5 13y ago
  Not all languages are compiled - sometimes line breaks are meaningful, and it would be good if diff tools work across all languages.
- RogerL 13y ago
  Scaling. The same diff tool works for text files, latex and other markup files, for any computer language, and so on. I can write downstream tools that take the output of the diff and do further processing, without worrying about what the output might look like for brainfuck. And how long would we have to wait for Torvalds to add a C++ or Java extension to git? :)
- rlpb 13y ago
  You essentially want to replace Unix pipelines with an API then. Nobody else has managed to do this successfully, completely replacing text.
  - Chris_Newton 13y ago
    Isn’t this the heart of the problem, though? Raw text is a limited medium, and working at the level of plain text analysis rather than semantic analysis does limit how much our tools can achieve. The UNIX philosophy of having many small, text-based tools and chaining them together represents a common platform, but it’s also a least common denominator platform. As long as we allow that glass ceiling to remain, the best our tools will ever do is push it incrementally higher, one tiny step at a time. If we want to make big leaps, we’re going to have to sacrifice some of that generality so we can use more powerful but specific tools. Unfortunately, that means that any new programming language wanting to take on the established standards needs not only a compiler/interpreter, but also the rest of the ecosystem: a comprehensive tool chain, ample library coverage, documentation and training resources, and so on. It is also, almost inevitably, going to need some standardised way of bridging the gap to today’s established languages for interoperability and backward compatibility purposes. This is why I think the view that programming languages should be designed optimally for humans is short-sighted, and I suspect most of the big success stories in the coming years will be languages that were designed with clean semantics and easy parsing in mind. Those languages will better support building that surrounding ecosystem, and a good language with a good ecosystem is more practically useful than a slightly better language with a limited ecosystem.
    - rlpb 13y ago
      > working at the level of plain text analysis rather than semantic analysis does limit how much our tools can achieve. We can add semantic analysis. I have no problem with that. But removing or harming the ability to do text analysis might not stop us from using more sophisticated tools, but it does stop us from putting tools together quickly in a way not previously predicted. This is why Unix is so powerful. If you haven't read The Art of Unix Programming, I urge you to do so. It puts the argument and examples forward far more convincingly than I can. Would moving to semantic tools harm the ability to use our existing text-based tools? I'd say so. A simple tool like diff works better, for example, if you take your big list of Python imports and put each one on a separate line, and keep them sorted. Patching works smoother this way too, reducing the likelyhood of the need for manual conflict resolution. If we eliminate doing this kind of arrangement by hand, and instead start relying on a semantic editor, we'll lose this ability. I have yet to see a tool that does semantic diffs, patches and merges better than diff, patch and git do.
jlgreco 13y ago
Vim shows diffs with wrapped lines just fine as far as I can tell. I have it set up to show both versions side by side, with changed lines highlighted and the particular change on each line also highlighted. I can wrap one or both, depending on how wide I make either. Can you explain what problem you think might occur? Its not clear to me what problems you anticipate.
- platz 13y ago
  Especially in languages where whitespace matters, I think it's the wrapping of the lines itself that is problematic
  - jlgreco 13y ago
    The editor wrapping the line does not actually change the whitespace though. It is a presentation change only.
- rlpb 13y ago
  Humans are set up to see differences visually when they see patterns. If the way that lines wrap depends on the width of your window, then it becomes hard to match up the output visually from windows of different widths. An example: I type "git diff" into one window, and look for some particular change area in my editor in a different window. If the wrap and alignments depend on the widths of my windows, then they won't match unless the widths of my windows also match. And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated.
  - jlgreco 13y ago
    Can't say I experience this problem, the highlighting of relevant lines takes care of this. Human eyes are terrible at tracking across long lines of text without jumping up or down a line (this is why splitting text into columns is common in large books). On the other hand jumping between regions of color is easy. Furthermore, I don't think this is true: "And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated." Being able to resize both, with the constraint that they must both be kept in sync (which to be clear, I don't consider necessary), is better than the alternative: no effective resizing at all. You should probably look into integrating git-diff with your editor though (use git-difftool).
dilap 13y ago
Good question. When I do a diff from within emacs, using ediff, it "just works" -- diffs are shown side-by-side w/ the same wrapping applied. (Ediff is also good at showing you what changed within the line.) If I'm diffing in an external tool (like gitx, or just on the command line), then I just see (possibly) long lines. So far, it hasn't been an issue for me. Obviously, diff, as a line-oriented protocol, breaks down as lines get really long -- but it's still just code, so it's not like my lines are ever insanely-long. :) I also use a mode that highlights my current (physical) line in the file, so I still tend to have a very good sense of what the physical line in the file is, despite the wrapped visual display. E.g., http://imgur.com/a/wAXHJ http://imgur.com/a/wAXHJ One of the oft-touted benefits of wrapping lines at (say) 80 chars is it makes it easy to do side-by-side viewing of files -- using dynamic wrapping gives you this same benefit, but even more so, since you can heads-up different files at whatever width your current display happens to have. (Or however many files you want to have side-by-side.) Also, there's a nice side-benefit to diffs, which is you don't get the noise that comes from a change that forces a manual rewrapping -- e.g., maybe I decide my variable "id" was too generic, so I change it to "frobnackId", but then this pushes some function call over the 80-character limit. If I'm manually rewrapping, I get a weird diff of multiple lines changing over the rewrap. (On the other hand, a definite down-side is if you do find yourself using an editor that can't wrap nicely, code with long lines can be quite annoying.)

by rlpb 13y ago

coldtea 13y ago

>What do you do when you view a diff, and what you see there doesn't match your editor? Mentally account for one more line or two?

dalore 13y ago

We should fix the diff tools too while we are at it. Why are we diffing by lines and not doing a semantic diff of the code? If the compiler doesn't care about it, why should the diff?

spenczar5 13y ago
Not all languages are compiled - sometimes line breaks are meaningful, and it would be good if diff tools work across all languages.
RogerL 13y ago
Scaling. The same diff tool works for text files, latex and other markup files, for any computer language, and so on. I can write downstream tools that take the output of the diff and do further processing, without worrying about what the output might look like for brainfuck. And how long would we have to wait for Torvalds to add a C++ or Java extension to git? :)
rlpb 13y ago
You essentially want to replace Unix pipelines with an API then. Nobody else has managed to do this successfully, completely replacing text.
- Chris_Newton 13y ago
  Isn’t this the heart of the problem, though? Raw text is a limited medium, and working at the level of plain text analysis rather than semantic analysis does limit how much our tools can achieve. The UNIX philosophy of having many small, text-based tools and chaining them together represents a common platform, but it’s also a least common denominator platform. As long as we allow that glass ceiling to remain, the best our tools will ever do is push it incrementally higher, one tiny step at a time. If we want to make big leaps, we’re going to have to sacrifice some of that generality so we can use more powerful but specific tools. Unfortunately, that means that any new programming language wanting to take on the established standards needs not only a compiler/interpreter, but also the rest of the ecosystem: a comprehensive tool chain, ample library coverage, documentation and training resources, and so on. It is also, almost inevitably, going to need some standardised way of bridging the gap to today’s established languages for interoperability and backward compatibility purposes. This is why I think the view that programming languages should be designed optimally for humans is short-sighted, and I suspect most of the big success stories in the coming years will be languages that were designed with clean semantics and easy parsing in mind. Those languages will better support building that surrounding ecosystem, and a good language with a good ecosystem is more practically useful than a slightly better language with a limited ecosystem.
  - rlpb 13y ago
    > working at the level of plain text analysis rather than semantic analysis does limit how much our tools can achieve. We can add semantic analysis. I have no problem with that. But removing or harming the ability to do text analysis might not stop us from using more sophisticated tools, but it does stop us from putting tools together quickly in a way not previously predicted. This is why Unix is so powerful. If you haven't read The Art of Unix Programming, I urge you to do so. It puts the argument and examples forward far more convincingly than I can. Would moving to semantic tools harm the ability to use our existing text-based tools? I'd say so. A simple tool like diff works better, for example, if you take your big list of Python imports and put each one on a separate line, and keep them sorted. Patching works smoother this way too, reducing the likelyhood of the need for manual conflict resolution. If we eliminate doing this kind of arrangement by hand, and instead start relying on a semantic editor, we'll lose this ability. I have yet to see a tool that does semantic diffs, patches and merges better than diff, patch and git do.

jlgreco 13y ago

Vim shows diffs with wrapped lines just fine as far as I can tell. I have it set up to show both versions side by side, with changed lines highlighted and the particular change on each line also highlighted. I can wrap one or both, depending on how wide I make either. Can you explain what problem you think might occur? Its not clear to me what problems you anticipate.

platz 13y ago
Especially in languages where whitespace matters, I think it's the wrapping of the lines itself that is problematic
- jlgreco 13y ago
  The editor wrapping the line does not actually change the whitespace though. It is a presentation change only.
rlpb 13y ago
Humans are set up to see differences visually when they see patterns. If the way that lines wrap depends on the width of your window, then it becomes hard to match up the output visually from windows of different widths. An example: I type "git diff" into one window, and look for some particular change area in my editor in a different window. If the wrap and alignments depend on the widths of my windows, then they won't match unless the widths of my windows also match. And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated.
- jlgreco 13y ago
  Can't say I experience this problem, the highlighting of relevant lines takes care of this. Human eyes are terrible at tracking across long lines of text without jumping up or down a line (this is why splitting text into columns is common in large books). On the other hand jumping between regions of color is easy. Furthermore, I don't think this is true: "And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated." Being able to resize both, with the constraint that they must both be kept in sync (which to be clear, I don't consider necessary), is better than the alternative: no effective resizing at all. You should probably look into integrating git-diff with your editor though (use git-difftool).

dilap 13y ago

Good question. When I do a diff from within emacs, using ediff, it "just works" -- diffs are shown side-by-side w/ the same wrapping applied. (Ediff is also good at showing you what changed within the line.) If I'm diffing in an external tool (like gitx, or just on the command line), then I just see (possibly) long lines. So far, it hasn't been an issue for me. Obviously, diff, as a line-oriented protocol, breaks down as lines get really long -- but it's still just code, so it's not like my lines are ever insanely-long. :) I also use a mode that highlights my current (physical) line in the file, so I still tend to have a very good sense of what the physical line in the file is, despite the wrapped visual display. E.g., http://imgur.com/a/wAXHJ http://imgur.com/a/wAXHJ One of the oft-touted benefits of wrapping lines at (say) 80 chars is it makes it easy to do side-by-side viewing of files -- using dynamic wrapping gives you this same benefit, but even more so, since you can heads-up different files at whatever width your current display happens to have. (Or however many files you want to have side-by-side.) Also, there's a nice side-benefit to diffs, which is you don't get the noise that comes from a change that forces a manual rewrapping -- e.g., maybe I decide my variable "id" was too generic, so I change it to "frobnackId", but then this pushes some function call over the 80-character limit. If I'm manually rewrapping, I get a weird diff of multiple lines changing over the rewrap. (On the other hand, a definite down-side is if you do find yourself using an editor that can't wrap nicely, code with long lines can be quite annoying.)