visual-line-mode and line wrapping

visual-line-mode and line wrapping

[Leo]

Hello,

In the discussion of the trashbin feature, visual-line-mode came up. It
seems many of us would like it to be able to wrap lines at a position
other than the window edge.

I wonder if someone has a patch to do this? Thanks. The feature would be
very useful to me at the moment.

Cheers,
Leo

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Mon, May 24, 2010 at 4:09 PM, Leo <sdl.web@gmail.com> wrote:
> Hello,
>
> In the discussion of the trashbin feature, visual-line-mode came up. It
> seems many of us would like it to be able to wrap lines at a position
> other than the window edge.
>
> I wonder if someone has a patch to do this? Thanks. The feature would be
> very useful to me at the moment.


You got my suggestion in the other thread. Is there anything wrong
with that if you need it now?

Re: visual-line-mode and line wrapping

[Leo]

On 2010-05-24 15:12 +0100, Lennart Borgman wrote:
> You got my suggestion in the other thread. Is there anything wrong
> with that if you need it now?

You mean using two fat fringes? It has some unpleasant visual impact.

Leo

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Mon, May 24, 2010 at 5:08 PM, Leo <sdl.web@gmail.com> wrote:
> On 2010-05-24 15:12 +0100, Lennart Borgman wrote:
>> You got my suggestion in the other thread. Is there anything wrong
>> with that if you need it now?
>
> You mean using two fat fringes? It has some unpleasant visual impact.


It is not fringes that are changed. It is only the margins. But you
see the fringes more since they are inside the margins.

What is it you do not like? You can change the fringes, try

  M-x fringe-mode

Re: visual-line-mode and line wrapping

[Leo]

On 2010-05-24 16:29 +0100, Lennart Borgman wrote:
> It is not fringes that are changed. It is only the margins. But you
> see the fringes more since they are inside the margins.

Could you paste a screenshot somewhere so people can see what it's like?

thanks.

Leo

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Mon, May 24, 2010 at 6:42 PM, Leo <sdl.web@gmail.com> wrote:
> On 2010-05-24 16:29 +0100, Lennart Borgman wrote:
>> It is not fringes that are changed. It is only the margins. But you
>> see the fringes more since they are inside the margins.
>
> Could you paste a screenshot somewhere so people can see what it's like?


Why not do that yourself? Then you can tell what is wrong.

Re: visual-line-mode and line wrapping

[Stefan Monnier]

> In the discussion of the trashbin feature, visual-line-mode came up.
> It seems many of us would like it to be able to wrap lines at
> a position other than the window edge.

I still haven't heard any good argument for it, as compared to using
wide fringes, wide margins, or by splitting windows.

I do think it could make sense in one case: when you want the
wrap-width to be larger than the window-width.  But AFAICT nobody has
asked for that yet.


        Stefan

Re: visual-line-mode and line wrapping

[Leo]

On 2010-05-24 18:34 +0100, Stefan Monnier wrote:
>> In the discussion of the trashbin feature, visual-line-mode came up.
>> It seems many of us would like it to be able to wrap lines at
>> a position other than the window edge.
>
> I still haven't heard any good argument for it, as compared to using
> wide fringes, wide margins, or by splitting windows.

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. Would be nice if 'visual-line-mode' gives user
an option to set a maximum width.

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.

> I do think it could make sense in one case: when you want the
> wrap-width to be larger than the window-width.  But AFAICT nobody has
> asked for that yet.
> 
> 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, something I have been doing myself for
quite a while now with this tiny function.

