4 ms·

Greppability is an interesting idea, and a good one, but I'm going to disagree with the recommendation > Stop hard-wrapping and just use soft-wrapping, Grep f

Greppability is an interesting idea, and a good one, but I'm going to disagree with the recommendation > Stop hard-wrapping and just use soft-wrapping, Grep for some pattern in soft-wrapped text and you get a lot of extraneous material. You also can't grep for things "at the beginning of the line", which is often an important indicator. When I did a lot of plain C programming, I would put function names at the start of a line, below their return type to make it easy to grep for a function definition, rather than just uses. Soft-wrapping also limits the use of diffability, a complement to grepability. You might correct a single letter in a misspelled word in a soft-wrapped paragraph. Do a "git diff" or equivalent and you'll get back a huge block of "changed" text. Useless. Short, hard wrapped lines make it easy to see diffs.

BlueTemplar 2y ago
> You also can't grep for things "at the beginning of the line" Why can't you, is there no way to make grep work with regular expressions??
kugurerdem 2y ago
Can you detail a bit more what you mean by extraneous material? Is it something like "you now also need tools that can do soft-wrapping"? Even if that's the case, I think it is easier to wrap a text than to unwrap it (programmatically). So, if you need hard-wrapping, you can just do it. Wrapping is just as simple as; `fold -s -w 80 input.txt` Unwrapping usually turns out to be harder according to my experiences. [1] > You also can't grep for things "at the beginning of the line", which is often an important indicator. When I did a lot of plain C programming, I would put function names at the start of a line, below their return type to make it easy to grep for a function definition, rather than just uses. I see what you mean. But I don’t think your approach conflicts with my recommendation for soft-wrapping. You can still soft-wrap regular text files while choosing to separate certain lines of code for clarity. What you’re doing might not even be considered "hard-wrapping" in the typical sense—it's not like you're breaking a 240-character line into multiple lines. You're simply formatting the definition in a way that suits your style, and it's perfectly ok! For the last one, you can simply use `git diff --word-diff`. Also, platforms like GitHub already highlight word-based diffs, so it usually is very easy to spot the changes. [1]. https://news.ycombinator.com/item?id=39227848 https://news.ycombinator.com/item?id=39227848
- bediger4000 2y ago
  Extraneous material in my example would be potentially the rest of a large paragraph if I change one word. The example would be the diffs of a "Word" doc: the whole paragraph shows as a diff. Folding after the "git diff" would just mean visually picking the diff out of a lot of text. I do a lot of Go programming these days, and there's a conventional format for code that ends up with a lot of hard wrapped lines, so my C example is just that, an example. Maybe Markdown would be a better example. When I edit markdown, I move around phrases, clauses and sentences. It's certainly possible to do this with a gigantic soft wrapped chunk of text, but it's much easier with one clause or even phrase per hard wrapped (at 74 characters or less) line. Grepability and diffability and even running text through sed or awk are easier. You're not relying on text coloring. Editing with vim is easier, it has commands to move the cursor to next word, previous paragraph etc etc. This is one of those things like tabs or spaces and byte order marks. We're unlikely to convince each other.
  - MrJohz 2y ago
    That doesn't sound like soft or hard wrapping, though, that sounds like semantic wrapping, which is a separate concept entirely. With semantic wrapping you put each sentence (or similar) on a new line, which helps with diffing. But if that sentence runs over e.g. 80 characters, you still need to decide whether you're going to hard wrap or soft wrap that sentence. And in the inverse direction, if you don't do semantic wrapping, you'll have similar issues with diffs regardless of whether you use hard wraps or soft wraps. So I think that's a good argument for doing semantic wrapping of code and text (I guess semantic wrapping for code is just not writing everything in one long line separated by semicolons), but once you've put in semantic line breaks, you still need to decide how to handle text that spans multiple lines.
    - a1369209993 2y ago
      > But if that sentence runs over e.g. 80 characters, > you still need to decide > whether you're going to hard wrap or soft wrap that sentence. No I don't. Semantic wrapping all the way.
card_zero 2y ago
Huh? Presumably "just use soft-wrapping" only applies to long lines. It isn't banning you from using linebreaks before function definitions. The next section is about linebreaks! Earlier on, it talks about lining thing up with tabs! It can't be advising you to write entire programs on one line. But anyway, don't you have a code editor with a sidebar with function names, that you can click on to go to the definitions? Sounds like choosing to navigate via grep is the nature of the problem with grepability. And other search tools that aren't regex based can search for multi-line text. This isn't about plain text, it's about Vim. It's like saying "this farmer's field should be constructed differently because it isn't skateable".
defanor 2y ago
Neither does soft wrap play nicely with preformatted texts (e.g., ASCII graphics, including diagrams and ornaments such as titles centered with spaces, as well as formatted code). And the support for soft-wrapping in tools varies: it may be completely unavailable, or just turned off by default, and generally unused in such a case. I think reflowable text enters the area of markup languages, rather than plain text.
eviks 2y ago
> Soft-wrapping also limits the use of diffability there are better tools for that that show word-based diff instead of a huge block. There aren't such tools that can convert your hard-coded linebreaks back.
- Zamiel_Snawley 2y ago
  Even with just regular git on the command line, there is an option for word-wise diffing, and hacky ways to get character-wise diffing.

