# Using auto-fill-mode vs. visual-line-mode **URL:** \ **Category:** Emacs\ **Created:** [February 15, 2024, 1:23am UTC](https://forum.systemcrafters.net/t/using-auto-fill-mode-vs-visual-line-mode/275 "2024-02-15T01:23:43Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![pjaml](https://avatars.discourse-cdn.com/v4/letter/p/df705f/32.png) [@pjaml](https://forum.systemcrafters.net/u/pjaml)\ **Post date:** [February 15, 2024, 1:23am UTC](https://forum.systemcrafters.net/t/using-auto-fill-mode-vs-visual-line-mode/275/1 "2024-02-15T01:23:43Z")
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. ---
**Author:** ![ashraz](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.systemcrafters.net/ashraz/32/509_2.png) [@ashraz](https://forum.systemcrafters.net/u/ashraz)\ **Post date:** [February 15, 2024, 9:57am UTC](https://forum.systemcrafters.net/t/using-auto-fill-mode-vs-visual-line-mode/275/2 "2024-02-15T09:57:18Z")
> [@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](https://www.rfc-editor.org/rfc/rfc2822#section-2.1.1). 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: ```plaintext 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: ```plaintext 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: ```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: ```plaintext 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. ``` ```plaintext 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. ```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. ---
**Author:** ![pjaml](https://avatars.discourse-cdn.com/v4/letter/p/df705f/32.png) [@pjaml](https://forum.systemcrafters.net/u/pjaml)\ **Post date:** [February 16, 2024, 1:58am UTC](https://forum.systemcrafters.net/t/using-auto-fill-mode-vs-visual-line-mode/275/3 "2024-02-16T01:58:56Z")
> [@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](https://protesilaos.com/emacs/dotemacs#h:c5fbd6dd-2982-4fca-aeed-d0e750d399bd) 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. ---
**Author:** ![ashraz](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.systemcrafters.net/ashraz/32/509_2.png) [@ashraz](https://forum.systemcrafters.net/u/ashraz)\ **Post date:** [February 16, 2024, 6:49am UTC](https://forum.systemcrafters.net/t/using-auto-fill-mode-vs-visual-line-mode/275/4 "2024-02-16T06:49:27Z")
> [@pjaml](#): > > I know Prot says in [his config](https://protesilaos.com/emacs/dotemacs#h:c5fbd6dd-2982-4fca-aeed-d0e750d399bd) 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): ![screenshot of four outputs, showing cat, bat, fmt and fmt piped into bat](https://canada1.discourse-cdn.com/flex029/uploads/systemcrafters/original/1X/cde9daaaf7b1c19a69ea416df478bfd6eb9d86c0.png) For Prot, there’s an additional benefit by limiting the line length: handling contributions. Prot has signed an [FSF copyright assignment](https://www.fsf.org/blogs/licensing/FSF-copyright-handling). 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. ---
**Author:** ![ryuslash](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.systemcrafters.net/ryuslash/32/66_2.png) [@ryuslash](https://forum.systemcrafters.net/u/ryuslash)\ **Post date:** [February 16, 2024, 11:31pm UTC](https://forum.systemcrafters.net/t/using-auto-fill-mode-vs-visual-line-mode/275/5 "2024-02-16T23:31:03Z")
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. ![image](https://canada1.discourse-cdn.com/flex029/uploads/systemcrafters/original/1X/47db15ca4b31abf9507a4d37afef5250bb7ec084.png) 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. ---
**Author:** ![ashraz](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.systemcrafters.net/ashraz/32/509_2.png) [@ashraz](https://forum.systemcrafters.net/u/ashraz)\ **Post date:** [February 17, 2024, 11:26am UTC](https://forum.systemcrafters.net/t/using-auto-fill-mode-vs-visual-line-mode/275/6 "2024-02-17T11:26:56Z")
> [@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`.