(defun adhoc-workspace-setup ()
  (interactive)
  (delete-other-windows (get-largest-window))
  (save-selected-window
    (split-window-horizontally (floor (* 0.6 (frame-parameter nil
  'width))))
    (switch-to-buffer-other-window nil t)))

The thing is very easy to lose the setup, C-x 1, switch buffer etc etc.
If I save the setup to a register it also restores the point, something
quite annoying when writing.

>         Stefan

Leo

Re: visual-line-mode and line wrapping

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> 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.

Implementing a wrap margin creates exactly the same waste of screen
estate.  Functionally, the two are equivalent.

Re: visual-line-mode and line wrapping

[Leo]

On 2010-05-24 20:31 +0100, Chong Yidong wrote:
>> 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.
>
> Implementing a wrap margin creates exactly the same waste of screen
> estate.  Functionally, the two are equivalent.

It might be the case for that buffer alone but the experience would be
different if you consider other activities while editing that buffer ie
switching to buffers, splitting windows etc. See this screenshot:
http://imagebin.org/98184. Basically I want to be able to put a cap on
the line length so that it won't go insanely long and make reading
painful.

Cheers.

Leo

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Mon, May 24, 2010 at 9:53 PM, Leo <sdl.web@gmail.com> wrote:
> On 2010-05-24 20:31 +0100, Chong Yidong wrote:
>>> 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.
>>
>> Implementing a wrap margin creates exactly the same waste of screen
>> estate.  Functionally, the two are equivalent.
>
> It might be the case for that buffer alone but the experience would be
> different if you consider other activities while editing that buffer ie
> switching to buffers, splitting windows etc. See this screenshot:
> http://imagebin.org/98184. Basically I want to be able to put a cap on
> the line length so that it won't go insanely long and make reading
> painful.


It seems like you think you are missing something in my
implementation, but I found it hard to understand exactly what you are
missing. Could you perhaps explain?

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Mon, May 24, 2010 at 9:31 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Leo <sdl.web@gmail.com> writes:
>
>> 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.
>
> Implementing a wrap margin creates exactly the same waste of screen
> estate.  Functionally, the two are equivalent.


I think there are some small functional differences:

- Using my implementation (i.e. setting margins) puts the fringes next
to the text. I think that is more useful but maybe someone else does
not.
- Just wrapping would leave the fringes further away.
- Also if a wrap margin was implemented that would have to be changed
dynamically according to window width. (Natural, of course.)

However it would be useful to be able to turn of fringes per buffer or window.

Leo, to make it easier for myself to stand the fringes I have
implemented something I call better-fringes-mode ( ;-) ). Did you try
that?

Re: visual-line-mode and line wrapping

[Leo]

On 2010-05-24 20:58 +0100, Lennart Borgman wrote:
> I think there are some small functional differences:
>
> - Using my implementation (i.e. setting margins) puts the fringes next
> to the text. I think that is more useful but maybe someone else does
> not.

I hardly pay attention to fringes because I also run emacs in a terminal
where no fringes present.

> - Just wrapping would leave the fringes further away.

This is consistent.

> - Also if a wrap margin was implemented that would have to be changed
> dynamically according to window width. (Natural, of course.)

I don't know how much c-code would be required if we were to offer a
'maximum-visual-line-width' option here. The reality is there are long
lines from email clients (Apple Mail for example), documents from other
editors that you might need to collaborate with and situations where
adding hard new lines (as in fill-paragraph) is not allowed. So we have
to deal with them.

> However it would be useful to be able to turn of fringes per buffer or window.

Setting margin or fringes changes how window splits it is not that
transparent. basically you enter a special mode, where window might
split horizontally now splits vertically or vice versa.

> Leo, to make it easier for myself to stand the fringes I have
> implemented something I call better-fringes-mode ( ;-) ). Did you try
> that?

No but I'd be happy to try it out.

Leo

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Mon, May 24, 2010 at 10:27 PM, Leo <sdl.web@gmail.com> wrote:
>
> I don't know how much c-code would be required if we were to offer a
> 'maximum-visual-line-width' option here.


That and quite a bit more is already available in my implementation.
It would be nice to understand why you are asking for it.

Re: visual-line-mode and line wrapping

[Johan Bockgård]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> - Using my implementation (i.e. setting margins) puts the fringes next
> to the text. I think that is more useful but maybe someone else does
> not.

Then just set `fringes-outside-margins'.

Re: visual-line-mode and line wrapping

[Stefan Monnier]

> 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

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Mon, May 24, 2010 at 10:26 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> 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.


There is always more than one view ;-)

One reason I implemented `wrap-to-fill-column' was that I wanted
something similar to "dark room", "write room" or whatever it is
called in different implementations. I.e. a view on the screen with
not to much disturbing things. Some people benefits from this (though
I am not so sure I am one of those ;-) ).

Another reason is that my view of Emacs' contents really is virtual. I
quickly switch views in my hunt for different details. Then I
sometimes find it good to have the contents in not too long lines on
the screen without having to fit the windows. (I use this more often
in org-mode than in other modes.)

Re: visual-line-mode and line wrapping

[Sean Sieger]

Lennart Borgman <lennart.borgman@gmail.com> writes:

    On Mon, May 24, 2010 at 10:26 PM, Stefan Monnier
    <monnier@iro.umontreal.ca> wrote:
    >
    > 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.


    There is always more than one view ;-)

    One reason I implemented `wrap-to-fill-column' was that I wanted
    something similar to "dark room", "write room" or whatever it is
    called in different implementations. I.e. a view on the screen with
    not to much disturbing things. Some people benefits from this (though
    I am not so sure I am one of those ;-) ).

I finally looked into those terms you've been mentioning (dark- and
writeroom) and a screenshot that I saw ... I guess I don't really see
the problem here ... has been effected by:

(defun full-screen-left-margin ()
  (interactive)
  (set-window-margins nil 25))
(global-set-key [f12] 'full-screen-left-margin)
(defun restored-screen-left-margin ()
  (interactive)
  (set-window-margins nil 0))
(global-set-key [f9] 'restored-screen-left-margin)

I don't like the f9 restore but f10 and f11 already being what they are,
well.

    Another reason is that my view of Emacs' contents really is virtual. I
    quickly switch views in my hunt for different details. Then I
    sometimes find it good to have the contents in not too long lines on
    the screen without having to fit the windows. (I use this more often
    in org-mode than in other modes.)

I have been using 12-inch lcd notebooks for a decade and /when I want to
focus on reading or writing/, I do f11, filling my little display with a
black background; f12, bumping the filled text to the center of the
display and I'm done.

I know this doesn't address a lot of what you guys are discussing, but I
just wanted to illustrate a, albeit simple, use of screen estate.

Re: visual-line-mode and line wrapping

[Leo]

On 2010-05-24 21:26 +0100, Stefan Monnier wrote:
> 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 have little of this in mind when proposing this feature.

It is more about if a long document has to be written with each
paragraph in one single line, how to make the editing slightly more
tolerable when one chooses to use visual-line-mode. Think of using emacs
as a poor word processor if you like.

Anyway, let's move on, let's forget about this.

Leo

Re: visual-line-mode and line wrapping

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> In the discussion of the trashbin feature, visual-line-mode came up.
>> It seems many of us would like it to be able to wrap lines at
>> a position other than the window edge.
>
> I still haven't heard any good argument for it, as compared to using
> wide fringes, wide margins, or by splitting windows.
>
> I do think it could make sense in one case: when you want the
> wrap-width to be larger than the window-width.  But AFAICT nobody has
> asked for that yet.

I thought I've said such in the past, but in case not:

One problem with the "fringe/margin approach" is that it always exactly
tracks physical window size, which is sometimes annoying.  For instance,
it would be nice to have word-wrapping that wraps to 80 or 72 columns
without having to result to multiple word-wrapping mechanisms (e.g., the
old lisp-based modes).

Also, it would be nice if one could bound the width used for wrapping so
that when a window becomes wider than a certain size, the wrapping width
would stick at some maximum -- this is because extremely wide paragraphs
can be hard to read.  Similarly, when windows become narrow than some
width, it would be nice if wrapping actually respected some _minimum_
width, so that you don't end up with the text in a single narrow
vertical line (the text is probably unreadable either way, but at least
with the bounded-width version, you can get a more sensible idea of the
document structure).

[Not commenting on the technical difficulty of doing these, just saying
there are reasonable use-cases.]

-Miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: visual-line-mode and line wrapping

[João Távora]

On Tue, May 25, 2010 at 9:37 AM, Miles Bader <miles@gnu.org> wrote:

> One problem with the "fringe/margin approach" is that it always exactly
> tracks physical window size, which is sometimes annoying.  For instance,
> it would be nice to have word-wrapping that wraps to 80 or 72 columns
> without having to result to multiple word-wrapping mechanisms (e.g., the
> old lisp-based modes).

Following this discussion I hacked up a darkroom-mode with the "fringe/margin"
approach and am quite happy with it. Try it out, it's very small (and
possibly buggy :-)

 http://pastebin.com/kcmuGjy8

I don't understand what exactly people are requesting that can't be
done with elisp.
My two cents, bye!
Joao

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Tue, May 25, 2010 at 12:05 PM, João Távora <joaotavora@gmail.com> wrote:
> On Tue, May 25, 2010 at 9:37 AM, Miles Bader <miles@gnu.org> wrote:
>
>> One problem with the "fringe/margin approach" is that it always exactly
>> tracks physical window size, which is sometimes annoying.  For instance,
>> it would be nice to have word-wrapping that wraps to 80 or 72 columns
>> without having to result to multiple word-wrapping mechanisms (e.g., the
>> old lisp-based modes).
>
> Following this discussion I hacked up a darkroom-mode with the "fringe/margin"
> approach and am quite happy with it. Try it out, it's very small (and
> possibly buggy :-)
>
>  http://pastebin.com/kcmuGjy8

You are welcome to try to enhance the version I have if you want to.

Re: visual-line-mode and line wrapping

[João Távora]

>>
>>  http://pastebin.com/kcmuGjy8
>
> You are welcome to try to enhance the version I have if you want to.
>
Thanks, I'm perfectly happy with 'visual-line-mode' +
'set-window-margins' which is basically what darkroom.el does in a few
lines (I've since made it a minor-mode).

I don't understand why, but 'wrap-line-to-fill-column'  seems to do a
lot more than that, including font-lock and stuff. Also it requires
'mumamo' which I don't use.

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Tue, May 25, 2010 at 9:37 AM, Miles Bader <miles@gnu.org> wrote:
>
> Also, it would be nice if one could bound the width used for wrapping so
> that when a window becomes wider than a certain size, the wrapping width
> would stick at some maximum -- this is because extremely wide paragraphs
> can be hard to read.

This is in the solution I mentioned.

> Similarly, when windows become narrow than some
> width, it would be nice if wrapping actually respected some _minimum_
> width, so that you don't end up with the text in a single narrow
> vertical line (the text is probably unreadable either way, but at least
> with the bounded-width version, you can get a more sensible idea of the
> document structure).

I never thought of that. Will add it.

Re: visual-line-mode and line wrapping

[Stefan Monnier]

> Also, it would be nice if one could bound the width used for wrapping so
> that when a window becomes wider than a certain size, the wrapping width
> would stick at some maximum -- this is because extremely wide paragraphs
> can be hard to read.  Similarly, when windows become narrow than some
> width, it would be nice if wrapping actually respected some _minimum_
> width, so that you don't end up with the text in a single narrow
> vertical line (the text is probably unreadable either way, but at least
> with the bounded-width version, you can get a more sensible idea of the
> document structure).

I'd be fine with a "wrap-width" if it's a buffer-local variable that
completely overrides the window-width wrapping, so that the wrapping is
purely determined by the buffer and not by the window.
This would mean that in narrow windows, long lines would be wrapped
*and* truncated.


        Stefan

Re: visual-line-mode and line wrapping

[Lennart Borgman]

On Tue, May 25, 2010 at 4:04 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Also, it would be nice if one could bound the width used for wrapping so
>> that when a window becomes wider than a certain size, the wrapping width
>> would stick at some maximum -- this is because extremely wide paragraphs
>> can be hard to read.  Similarly, when windows become narrow than some
>> width, it would be nice if wrapping actually respected some _minimum_
>> width, so that you don't end up with the text in a single narrow
>> vertical line (the text is probably unreadable either way, but at least
>> with the bounded-width version, you can get a more sensible idea of the
>> document structure).
>
> I'd be fine with a "wrap-width" if it's a buffer-local variable that
> completely overrides the window-width wrapping, so that the wrapping is
> purely determined by the buffer and not by the window.
> This would mean that in narrow windows, long lines would be wrapped
> *and* truncated.


Sounds nice. This is what I have been trying to emulate. (Though the
truncation part is not possible to emulate.)

BTW, I just added winsize-fit-window-to-fill-column. Should not
something like that be in Emacs?

RE: visual-line-mode and line wrapping

[Drew Adams]

L> BTW, I just added winsize-fit-window-to-fill-column. Should not
L> something like that be in Emacs?

D> IOW, I would think that in some cases a user would want 
D> window fitting to accompany the text wrapping: You want
D> text to be wrapped for easy reading (not too wide), and
D> you want the window to be fit to that text, to not waste
D> real estate to the right of the wrapped text.

Seems we sometimes think alike. ;-)


[On a similar topic - with the same aim of saving window real estate, I sent a
patch a year ago to let users _optionally_ fit the window to text that has been
resized.

Currently, if you shrink the text, then you get wasted space at the right.  The
patch lets you (optionally) automatically resize the window to recuperate that
space for adjacent windows.  No one was interested in the patch at that time.
Maybe you would like to take another look? ;-)

Thread `face-remap.el patch to resize window':
http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00414.html]

