3 ms·

In my experience the worst part about Word is collaboration. Have you ever seen the track changes interface? It's a sea of incomprehensible, badly segmented,

In my experience the worst part about Word is collaboration. Have you ever seen the track changes interface? It's a sea of incomprehensible, badly segmented, changes where every switch from bold to italics is counted as a separate change mixed in with actual substantive changes and has some little red line among thousands of indistinguishable little red lines pointing to some unclear place in the document. It's a totally unusable interface, and yet some highly collaborative industries (ahem, law) are stuck with it. It's horrifying. I have seriously considered offering to pay people with whom I'm forced to exchange documents (especially academic law review articles which tend to have thousands of edits) to learn markdown and git just so I don't have to eyestrain my way through that track changes screen

objplant 8y ago
How well does git perform for usual text (not code)? I only use git for code and as far as I know it compare only whole lines, which is not very useful in a text where a paragraph has no line brakes and is about half a page long. I write in Word as well and merging edits from collaborators with my in-the-meantime-updated document is really anoying and error-prone. I found https://www.simuldocs.com/ https://www.simuldocs.com/, but haven't tried it yet.
- fwip 8y ago
  There are a few tweaks you can make to gits diff so it shows changes in a line better, but it's not great. You can also write each sentence on its own line - output will still put them in the same paragraph. But it's not as nice a reading experience of the markdown.
  - deleted 8y ago
    [deleted]
- pronoiac 8y ago
  markdown and git can work together. I've set that each sentence gets its own line, and configured git to use wdiff instead, highlighting the changed words instead of lines.
- CogitoCogito 8y ago
  > How well does git perform for usual text (not code)? I only use git for code and as far as I know it compare only whole lines, which is not very useful in a text where a paragraph has no line brakes and is about half a page long. As long as you limit your lines' lengths git is just as good for text as it is for code. Of course you're correct that using it for paragraphs without line breaks wouldn't be that great, but my question would be why would you ever do that?

objplant 8y ago

How well does git perform for usual text (not code)? I only use git for code and as far as I know it compare only whole lines, which is not very useful in a text where a paragraph has no line brakes and is about half a page long. I write in Word as well and merging edits from collaborators with my in-the-meantime-updated document is really anoying and error-prone. I found https://www.simuldocs.com/ https://www.simuldocs.com/, but haven't tried it yet.

fwip 8y ago
There are a few tweaks you can make to gits diff so it shows changes in a line better, but it's not great. You can also write each sentence on its own line - output will still put them in the same paragraph. But it's not as nice a reading experience of the markdown.
- deleted 8y ago
  [deleted]
pronoiac 8y ago
markdown and git can work together. I've set that each sentence gets its own line, and configured git to use wdiff instead, highlighting the changed words instead of lines.
CogitoCogito 8y ago
> How well does git perform for usual text (not code)? I only use git for code and as far as I know it compare only whole lines, which is not very useful in a text where a paragraph has no line brakes and is about half a page long. As long as you limit your lines' lengths git is just as good for text as it is for code. Of course you're correct that using it for paragraphs without line breaks wouldn't be that great, but my question would be why would you ever do that?