visual-line-mode tweaks

visual-line-mode tweaks

[Miles Bader]

(1) Maybe visual-line-mode should turn off auto-fill-mode -- it's
annoying to have your lines truncated physically when editing a file
that intentionally uses a line-per-paragraph, and it's very common for
auto-fill mode to be turned on by default.

[I turn on auto-fill mode for text-mode, text-mode is my default
major-mode -- but if i visit a file which uses line-per-paragraph, I do
M-x visual-line-mode...]

(2) The lighter should probably be "Wrap", not "wrap", to match other
lighters.

-Miles

-- 
Rational, adj. Devoid of all delusions save those of observation, experience
and reflection.

Re: visual-line-mode tweaks

[Stefan Monnier]

> (1) Maybe visual-line-mode should turn off auto-fill-mode -- it's
> annoying to have your lines truncated physically when editing a file
> that intentionally uses a line-per-paragraph, and it's very common for
> auto-fill mode to be turned on by default.

> [I turn on auto-fill mode for text-mode, text-mode is my default
> major-mode -- but if i visit a file which uses line-per-paragraph, I do
> M-x visual-line-mode...]

I'm not completely opposed to it, but I'm not sure how we could do it in
a way that wouldn't be annoying in one case or another.  So if you
propose a patch, maybe I would accept it.

> (2) The lighter should probably be "Wrap", not "wrap", to match other
> lighters.

Yes, that's just a bug,


        Stefan

Re: visual-line-mode tweaks

[Teemu Likonen]

* 2010-02-03 09:23 (-0500), Stefan Monnier wrote:

>> (1) Maybe visual-line-mode should turn off auto-fill-mode -- it's
>> annoying to have your lines truncated physically when editing a file
>> that intentionally uses a line-per-paragraph, and it's very common
>> for auto-fill mode to be turned on by default.

> I'm not completely opposed to it, but I'm not sure how we could do it
> in a way that wouldn't be annoying in one case or another. So if you
> propose a patch, maybe I would accept it.

It think the user interface is clearer when minor modes don't turn
others off. I always have visual-line-mode and auto-fill-mode turned on
when I'm writing email and news messages, that is, with message-mode. I
don't write long lines but want to have kill-visual-line (C-k) and
end-of-visual-line (C-e) available.

Re: visual-line-mode tweaks

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> (1) Maybe visual-line-mode should turn off auto-fill-mode -- it's
>> annoying to have your lines truncated physically when editing a file
>> that intentionally uses a line-per-paragraph, and it's very common for
>> auto-fill mode to be turned on by default.
>
>> [I turn on auto-fill mode for text-mode, text-mode is my default
>> major-mode -- but if i visit a file which uses line-per-paragraph, I do
>> M-x visual-line-mode...]
>
> I'm not completely opposed to it, but I'm not sure how we could do it in
> a way that wouldn't be annoying in one case or another.  So if you
> propose a patch, maybe I would accept it.

Hmm, Teemu also made a good point about minor modes not turning off
other minor modes.

I think it's fine if minor modes _interact_ in some way that helps the
user, but I think such interaction should be dynamic (so for instance,
if I turn visual-line-mode off again, auto-filling should once again be
enabled; one could do this by saving previous state or whatever, but
that gets messy and flaky).

How about having auto-fill-mode be a nop when visual-line-mode is
enabled (so the change would be to auto-fill-mode instead of
visual-line-mode)?

Here's a change to `do-auto-fill' that does it:

diff --git a/lisp/simple.el b/lisp/simple.el
index cce793f..e6b9ee3 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5006,7 +5006,8 @@ If optional arg REALLY-WORD is non-nil, it finds just a word."
 		 (<= (current-column) fc))
 	    (and auto-fill-inhibit-regexp
 		 (save-excursion (beginning-of-line)
-				 (looking-at auto-fill-inhibit-regexp))))
+				 (looking-at auto-fill-inhibit-regexp)))
+	    visual-line-mode)
 	nil ;; Auto-filling not required
       (if (memq justify '(full center right))
 	  (save-excursion (unjustify-current-line)))

I'm not sure if do-auto-fill would be the right place though; wouldn't
the place that _calls_ it be better, so alternative auto-filling
functions would also be suppressed?  [Also it would be nice if the
"Fill" in the mode-line were omitted or altered when auto-filling is
suppressed...]

-Miles

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: visual-line-mode tweaks

[Teemu Likonen]

* 2010-02-04 10:06 (+0900), Miles Bader wrote:

> I think it's fine if minor modes _interact_ in some way that helps the
> user, but I think such interaction should be dynamic (so for instance,
> if I turn visual-line-mode off again, auto-filling should once again
> be enabled; one could do this by saving previous state or whatever,
> but that gets messy and flaky).
>
> How about having auto-fill-mode be a nop when visual-line-mode is
> enabled (so the change would be to auto-fill-mode instead of
> visual-line-mode)?

I don't like that idea. Let's also think about the case when user turns
visual-line-mode on automatically in text-mode-hook because it makes
sense with most text modes. Then he turns auto-fill-mode on in _some_
hooks for modes which are derived from text-mode, such as org-mode and
message-mode. So, obviously turning auto-fill-mode on should turn its
behavior on.

I actually described my settings. If this "visual-line-mode tweak"
feature were already in place it's very likely that I would have sent a
bug report about visual-line-mode and auto-fill-mode not working
together. So, the bottom line is that I think a logical expected
behavior is more important than some narrow-case convenience.

Re: visual-line-mode tweaks

[Stefan Monnier]

> I think it's fine if minor modes _interact_ in some way that helps the
> user, but I think such interaction should be dynamic (so for instance,
> if I turn visual-line-mode off again, auto-filling should once again be
> enabled; one could do this by saving previous state or whatever, but
> that gets messy and flaky).

Messy and flaky and indeed some of the words that come to mind.

> How about having auto-fill-mode be a nop when visual-line-mode is
> enabled (so the change would be to auto-fill-mode instead of
> visual-line-mode)?

That just moves the problem.  I'd rather live with the current situation
where the problems are a logical consequence of the user's configuration
rather than the result of magic DWIM behavior.


        Stefan

Re: visual-line-mode tweaks

[Davis Herring]

> (1) Maybe visual-line-mode should turn off auto-fill-mode -- it's
> annoying to have your lines truncated physically when editing a file
> that intentionally uses a line-per-paragraph, and it's very common for
> auto-fill mode to be turned on by default.

I don't think it's a good idea to make it automatic, because one might
have some very long lines that one likes to peruse/edit with v-l-m and yet
be writing text that isn't meant to be line-per-para.

So, I would suggest adding a convenience command: perhaps
`visual-line-nofill'.  If v-l-m were off, it would turn it on and turn off
auto-fill-mode.  Otherwise, it would turn off v-l-m and turn on a-f-m. 
(The downside would be that two invocations of the command would not be a
no-op, but would instead set a-f-m to the opposite of your original v-l-m
setting.  I doubt anyone would be harmed, but that's why I gave it a name
not ending in "mode".)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: visual-line-mode tweaks

[Andrey Paramonov]

> (1) Maybe visual-line-mode should turn off auto-fill-mode -- it's
> annoying to have your lines truncated physically when editing a file
> that intentionally uses a line-per-paragraph, and it's very common for
> auto-fill mode to be turned on by default.
> 

Please do not do so. I'm used to formatting files physically, but I always have
visual-line-mode on as well. The latter helps so much for occasional
side-by-side Ediff on my narrow display.

Andrey Paramonov