RE: visual-line-mode and line wrapping

[Drew Adams]

> > Also, it would be nice if one could bound the width used 
> > for wrapping so that when a window becomes wider than a
> > certain size, the wrapping width would stick at some maximum
> > -- this is because extremely wide paragraphs can be hard to
> > read.  Similarly, when windows become narrow than some
> > width, it would be nice if wrapping actually respected some 
> > _minimum_ width, so that you don't end up with the text in
> > a single narrow vertical line...
> 
> I'd be fine with a "wrap-width" if it's a buffer-local variable that
> completely overrides the window-width wrapping, so that the 
> wrapping is purely determined by the buffer and not by the window.
> This would mean that in narrow windows, long lines would be wrapped
> *and* truncated.

Not to take away from the utility of the wrapping being discussed, or to divert
the discussion, but if it is sometimes useful to be able to wrap that way for
the reasons given, I would think that in at least some of those use cases users
would also want to recuperate the "wasted" window width by automatically
resizing the window.

IOW, I would think that in some cases a user would want window fitting to
accompany the text wrapping: You want text to be wrapped for easy reading (not
too wide), and you want the window to be fit to that text, to not waste real
estate to the right of the wrapped text.

Re: visual-line-mode and line wrapping

[Leo]

On 2010-05-25 15:04 +0100, Stefan Monnier wrote:
>> Also, it would be nice if one could bound the width used for wrapping
>> so that when a window becomes wider than a certain size, the wrapping
>> width would stick at some maximum -- this is because extremely wide
>> paragraphs can be hard to read. Similarly, when windows become narrow
>> than some width, it would be nice if wrapping actually respected some
>> _minimum_ width, so that you don't end up with the text in a single
>> narrow vertical line (the text is probably unreadable either way, but
>> at least with the bounded-width version, you can get a more sensible
>> idea of the document structure).
>
> I'd be fine with a "wrap-width" if it's a buffer-local variable that
> completely overrides the window-width wrapping, so that the wrapping
> is purely determined by the buffer and not by the window. This would
> mean that in narrow windows, long lines would be wrapped *and*
> truncated.

