Display-based word wrapping

Display-based word wrapping

[Chong Yidong]

I have been studying Kim Storm's display-based word wrapping code.  I
believe it's pretty safe, and suitable for inclusion into the Emacs 23
release (probably turned off by default).

The original patch included a `wrap-column' variable, but I'd like to
modify this to use `truncate-lines' instead, as shown below.  This would
mean that word wrap always uses the right window edge as a wrap column.
Any objections?



truncate-lines is a variable defined in `C source code'.

Documentation:
Whether lines longer than the window width are truncated.
If the value is nil or `word-wrap', long lines are displayed using
continuation lines.  If nil, the wrapping occurs at the right window
edge.  If `word-wrap', it occurs at the rightmost space or tab
character, if possible.

Any other non-nil value means to give each line of text just one
screen line, truncating long lines at the right window edge.

Note that this is overridden by the variable
`truncate-partial-width-windows' if that variable is non-nil
and this buffer is not full-frame width.

Re: Display-based word wrapping

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> I have been studying Kim Storm's display-based word wrapping code.  I
> believe it's pretty safe, and suitable for inclusion into the Emacs 23
> release (probably turned off by default).
> 
> The original patch included a `wrap-column' variable, but I'd like to
> modify this to use `truncate-lines' instead, as shown below.  This would
> mean that word wrap always uses the right window edge as a wrap column.
> Any objections?

Yes, I would find this quite impractical to not have a `wrap-column'. I 
do not want to resize windows just to edit text in a comfortable way. 
(Wouldn't it also make it impossible to use the "darkroom" editing some 
people have suggested?)

Is there any reason not to have a wrap-column? If that is nil I would 
suggest falling back to the window edge.

> truncate-lines is a variable defined in `C source code'.
> 
> Documentation:
> Whether lines longer than the window width are truncated.
> If the value is nil or `word-wrap', long lines are displayed using
> continuation lines.  If nil, the wrapping occurs at the right window
> edge.  If `word-wrap', it occurs at the rightmost space or tab
> character, if possible.
> 
> Any other non-nil value means to give each line of text just one
> screen line, truncating long lines at the right window edge.
> 
> Note that this is overridden by the variable
> `truncate-partial-width-windows' if that variable is non-nil
> and this buffer is not full-frame width.
> 
> 
> 

Re: Display-based word wrapping

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> I have been studying Kim Storm's display-based word wrapping code.  I
> believe it's pretty safe, and suitable for inclusion into the Emacs 23
> release (probably turned off by default).
>
> The original patch included a `wrap-column' variable, but I'd like to
> modify this to use `truncate-lines' instead, as shown below.  This would
> mean that word wrap always uses the right window edge as a wrap column.
> Any objections?
>
>
>
> truncate-lines is a variable defined in `C source code'.
>
> Documentation:
> Whether lines longer than the window width are truncated.
> If the value is nil or `word-wrap', long lines are displayed using
> continuation lines.  If nil, the wrapping occurs at the right window
> edge.  If `word-wrap', it occurs at the rightmost space or tab
> character, if possible.

How about not using word-wrap, but rather integers?  A positive integer
indicates the column before the wrap should occur, with negative
integers counting from the right margin?  That makes it possible to
specify a fixed wrap position if really wanted.  Also the
truncate-partial-window-width override should have the same meaning and
take precedence if non-nil.

I am not sure this flexibility is needed, though.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Display-based word wrapping

[Chong Yidong]

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

> Chong Yidong wrote:
>> I have been studying Kim Storm's display-based word wrapping code.  I
>> believe it's pretty safe, and suitable for inclusion into the Emacs 23
>> release (probably turned off by default).
>>
>> The original patch included a `wrap-column' variable, but I'd like to
>> modify this to use `truncate-lines' instead, as shown below.  This would
>> mean that word wrap always uses the right window edge as a wrap column.
>> Any objections?
>
> Yes, I would find this quite impractical to not have a
> wrap-column'. I do not want to resize windows just to edit text in a
> comfortable way.

Introducing a wrap-column variable is almost exactly the same as
changing the window width, or equivalently the right fringe width.  I
don't see the advantage in further complicating this part of the code to
introduce a new way to do the same thing.

It would be easier, for example, to introduce a separate patch that
automatically adjusts the right fringe so that the editable area has a
certain width.

