Re: visual-line-mode and line wrapping

[Stefan Monnier <monnier@iro.umontreal.ca>]

> There's clearly desire for it.  Otherwise Lennart wouldn't have created
> that wrap fill mode.  Screens are getting wider so having lines of 200
> chars is painful to read.

You're preaching to the choir here (why do you think we have an "80
columns max" limit on C and Elisp code?).
But some people have been using >=1600 horizontal pixels for more than
10 years and that's not been a problem.  The real problem is not that
screens are getting larger, but that people don't have to pay real money
for that real-estate any more, so they don't care about using
it efficiently, and they end up suffering from their sloppiness.

I think that adjusting margins is an absurd waste of screen real-estate,
but at least (compared to your suggestion) it doesn't leave the fringe
icons far away from the text, so I think it's a better solution than
a wrap-width.  Of course, splitting windows is an even better solution.

> Using fringes or margins (now that I have tried it and I can imagine how
> Lennart implement his mode) are all workarounds and they are not much
> different than opening up a frame with the desired width but then it is
> a waste of screen estate and it has impact on productivity.

How would a wrap-width waste less screen estate or have less impact
on productivity?

>> You can also split the window to set its width as desired. That will let
>> you use the extra horizontal space for something useful.
> This is also another workaround,

Not at all.  And it's additionally a first step to working more efficiently.

> The thing is very easy to lose the setup, C-x 1, switch buffer etc etc.

Ah, now you're talking.  Sadly for your two examples, sadly, I don't know
what to tell you:
- why would you do C-x 1 in a "whole screen" Emacs frame?
- switch-to-buffer is not a problem as long as all your buffers use the
  same width.  Hence the "80 columns" rule.
But indeed window management is something that requires improvement.
Better UI to access and manipulate window configurations might be
a good solution.

But also, we could introduce a buffer-local var "natural-width" which
would be similar to wrap-width but would not directly control anything
related to display: it would simply declare that the buffer's content
was formatted with the intention of seeing/editing it in a buffer of
that width.  Then the window-management (via things like
fit-window-to-buffer or by resizing margins if you so prefer) could
better automatically resize windows, so that switch-to-buffer could DTRT
when switching between buffers of different "natural-width".
The only problem I have with that, is that there are very few good
reasons to set natural-width to anything significantly different from 80
since it is related not so much to computer technology as to the human's
vision system.


        Stefan