That will do for me too.

Yidong has said something like this in 2009:
http://article.gmane.org/gmane.emacs.devel/114706/match=visual+line+mode

I wonder if he has a patch in his local branch.

Thanks.

Leo

Re: visual-line-mode and line wrapping

[Uday S Reddy]

On 5/24/2010 6:34 PM, Stefan Monnier wrote:
>> In the discussion of the trashbin feature, visual-line-mode came up.
>> It seems many of us would like it to be able to wrap lines at
>> a position other than the window edge.
>
> I still haven't heard any good argument for it, as compared to using
> wide fringes, wide margins, or by splitting windows.

Hi Stefan, My use for it would be that, occasionally, I want to enlarge the Emacs window for some purpose or the other.  (For instance, to see more of email summary lines.  Or, even the mode line.  Do you use which-func-mode?)

When you do that, it would be nice if the wrapped lines don't become ridiculously wide at the same time.

It seems just natural. Just like we have a `fill-column' for filled text, we have a `wrap-column' for wrapped text.

My two cents.

Cheers,
Uday

Re: visual-line-mode and line wrapping

[Stephen J. Turnbull]

Uday S Reddy writes:

 > Hi Stefan, My use for it would be that, occasionally, I want to
 > [vertically] enlarge the Emacs window for some purpose or the other.