> (Wouldn't it also make it impossible to use the "darkroom" editing
> some people have suggested?)

I don't know what this is about.

Re: Display-based word wrapping

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Chong Yidong wrote:
>>> I have been studying Kim Storm's display-based word wrapping code.  I
>>> believe it's pretty safe, and suitable for inclusion into the Emacs 23
>>> release (probably turned off by default).
>>>
>>> The original patch included a `wrap-column' variable, but I'd like to
>>> modify this to use `truncate-lines' instead, as shown below.  This would
>>> mean that word wrap always uses the right window edge as a wrap column.
>>> Any objections?
>> Yes, I would find this quite impractical to not have a
>> wrap-column'. I do not want to resize windows just to edit text in a
>> comfortable way.
> 
> Introducing a wrap-column variable is almost exactly the same as
> changing the window width, or equivalently the right fringe width.  I
> don't see the advantage in further complicating this part of the code to
> introduce a new way to do the same thing.

I thought it would be similar to fill-column, but I am beginning to see 
your point.

> It would be easier, for example, to introduce a separate patch that
> automatically adjusts the right fringe so that the editable area has a
> certain width.

 From a users point of view I think it is essential that it is easy to 
turn this on/off.

>> (Wouldn't it also make it impossible to use the "darkroom" editing
>> some people have suggested?)
> 
> I don't know what this is about.

Here is a description, it is about distraction-free writing:

http://www.emacswiki.org/cgi-bin/wiki/WriteRoom
http://www.martyn.se/code/emacs/darkroom-mode/darkroommode-screenshot.png

Re: Display-based word wrapping

[Stefan Monnier]

> How about not using word-wrap, but rather integers?  A positive integer

I don't see any need for it: the boundary is a hard one, so nothing will
ever be displayed poast it, so you may as well place the window edge
there, which works just fine without introducing anything new.

We're only talking about adding word-wrap additionally to char-wrap.

> truncate-partial-window-width override should have the same meaning and
> take precedence if non-nil.

For truncate-partial-window-width OTOH, I think it would make sense to
allow it to be an integer to mean "truncate if the window is less than
this number".  But that's unrelated to word-wrapping,


        Stefan

Re: Display-based word wrapping

[David Reitter]

On 22 Jun 2008, at 21:33, Chong Yidong wrote:
>>
>> Yes, I would find this quite impractical to not have a
>> wrap-column'. I do not want to resize windows just to edit text in a
>> comfortable way.
>
> Introducing a wrap-column variable is almost exactly the same as
> changing the window width, or equivalently the right fringe width.  I
> don't see the advantage in further complicating this part of the  
> code to
> introduce a new way to do the same thing.

How does the specification of a wrap column work with variable-width  
fonts?

Re: Display-based word wrapping

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> On 22 Jun 2008, at 21:33, Chong Yidong wrote:
>>>
>>> Yes, I would find this quite impractical to not have a
>>> wrap-column'. I do not want to resize windows just to edit text in a
>>> comfortable way.
>>
>> Introducing a wrap-column variable is almost exactly the same as
>> changing the window width, or equivalently the right fringe width.  I
>> don't see the advantage in further complicating this part of the code
>> to introduce a new way to do the same thing.
>
> How does the specification of a wrap column work with variable-width
> fonts?

In the current patch that I'm working with, the wrap occurs at the
window edge, calculated using pixel positions.  So it DTRT with respect
to variable-width fonts.

If a wrap-column is introduced, it will probably specify a number of
pixels equal to N standard-width columns.

Re: Display-based word wrapping

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> Also the truncate-partial-window-width override should have the same
> meaning and take precedence if non-nil.

I'm not sure how to handle truncate-partial-window-width.  It's true
that if word wrapping is to be useful, it shouldn't be turned off by
truncate-partial-window-width.

But if we change it as you suggest, the name of the variable no longer
really makes sense.  I think this variable was poorly designed.

The easiest thing to do is to change the default value of
truncate-partial-window-width to nil, and deprecate it.  But other
suggestions are welcome.

Re: Display-based word wrapping

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> truncate-partial-window-width override should have the same meaning and
>> take precedence if non-nil.
>
> For truncate-partial-window-width OTOH, I think it would make sense to
> allow it to be an integer to mean "truncate if the window is less than
> this number".  But that's unrelated to word-wrapping,