BlueTemplar 2y ago

> You also can't grep for things "at the beginning of the line" Why can't you, is there no way to make grep work with regular expressions??

kugurerdem 2y ago

Can you detail a bit more what you mean by extraneous material? Is it something like "you now also need tools that can do soft-wrapping"? Even if that's the case, I think it is easier to wrap a text than to unwrap it (programmatically). So, if you need hard-wrapping, you can just do it. Wrapping is just as simple as; `fold -s -w 80 input.txt` Unwrapping usually turns out to be harder according to my experiences. [1] > You also can't grep for things "at the beginning of the line", which is often an important indicator. When I did a lot of plain C programming, I would put function names at the start of a line, below their return type to make it easy to grep for a function definition, rather than just uses. I see what you mean. But I don’t think your approach conflicts with my recommendation for soft-wrapping. You can still soft-wrap regular text files while choosing to separate certain lines of code for clarity. What you’re doing might not even be considered "hard-wrapping" in the typical sense—it's not like you're breaking a 240-character line into multiple lines. You're simply formatting the definition in a way that suits your style, and it's perfectly ok! For the last one, you can simply use `git diff --word-diff`. Also, platforms like GitHub already highlight word-based diffs, so it usually is very easy to spot the changes. [1]. https://news.ycombinator.com/item?id=39227848 https://news.ycombinator.com/item?id=39227848

bediger4000 2y ago
Extraneous material in my example would be potentially the rest of a large paragraph if I change one word. The example would be the diffs of a "Word" doc: the whole paragraph shows as a diff. Folding after the "git diff" would just mean visually picking the diff out of a lot of text. I do a lot of Go programming these days, and there's a conventional format for code that ends up with a lot of hard wrapped lines, so my C example is just that, an example. Maybe Markdown would be a better example. When I edit markdown, I move around phrases, clauses and sentences. It's certainly possible to do this with a gigantic soft wrapped chunk of text, but it's much easier with one clause or even phrase per hard wrapped (at 74 characters or less) line. Grepability and diffability and even running text through sed or awk are easier. You're not relying on text coloring. Editing with vim is easier, it has commands to move the cursor to next word, previous paragraph etc etc. This is one of those things like tabs or spaces and byte order marks. We're unlikely to convince each other.
- MrJohz 2y ago
  That doesn't sound like soft or hard wrapping, though, that sounds like semantic wrapping, which is a separate concept entirely. With semantic wrapping you put each sentence (or similar) on a new line, which helps with diffing. But if that sentence runs over e.g. 80 characters, you still need to decide whether you're going to hard wrap or soft wrap that sentence. And in the inverse direction, if you don't do semantic wrapping, you'll have similar issues with diffs regardless of whether you use hard wraps or soft wraps. So I think that's a good argument for doing semantic wrapping of code and text (I guess semantic wrapping for code is just not writing everything in one long line separated by semicolons), but once you've put in semantic line breaks, you still need to decide how to handle text that spans multiple lines.
  - a1369209993 2y ago
    > But if that sentence runs over e.g. 80 characters, > you still need to decide > whether you're going to hard wrap or soft wrap that sentence. No I don't. Semantic wrapping all the way.

card_zero 2y ago

Huh? Presumably "just use soft-wrapping" only applies to long lines. It isn't banning you from using linebreaks before function definitions. The next section is about linebreaks! Earlier on, it talks about lining thing up with tabs! It can't be advising you to write entire programs on one line. But anyway, don't you have a code editor with a sidebar with function names, that you can click on to go to the definitions? Sounds like choosing to navigate via grep is the nature of the problem with grepability. And other search tools that aren't regex based can search for multi-line text. This isn't about plain text, it's about Vim. It's like saying "this farmer's field should be constructed differently because it isn't skateable".

defanor 2y ago

Neither does soft wrap play nicely with preformatted texts (e.g., ASCII graphics, including diagrams and ornaments such as titles centered with spaces, as well as formatted code). And the support for soft-wrapping in tools varies: it may be completely unavailable, or just turned off by default, and generally unused in such a case. I think reflowable text enters the area of markup languages, rather than plain text.

eviks 2y ago

> Soft-wrapping also limits the use of diffability there are better tools for that that show word-based diff instead of a huge block. There aren't such tools that can convert your hard-coded linebreaks back.

Zamiel_Snawley 2y ago
Even with just regular git on the command line, there is an option for word-wise diffing, and hacky ways to get character-wise diffing.