Sure.  My window manager has a maximize vertically option (button 2 on
the maximize button).

Re: visual-line-mode and line wrapping

[Uday S Reddy]

On 5/25/2010 12:48 PM, Stephen J. Turnbull wrote:
> Uday S Reddy writes:
>
>   >  Hi Stefan, My use for it would be that, occasionally, I want to
>   >  [vertically] enlarge the Emacs window for some purpose or the other.
>
> Sure.  My window manager has a maximize vertically option (button 2 on
> the maximize button).

No, I meant enlarge horizontally.  With my standard email summary format, 80 columns turn out to produce summary lines like this:

->2727 N  5/25  Hans Hüttel          11376-  [TYPES/announce] Book announcement:
   2662    5/23  Ulrich Müller         6629-  [Bug 584616] [NEW] vm-8.1.1 paralle
     51    5/21  Eli Zaretskii         3813-     Re: bug#6229: 23.2; Cancel debug

Most of the time they turn out fine.  The initial bits of the subject line are enough to tell me what is going on.  But sometimes they aren't.  So, horizontal enlargement of the frame is warranted.

I think the more general point is that an Emacs frame might contain some windows that have wrapped text and others that have unwrapped text.  We need to balance the needs of both.

Cheers,
Uday

RE: visual-line-mode and line wrapping