It's a good idea, and it's actually fairly closely related to
word-wrapping.  If truncate-partial-window-width is a sufficiently small
number, it wouldn't interfere with word wrap for fairly large-sized
windows.  For small windows, it would make sense to truncate instead of
word wrapping.

So maybe this is a good solution.

Re: Display-based word wrapping

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

On 22 Jun 2008, at 23:24, Chong Yidong wrote:

> If a wrap-column is introduced, it will probably specify a number of
> pixels equal to N standard-width columns.

OK, that would work.  But I see little need for it. 
   

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Display-based word wrapping

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> The original patch included a `wrap-column' variable, but I'd like to
> modify this to use `truncate-lines' instead, as shown below.  This would
> mean that word wrap always uses the right window edge as a wrap column.
> Any objections?

Yes -- window width is very often the wrong thing to use.  I want to be
able to wrap at say 72 columns and not have to resize my window to
achieve that effect.

Mainly this is because (1) I often want to have window-widths which are
far wider than what's reasonable for readable text (wiiiiide text is
very hard to read), and (2) also for readability I like having a ragged
right margin which gives a bit more whitespace than you would get with
window-edge wrapping (I find right-up-to-the-edge wrapping annoying).

Of course the window width makes a good upper bound, but there
absolutely should be a way for the user to control wrapping at a lesser
point.

[Also, whatever the discussion of defaults ends up turning up, it should
at least be _possible_ to have global setting which causes there to be
no indicators at all for display-time wrapped text.]

-Miles

-- 
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.

Re: Display-based word wrapping

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> The easiest thing to do is to change the default value of
> truncate-partial-window-width to nil, and deprecate it.  But other
> suggestions are welcome.

That seems quite absurd -- truncate-partial-window-width windows serves
a very good purpose in normal use, and surely you're not suggesting that
word-wrapping become a mandatory global default?!

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: Display-based word wrapping

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> It would be easier, for example, to introduce a separate patch that
> automatically adjusts the right fringe so that the editable area has a
> certain width.

No, that would be bad.  Fringes have a number of properties which would
make them unsuitable for use as a "wide wrapping margin".

Fringes are designed to relatively narrow, and are used for many
indicators.  Thus fringes are (1) visually distinguishable, (2) global,
and (3) have indicators in them even when normal line-wrapping isn't
being used.

So if I wanted to, say, wrap at 72 chars in an 80-char window, I _don't_
want an 8-char-wide colored band on the right, with all my indicators
shifted over (and I most certainly don't want an 8-char wide fringe in
every window!!!).  I want whitespace.  That's it.

-Miles

-- 
Road, n. A strip of land along which one may pass from where it is too
tiresome to be to where it is futile to go.

Re: Display-based word wrapping

[Stefan Monnier]

>>> truncate-partial-window-width override should have the same meaning and
>>> take precedence if non-nil.
>> 
>> For truncate-partial-window-width OTOH, I think it would make sense to
>> allow it to be an integer to mean "truncate if the window is less than
>> this number".  But that's unrelated to word-wrapping,

> It's a good idea, and it's actually fairly closely related to
> word-wrapping.  If truncate-partial-window-width is a sufficiently small
> number, it wouldn't interfere with word wrap for fairly large-sized
> windows.  For small windows, it would make sense to truncate instead of
> word wrapping.

> So maybe this is a good solution.

Solution to what?


        Stefan

Re: Display-based word wrapping

[Stefan Monnier]

> Yes -- window width is very often the wrong thing to use.  I want to be
> able to wrap at say 72 columns and not have to resize my window to
> achieve that effect.

That's a separate feature.  The same can be requested for char-wrapping
(and for line-truncation even).  So let's drop this from this thread,
which is about word-wrapping.


        Stefan

Re: Display-based word wrapping

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Yes -- window width is very often the wrong thing to use.  I want to be
>> able to wrap at say 72 columns and not have to resize my window to
>> achieve that effect.
>
> That's a separate feature.  The same can be requested for char-wrapping
> (and for line-truncation even).  So let's drop this from this thread,
> which is about word-wrapping.

Well as long as it's available, I don't care how it's categorized. :-)

