Using auto-fill-mode vs. visual-line-mode

[pjaml]

Hi everyone,

I’ve been using Doom Emacs for a few years, but I’ve recently decided to try building up a config from scratch (very slowly) and learn more about Emacs as I go. I’ve been using visual-line-mode (along with visual-fill-column-mode) since I started using Emacs.

I’m just curious if people are using auto-fill-mode, and if so, what advantages it has. Seems like it can be helpful to have hard line breaks when you’re using version control.

In my very brief attempt to try out auto-fill-mode, I ran into trouble when I had multiple windows open that were narrower than my fill column. Also, opening auto-filled text files in Android Emacs on my smartphone didn’t look so great with a small screen. For people who use auto-fill-mode, are there ways to deal with issues like these? Are you just adjusting the font size to make up for it? I’m not used to having to think about this.

[ashraz]

@pjaml

I’m just curious if people are using auto-fill-mode, and if so, what advantages it has.

There’s only one point in my configuration where I use auto-fill-mode, and that’s magit’s COMMIT_EDITMSG buffer. This allows me to just write text and have magit handle the (recommended) hard breaks automatically.

If I were to write text-only mails with Emacs, I would use auto-fill-mode there too, just to ensure that my text follows the RFC.

And that’s exactly where auto-fill-mode shines: situations where only a specific line length is valid.

@pjaml

Seems like it can be helpful to have hard line breaks when you’re using version control.

I disagree (unless you’re talking about commit messages). Let’s say you have the following text with hard line breaks:

I’m just curious if people are using auto-fill-mode, and if so, what
advantages it has. Seems like it can be helpful to have hard line
breaks when you’re using version control.

Now we want to add a word:

I’m just curious if people are using auto-fill-mode, and if so, what
convincing advantages it has. Seems like it can be helpful to have
hard line breaks when you’re using version control.

This yields the following diff:

 I’m just curious if people are using auto-fill-mode, and if so, what
-advantages it has. Seems like it can be helpful to have hard line
-breaks when you’re using version control.
\ No newline at end of file
+convincing advantages it has. Seems like it can be helpful to have
+hard line breaks when you’re using version control.

A change in a single line affected two. Even worse, a single word moved all words in the following lines. That makes it hard to see the actual changes, because content and representation suddenly are mixed.

In many markup languages, a single newline does not introduce a new paragraph/newline. So if we think about that being Markdown or LaTeX, the following text that enters a non-rendering newline after periods would render the same but have a clear diff:

I’m just curious if people are using auto-fill-mode, and if so, what advantages it has.
Seems like it can be helpful to have hard line breaks when you’re using version control.

 I’m just curious if people are using auto-fill-mode, and if so, what convincing advantages it has.
Seems like it can be helpful to have hard line breaks when you’re using version control.

This yields a single line diff.

-I’m just curious if people are using auto-fill-mode, and if so, what advantages it has.
+I’m just curious if people are using auto-fill-mode, and if so, what convincing advantages it has.
 Seems like it can be helpful to have hard line breaks when you’re using version control.

Note that the unrelated sentence isn’t affected by the change. All of this of course only holds if you can use free-flowing text—if you have to work on the resulting text and said text needs to have a fixed with, then that changes the whole scenario, but otherwise I’d say: drop auto-fill-mode unless actually required.

[pjaml]

@ashraz

A change in a single line affected two. Even worse, a single word moved all words in the following lines. That makes it hard to see the actual changes, because content and representation suddenly are mixed.

This makes sense, thanks for clarifying.

Now I’m even more curious why people choose to use auto-fill-mode over visual-line-mode when editing text. I use mu4e for email and even there you can compose in visual-line-mode and have it add hard line breaks of the right length before sending.

I know Prot says in his config that he uses it:

I find this much more pleasant to work with than to have to rely on visual-line-mode to visually wrap long lines. I want my text to be readable even if I do not use Emacs (e.g. if I use cat or less on the command-line). Auto-filled text does not affect published prose, as the relevant programs strip away the newlines inside a paragraph.

[ashraz]

@pjaml

I know Prot says in his config that he uses it:

The cat and less use cases are perfectly valid. Still, if it is just about prose, I would probably use fmt (the example text is your initial prose):

For Prot, there’s an additional benefit by limiting the line length: handling contributions. Prot has signed an FSF copyright assignment. That means that he may only accept contributions by those who also signed that assignment, unless the change is less than ~15 lines. Having a fixed line length there stops all discussions and ambiguity, so there’s also a legal aspect.

That aside, it’s also a stylistic choice. I would probably personally use olivetti-mode and visual-line-mode to create something similar.

Disclaimer: there was a time when I’ve used M-q manually on each paragraph, so I would have benefit from auto-fill-mode. But I realized that coworkers don’t have a similar tool installed, and it was quite a hassle for them to fill the text again. That’s why I’ve changed to a non-filled style, easier collaboration in those cases.

[ryuslash]

Personally I only use visual-line-mode in org-mode along with org-indent-mode and olivetti-mode. These together make the line lengths, indentation, and all such things implementation details. I don’t have to think about it. Like you said when you open an auto-filled file on a smaller screen (phone) you might end up with lines that don’t fit anymore. Not a problem with visual-line-mode.

But I really don’t like the look of having a certain section indented and then not having the wrapped lines follow the same indentation, which is what happens with visual-line-mode without org-indent-mode.

So for Markdown I end up using auto-fill-mode. For commit messages I actually use refill-mode so that when I modify an existing sentence it immediately refills the paragraph and I don’t have to use M-q to fix it up manually. This does come with some formatting issues that I haven’t taken the time to look at yet, though. For emails I also usually end up using auto-fill-mode. I would like to not have to worry about that, though. As long as indentation and formatting aren’t issues it’s better to let the client figure out how to do the flow of some text.

@ashraz

A change in a single line affected two. Even worse, a single word moved all words in the following lines. That makes it hard to see the actual changes, because content and representation suddenly are mixed.

I agree, but also I think this is a failing of the diff tool. If you use diff-refine or ediff-auto-refine you can tell what’s changed more easily.

I was hoping difftastic would have something for this as well, but it doesn’t appear so, it seems to focus on other formats mostly.

[ashraz]

@ryuslash

I agree, but also I think this is a failing of the diff tool. If you use diff-refine or ediff-auto-refine you can tell what’s changed more easily

(Un)fortunately, it doesn’t matter what I use, but what the majority experiences. Discourse diff block is a good representation of the most commonly supported features in presenting diffs which even lacks highlighting the actual changes within the lines. That’s also true for other representations, e.g., git-web.

Personally, I like changes that are compatible to the 30±year-old diff tool; they even are readable on busybox diff.