[Drew Adams]

> >   >  My use for it would be that, occasionally, I want to
> >   >  [vertically] enlarge the Emacs window for some purpose 
> >   >  or the other.
> >
> > Sure.  My window manager has a maximize vertically option 
> > (button 2 on the maximize button).
> 
> No, I meant enlarge horizontally.

FWIW, my library `frame-cmds.el' has commands to maximize the frame
horizontally, vertically, or both.  The commands leave room for the MS Windows
task bar and a standalone minibuffer frame, if present.  I put these commands,
along with other frame commands (tiling, fitting) on a menu-bar `Frames' menu.

http://www.emacswiki.org/emacs/frame-cmds.el

Re: visual-line-mode and line wrapping

[Uday S Reddy]

On 5/25/2010 9:36 AM, Uday S Reddy wrote:

>
> Hi Stefan, My use for it would be that, occasionally, I want to enlarge
> the Emacs window for some purpose or the other. (For instance, to see
> more of email summary lines. Or, even the mode line. Do you use
> which-func-mode?)

Wanting to view a PDF document or some such wide object seems to be another legitimate reason to widen an Emacs frame.

Cheers,
Uday


> When you do that, it would be nice if the wrapped lines don't become
> ridiculously wide at the same time.
>
> It seems just natural. Just like we have a `fill-column' for filled
> text, we have a `wrap-column' for wrapped text.
>
> My two cents.
>
> Cheers,
> Uday
>
>
>
>

Re: visual-line-mode and line wrapping

[Stefan Monnier]

>> Hi Stefan, My use for it would be that, occasionally, I want to enlarge
>> the Emacs window for some purpose or the other. (For instance, to see
>> more of email summary lines. Or, even the mode line. Do you use
>> which-func-mode?)

> Wanting to view a PDF document or some such wide object seems to be
> another legitimate reason to widen an Emacs frame.

But a PDF document doesn't need wrapping.  And you can still split
a window if/when you switch from the PDF to something else.

In any case, I'd be interested in a patch which adds some kind of
wrap-width buffer-local variable, but it needs to also be obeyed in
windows that are narrower than wrap-width.


        Stefan

Re: visual-line-mode and line wrapping

[MON KEY]

> You're preaching to the choir here (why do you think we have an "80
> columns max" limit on C and Elisp code?).

This limit has really been on my mind lately. FTMP I agree with the
rationale, its benefits, and am (in general) a strong advocate.

However, something I find really disconcerting (and biased) is that
there is a fundamental difference between (E)lisp code and C code, and
the 80 col limit is far more C centric. Moreover, the convention is
not particularly friendly to code that employs features from the CL
package. Likewise, in the absence of _real_ namespacing third party
fncns must extend by at least two extra tokens for each def* in order
not to step on Emacs' core fncns. In the aggregate these factors can
make it particularly difficult for third party code to meet with the
80 col rule. Following are examples of moderately sized lambda lists
(with IMHO unreasonably truncated arg names):

A conventional Elisp fncn from Emacs' lisp/* directory:

(defun elisp-fun (arg1 arg2 &optional arg3 &rest arg4)
^^^^^!^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^^^^^!^^^^^^^^^^^!
     5        15    21   26             41          53

Same Elisp fncn from Emacs' lisp/* directory with CL features:

(defun* elisp-fun (arg1 arg2 &optional (arg3 arg3-dflt) &rest arg4)
^^^^^^!^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^^^^^^!^^^^^^^^^^!^^^^^^^^^^^!
      6        16    22   27              44         54          66

Same(ish) but w/ CL packages keywords feature:
(defun* elisp-fun (arg1 arg2 &rest arg4 &key arg3 arg3-alt)
^^^^^^!^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^!^^^^^^^^^!^^^^^^^^^!
      6        16    22   27         38        47        58

User function with four token textual namespace:
(defun usr-elisp-fun (arg1 arg2 &optional arg3 &rest arg4)
^^^^^!^^^^^^^^^^^^^!^^^^^!^^^^!^^^^^^^^^^^^^^!^^^^^^^^^^^!
     5            15    25   30             45          57

It would be an interesting exercise to do a count of the number of defun,
defsubst,, defmacro forms in lisp/* which have their parameter
list split over two or more lines to accommodate the 80 limit.

--
/s_P\