But it is more important for word-wrapping, because AFAIUT, when
word-wrapping is used, wrapping is "the norm" -- you expect there to be
lots and lots of "wrapped" lines in normal text -- whereas the other
wrapping modes emacs traditionally supports are "exceptional" -- normal
text usually isn't expected to wrap, and if some does, it is a potential
problem indicator.

A similar argument applies to wrapping indicators:  For traditional
wrapping modes, it's Ok, and even useful, when wrapping indicators are
quite noticeable, because they usually indicate an exceptional
condition.  But for word wrapping, wrapping is the normal case, so more
care should be taken to make sure wrapping indicators [if any] are not
annoying.

-Miles

-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Re: Display-based word wrapping

[Stefan Monnier]

> A similar argument applies to wrapping indicators:  For traditional
> wrapping modes, it's Ok, and even useful, when wrapping indicators are
> quite noticeable, because they usually indicate an exceptional
> condition.  But for word wrapping, wrapping is the normal case, so more
> care should be taken to make sure wrapping indicators [if any] are not
> annoying.

IOW, word-wrapping will be a big time sink?
Yes, I definitely expect that: line-end indicators, visual-line
movement, ... and I'm sure people will find more things to wish
for afterwards (adaptive-fill-prefix anyone?)


        Stefan

Re: Display-based word wrapping

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> For truncate-partial-window-width OTOH, I think it would make sense to
>>> allow it to be an integer to mean "truncate if the window is less than
>>> this number".  But that's unrelated to word-wrapping,
>
>> It's a good idea, and it's actually fairly closely related to
>> word-wrapping.  If truncate-partial-window-width is a sufficiently small
>> number, it wouldn't interfere with word wrap for fairly large-sized
>> windows.  For small windows, it would make sense to truncate instead of
>> word wrapping.
>
>> So maybe this is a good solution.
>
> Solution to what?

To the problem of how to treat truncate-partial-window-width once
word-wrapping is available as a third option for long lines (the first
two options being line truncation and simple line continuation).

Instead of adding `word-wrap' as a new value for truncate-lines, let's
say we add a new per-buffer variable, `word-wrap', which if non-nil says
to wrap lines at word boundaries rather than the middle of words.  This
variable has no effect if lines are truncated instead of continued.
Then truncate-partial-window-width need not "care" about whether
non-truncation means simple line continuation or word wrapping.

Finally, by allowing truncate-partial-window-width to take integer
values as you suggested, and then setting the default to a number such
as 30, we can ensure that word wrapping can still take place for
reasonably-sized partial-width windows.

Re: Display-based word wrapping

[Miles Bader]

On Mon, Jun 23, 2008 at 11:03 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> A similar argument applies to wrapping indicators:  For traditional
>> wrapping modes, it's Ok, and even useful, when wrapping indicators are
>> quite noticeable, because they usually indicate an exceptional
>> condition.  But for word wrapping, wrapping is the normal case, so more
>> care should be taken to make sure wrapping indicators [if any] are not
>> annoying.
>
> IOW, word-wrapping will be a big time sink?
> Yes, I definitely expect that: line-end indicators, visual-line
> movement, ... and I'm sure people will find more things to wish
> for afterwards (adaptive-fill-prefix anyone?)

I'm not sure what your point is .. if you mean that we should add a
"simple" word-wrapping feature to the display engine first, ignoring
other features which make it usable for regular use, maybe you're
right.  I think many of those "time-sink" features are necessary for
it to be really usable in a way users expect, though, so we should at
least make a tentative plan to add them.

[Display-time word-wrapping is probably a nice thing, but I don't
think it's quite as simple as people often seem to assume it is --
devil, details, etc.]

The visual movement stuff may not be be necessary for "display only"
use -- e.g. in a Gnus article buffer -- and we probably want to just
turn off wrapping indicators in such usage.

-Miles

-- 
Frank Lloyd Wright  - "TV is chewing gum for the eyes."

Re: Display-based word wrapping

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> To the problem of how to treat truncate-partial-window-width once
> word-wrapping is available as a third option for long lines (the first
> two options being line truncation and simple line continuation).
>
> Instead of adding `word-wrap' as a new value for truncate-lines, let's
> say we add a new per-buffer variable, `word-wrap', which if non-nil
> says to wrap lines at word boundaries rather than the middle of words.
> This variable has no effect if lines are truncated instead of
> continued.  Then truncate-partial-window-width need not "care" about
> whether non-truncation means simple line continuation or word
> wrapping.
>
> Finally, by allowing truncate-partial-window-width to take integer
> values as you suggested, and then setting the default to a number such
> as 30, we can ensure that word wrapping can still take place for
> reasonably-sized partial-width windows.

So, any objections to this set of variables?

  word-wrap (default: nil)
  *Non-nil means to use word-wrapping for continuation lines.
  When word-wrapping is on, continuation lines are wrapped at the space
  or tab character nearest to the right window edge.
  If nil, continuation lines are wrapped at the right screen edge.

  This variable has no effect if long lines are truncated (see
  `truncate-lines' and `truncate-partial-width-windows').


  truncate-partial-width-windows (default: 35)
  Non-nil means truncate lines in windows with less than the frame width.
  For an integer value, truncate lines in each window with less than the
  full frame width, provided the window width is less than that integer;
  otherwise, respect the value of `truncate-lines'.

  For any other non-nil value, truncate lines in all windows with
  less than the full frame width.

  Nil means to respect the value of `truncate-lines'.


For now, I will not provide a way to change the column at which line
wrapping/continuation/truncation takes place, but I know how to do it
(it's a separate set of changes).

Re: Display-based word wrapping

[Stefan Monnier]

> I'm not sure what your point is .. if you mean that we should add a
> "simple" word-wrapping feature to the display engine first, ignoring
> other features which make it usable for regular use, maybe you're
> right.  I think many of those "time-sink" features are necessary for
> it to be really usable in a way users expect, though, so we should at
> least make a tentative plan to add them.

We don't have to ignore the other features, but those other features
have no impact on the display word-wrapping AFAICT, so we don't have to
discuss them right away in this thread and we can address them later on,
little by little.
After all, we've survived decades without word wrapping at all, so it's
not like we need it to work perfectly right away.

As for a plan:
1 - improve the fringe indicators so they can be turned off.
2 - visual movement.
3 - maybe add a pilcrow fringe indicator (the issue is obviously not
    the icon itself but the code that determines where to place it).

The order can be changed at will.


        Stefan

Re: Display-based word wrapping

[Stefan Monnier]

> To the problem of how to treat truncate-partial-window-width once
> word-wrapping is available as a third option for long lines (the first
> two options being line truncation and simple line continuation).

I see no problem here:

   truncate-partial-width-windows is a variable defined in `C source code'.
   Its value is t
   
   Documentation:
   *Non-nil means truncate lines in all windows less than full frame wide.
   Nil means to respect the value of `truncate-lines'.
   
   You can customize this variable.

The current docstring works just fine if we extend the semantics of
truncate-lines.  Nowhere does it say "takes the same kind of values as
`truncate-lines'".

My suggestion was trying to address the fact the above docstring seems
to assume that "frame wide" windows are somewhat special, whereas with
200x80 frames, you may want to consider an 80x80 window as being "large
enough" to not require truncation.


        Stefan

Display-based word wrapping

[Chong Yidong]

I've checked in Kim F. Storm's display-based word-wrapping patch, with
some modifications.  The word-wrapping is controlled by the `word-wrap'
per-buffer variable.  It is a form of continuation line, so e.g. will
not be performed if lines are truncated rather than continued.

The default is nil.  More work will have to be done to make this really
useful for editing documents with long lines: (i) the minor mode for
screen-based editing commands being discussed in another thread, (ii) a
way to change the continuation/wrapping/truncation margin, and (iii) a
way to customize the fringe indicators to avoid displaying tons of
continuation line indicators.

I have also changed truncate-partial-width-windows to accept integer
values specifying a window width below which to truncate lines, and
changed the default to 30.

I believe the patch should not affect the default behavior where
word-wrap is nil, but please be on the lookout.  Problem reports are
welcome.

Re: Display-based word wrapping

[Stefan Monnier]

> I've checked in Kim F. Storm's display-based word-wrapping patch, with
> some modifications.  The word-wrapping is controlled by the `word-wrap'
> per-buffer variable.  It is a form of continuation line, so e.g. will
> not be performed if lines are truncated rather than continued.

Why did you choose a separate variable rather than reusing truncate-lines?

> I have also changed truncate-partial-width-windows to accept integer
> values specifying a window width below which to truncate lines, and
> changed the default to 30.

Since the Emacs-22 default was t, I think a safer new default (other
than t) would be something around 70-80, so it behaves as before for
80 column frames.


        Stefan

Re: Display-based word wrapping

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I've checked in Kim F. Storm's display-based word-wrapping patch, with
>> some modifications.  The word-wrapping is controlled by the `word-wrap'
>> per-buffer variable.  It is a form of continuation line, so e.g. will
>> not be performed if lines are truncated rather than continued.
>
> Why did you choose a separate variable rather than reusing truncate-lines?

The name `truncate-lines' does not give any hint that it controls word
wrapping too.

Do you care about this?  If so, how about this: make truncate-lines an
obsolete alias for `line-wrap-method', which accepts the values
`edge-wrap', `word-wrap', and `truncate', with t equivalent to
`truncate' and nil equivalent to `edge-wrap'.

>> I have also changed truncate-partial-width-windows to accept integer
>> values specifying a window width below which to truncate lines, and
>> changed the default to 30.
>
> Since the Emacs-22 default was t, I think a safer new default (other
> than t) would be something around 70-80, so it behaves as before for
> 80 column frames.

For anyone using the word-wrap feature, that could be annoying.  With
word wrapping, buffers with long lines can be comfortably read in
50-column windows, but if truncate-partial-width-windows is 70-80,
they'll be truncated rather than wrapped.

Re: Display-based word wrapping

[Stefan Monnier]

> The name `truncate-lines' does not give any hint that it controls word
> wrapping too.

> Do you care about this?  If so, how about this: make truncate-lines an
> obsolete alias for `line-wrap-method', which accepts the values
> `edge-wrap', `word-wrap', and `truncate', with t equivalent to
> `truncate' and nil equivalent to `edge-wrap'.

Yes, that sounds very good (I'd have said `char-wrap' rather than
`edge-wrap', tho).

>>> I have also changed truncate-partial-width-windows to accept integer
>>> values specifying a window width below which to truncate lines, and
>>> changed the default to 30.
>> 
>> Since the Emacs-22 default was t, I think a safer new default (other
>> than t) would be something around 70-80, so it behaves as before for
>> 80 column frames.

> For anyone using the word-wrap feature, that could be annoying.  With
> word wrapping, buffers with long lines can be comfortably read in
> 50-column windows, but if truncate-partial-width-windows is 70-80,
> they'll be truncated rather than wrapped.

If you say so,


        Stefan

Re: Display-based word wrapping

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The name `truncate-lines' does not give any hint that it controls word
>> wrapping too.
>
>> Do you care about this?  If so, how about this: make truncate-lines an
>> obsolete alias for `line-wrap-method', which accepts the values
>> `edge-wrap', `word-wrap', and `truncate', with t equivalent to
>> `truncate' and nil equivalent to `edge-wrap'.
>
> Yes, that sounds very good (I'd have said `char-wrap' rather than
> `edge-wrap', tho).

One big disadvantage, though: truncate-lines is used very widely in the
Lisp code.  Replacing them would be rather annoying.

There's also the matter of what to do with `toggle-truncate-lines'.

Re: Display-based word wrapping

[Stefan Monnier]

>>> The name `truncate-lines' does not give any hint that it controls word
>>> wrapping too.
>> 
>>> Do you care about this?  If so, how about this: make truncate-lines an
>>> obsolete alias for `line-wrap-method', which accepts the values
>>> `edge-wrap', `word-wrap', and `truncate', with t equivalent to
>>> `truncate' and nil equivalent to `edge-wrap'.
>> 
>> Yes, that sounds very good (I'd have said `char-wrap' rather than
>> `edge-wrap', tho).

> One big disadvantage, though: truncate-lines is used very widely in the
> Lisp code.  Replacing them would be rather annoying.

I don't see much of a problem with it.  That's what
define-obsolete-variable-alias is for, isn't it?

> There's also the matter of what to do with `toggle-truncate-lines'.

This has 2 issues: the name of the command, and its functionality.
I think we'll find that once we figured what is the right fix for its
functionality, the naming issue will be easy to solve.


        Stefan

Re: Display-based word wrapping

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> There's also the matter of what to do with `toggle-truncate-lines'.
>
> This has 2 issues: the name of the command, and its functionality.
> I think we'll find that once we figured what is the right fix for its
> functionality, the naming issue will be easy to solve.

Tho the concept of truncation still seems quite valid

-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: Display-based word wrapping

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Do you care about this?  If so, how about this: make truncate-lines an
>>>> obsolete alias for `line-wrap-method', which accepts the values
>>>> `edge-wrap', `word-wrap', and `truncate', with t equivalent to
>>>> `truncate' and nil equivalent to `edge-wrap'.
>>> 
>>> Yes, that sounds very good (I'd have said `char-wrap' rather than
>>> `edge-wrap', tho).
>
>> One big disadvantage, though: truncate-lines is used very widely in the
>> Lisp code.  Replacing them would be rather annoying.
>
> I don't see much of a problem with it.  That's what
> define-obsolete-variable-alias is for, isn't it?

Leaving these calls in place would generate plenty of byte-compiler
warnings, unless we do defvaralias instead of
define-obsolete-variable-alias.  Anyway, isn't it a general policy to
change the code in Emacs to use non-obsolete names?

Re: Display-based word wrapping

[Stefan Monnier]

>>> There's also the matter of what to do with `toggle-truncate-lines'.
>> 
>> This has 2 issues: the name of the command, and its functionality.
>> I think we'll find that once we figured what is the right fix for its
>> functionality, the naming issue will be easy to solve.

> Tho the concept of truncation still seems quite valid

Agreed.


        Stefan

Re: Display-based word wrapping

[Stefan Monnier]

>> I don't see much of a problem with it.  That's what
>> define-obsolete-variable-alias is for, isn't it?

> Leaving these calls in place would generate plenty of byte-compiler
> warnings, unless we do defvaralias instead of
> define-obsolete-variable-alias.  Anyway, isn't it a general policy to
> change the code in Emacs to use non-obsolete names?

Of course, but luckily we have a tool (Emacs) that can help us do the
search&replace for those cases that occur within Emacs's own files.
Still doesn't seem like a major problem.

Of course, we could also decide not to rename the variable.  All I'm
after is to keep a single (3-state) variable rather than a pair of
boolean vars to choose between the 3 alternative ways to deal with long
lines.


        Stefan

Re: Display-based word wrapping

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I don't see much of a problem with it.  That's what
>>> define-obsolete-variable-alias is for, isn't it?
>
>> Leaving these calls in place would generate plenty of byte-compiler
>> warnings, unless we do defvaralias instead of
>> define-obsolete-variable-alias.  Anyway, isn't it a general policy to
>> change the code in Emacs to use non-obsolete names?
>
> Of course, but luckily we have a tool (Emacs) that can help us do the
> search&replace for those cases that occur within Emacs's own files.
> Still doesn't seem like a major problem.
>
> Of course, we could also decide not to rename the variable.  All I'm
> after is to keep a single (3-state) variable rather than a pair of
> boolean vars to choose between the 3 alternative ways to deal with long
> lines.

What I'm questioning is whether it's truly a 3-state situation.  From
the point of view of the redisplay engine, yes, it's just three
different ways of wrapping.  But from the point of view of the Lisp
interface, it may be more convenient to regard word-wrap and char-wrap
are two different styles of line continuation, and to draw an additional
distinction between line continuation and line truncation.  Because then
the semantic role of truncate-partial-width-windows and
toggle-truncate-lines would be unchanged: if lines are not truncated,
they are continued, and the word-wrap variable determines how that
continuation occurs.

Re: Display-based word wrapping

[Stefan Monnier]

> What I'm questioning is whether it's truly a 3-state situation.  From
> the point of view of the redisplay engine, yes, it's just three
> different ways of wrapping.  But from the point of view of the Lisp
> interface, it may be more convenient to regard word-wrap and char-wrap
> are two different styles of line continuation, and to draw an additional
> distinction between line continuation and line truncation.  Because then
> the semantic role of truncate-partial-width-windows and
> toggle-truncate-lines would be unchanged: if lines are not truncated,
> they are continued, and the word-wrap variable determines how that
> continuation occurs.

Yes, I guess that makes sense as well,


        Stefan