GNU bug report logs - #19661
wrapping before window-width (new wrap-column text property?)

Previous Next

To reply to this bug, email your comments to 19661 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: submit <at> debbugs.gnu.org
Subject: wrapping before window-width (new wrap-column text property?) 
Date: Fri, 23 Jan 2015 13:17:08 +0000

Package:  emacs
Severity: wishlist

	[As suggested in news:jwviogtdei4.fsf-monnier+emacs <at> gnu.org,
	news:87387w8r2j.fsf <at> violet.siamics.net, etc.; parts of the
	second message are reiterated below.]

	Please provide support for window-width-independent wrapping in
	the Emacs display engine; possibly by the means of a new
	wrap-column text property (and still perhaps complemented by a
	eponymous buffer-local variable), treated similarly to the likes
	of wrap-prefix.

	This feature could be used to display format=flowed (RFC 3676)
	MIME parts, as well as enriched-mode documents, documents using
	MediaWiki markup, SHR-rendered HTML documents, and pretty much
	any other kind of text which allows for /both/ wrappable and
	preformatted parts at the same time.

	It is already possible to influence the wrap width somewhat by
	setting the margin width variables (right-margin-width,
	left-margin-width) appropriately (see bug#4172, for instance.)
	The suggested wrap-column text property should probably have no
	effect on the window marginal areas, however.

	I admit that I know very little of the current Emacs display
	implementation.  However, it seems to me that wrap-column makes
	us one property closer to native multicolumn display (which’d
	warrant a separate wishlist bug report, though.)

	Consider, e. g.:

This is an example sentence with wrap-column set to 23.

This is yet another example sentence with line-prefix and wrap-prefix
both set to (space :align-to 25), – or something like that.

	From there, we may display it as follows:

This is an example
sentence with
wrap-column set to 23.

                         This is yet another example sentence with line-prefix
                         and wrap-prefix both set to (space :align-to 25), –
                         or something like that.

	Yet, provided that some other property is switched on, the Emacs
	display engine may decide to show it like this instead:

This is an example       This is yet another example sentence with line-prefix
sentence with            and wrap-prefix both set to (space :align-to 25), –
wrap-column set to 23.   or something like that.

	As already imagined in the preceding discussion, forward- and
	backward-char commands would then still follow the logical order
	of text in the buffer (that is: the “23” sentence, then the “25”
	one), while left-char, etc. would follow the visual order
	(assuming visual-order-cursor-movement.)

-- 
FSF associate member #7257  np. Mi memoras — Kajto      … 3013 B6A0 230E 334A

Message #8 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column
 text	property?)
Date: Fri, 23 Jan 2015 18:11:12 +0200

> From: Ivan Shmakov <ivan <at> siamics.net>
> Date: Fri, 23 Jan 2015 13:17:08 +0000
> 
> 	Please provide support for window-width-independent wrapping in
> 	the Emacs display engine; possibly by the means of a new
> 	wrap-column text property (and still perhaps complemented by a
> 	eponymous buffer-local variable), treated similarly to the likes
> 	of wrap-prefix.
> 
> 	This feature could be used to display format=flowed (RFC 3676)
> 	MIME parts, as well as enriched-mode documents, documents using
> 	MediaWiki markup, SHR-rendered HTML documents, and pretty much
> 	any other kind of text which allows for /both/ wrappable and
> 	preformatted parts at the same time.

format=flowed etc. is already supported by word-wrap, isn't it?

> 	I admit that I know very little of the current Emacs display
> 	implementation.

How about biting the bullet and trying to do this yourself?  I can
provide guidance and advice, if needed.

> 	Yet, provided that some other property is switched on, the Emacs
> 	display engine may decide to show it like this instead:
> 
> This is an example       This is yet another example sentence with line-prefix
> sentence with            and wrap-prefix both set to (space :align-to 25), –
> wrap-column set to 23.   or something like that.

This is a much harder nut to crack, and having wrap-column doesn't
help with that.

The fundamental problem here is that the Emacs display engine is based
on an "iterator" object that basically walks a buffer and generates
"glyph" objects that are then given to the display back-end for actual
display.  The iterator object has only a very myopic view of the text
it walks through.  Before Emacs 24, that view was one-character long
-- we only looked at the next character in the logical order.  With
Emacs 24's bidirectional display, the field of view became slightly
wider, but it is still limited to a single physical line, and most of
the display doesn't even know about that, the single exception being
bidi.c.

Now, the current display engine's workhorse is display_line, which
produces glyph objects for a single screen line.  What it does is call
a function to find the next "display element" (character, image,
composition, etc.) to display, produces glyphs for it, and goes to the
next display element in the visual order.

With your suggestion, once the width of the laid out glyphs reaches
some pixel value, the next display element will need to come from a
different part of the buffer.  But how to know where in the buffer is
that?  You cannot know that until you are done with layout of the
entire visible portion of the left-side pane, the one that in the
above example ends with "set to 23."

So either we need a deep surgery of display_line, so that it acquires
the ability to produce layout of each screen line in several parts, or
we write some tricky code that would perform all the necessary
calculations to find the buffer position of "This yet another example"
when we are done producing "This is an example" and want to continue
with the same screen line.

The former alternative means significant changes all over the display
engine, the latter means redisplay will be slower (not sure by how
much).  So both are highly non-trivial.

> 	As already imagined in the preceding discussion, forward- and
> 	backward-char commands would then still follow the logical order
> 	of text in the buffer (that is: the “23” sentence, then the “25”
> 	one), while left-char, etc. would follow the visual order
> 	(assuming visual-order-cursor-movement.)

That's the least of our trouble: the function that finds the place to
put the cursor (set_cursor_from_row) already thoroughly analyzes the
window display, and in Emacs 24 was rewritten to make it independent
of many assumptions that were broken by bidirectional display.

Perhaps you think that Emacs moves cursor visually, in which case it
would have had problems when the logical flow of text is broken like
that.  But that's not what Emacs does to move cursor: it moves point,
updates the display, and then figures out where in the new display to
put the cursor.

Message #11 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Fri, 23 Jan 2015 17:55:53 +0100

>> This is an example       This is yet another example sentence with line-prefix
>> sentence with            and wrap-prefix both set to (space :align-to 25), –
>> wrap-column set to 23.   or something like that.
>
> This is a much harder nut to crack, and having wrap-column doesn't
> help with that.

This could be done with two side-by-side windows, `follow-mode' (Anders
Lindgren would certainly help with that) and some non-trivial changes in
window layout.  You'd probably want a zero width window to display a
common vertical scroll bar, a zero height window to display a horizontal
scroll bar and two zero height windows to display common mode and header
lines.  And obviously some meta mode that turns on multicolumn display
for parts of the text and manages the window layout appropriately.

In any case you can easily try a prototype with a number of side-by-side
windows turning off all decorations but the scroll bar of the rightmost
one and enabling `follow-mode'.  And you could insert (barely visible)
window dividers and use the mouse to change the widths of the columns.

martin

Message #14 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?) 
Date: Fri, 23 Jan 2015 19:11:11 +0000

>>>>> martin rudalics <rudalics <at> gmx.at> writes:

 >>> This is an example       This is yet another example sentence with
 >>> sentence with            line-prefix and wrap-prefix both set to
 >>> wrap-column set to 23.   (space :align-to 25), – or something like that.

 >> This is a much harder nut to crack, and having wrap-column doesn't
 >> help with that.

 > This could be done with two side-by-side windows, `follow-mode'
 > (Anders Lindgren would certainly help with that) and some non-trivial
 > changes in window layout.

	Yes, I was thinking about something like that.  However, the
	ultimate goal is for Emacs to set foot on that wordprocessing
	land, so to say; and there, such window layouts may easily
	become unmanageable.

[…]

 > In any case you can easily try a prototype with a number of
 > side-by-side windows turning off all decorations but the scroll bar
 > of the rightmost one and enabling `follow-mode'.  And you could
 > insert (barely visible) window dividers and use the mouse to change
 > the widths of the columns.

	I doubt I really could experiment much with scrollbars with the
	tty-only Emacs builds I use exclusively for over a year now.

-- 
FSF associate member #7257  np. Innocent Exile — Iron Maiden … B6A0 230E 334A

Message #17 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?) 
Date: Fri, 23 Jan 2015 19:45:31 +0000

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

 >> From: Ivan Shmakov  Date: Fri, 23 Jan 2015 13:17:08 +0000

 >> Please provide support for window-width-independent wrapping in the
 >> Emacs display engine; possibly by the means of a new wrap-column
 >> text property (and still perhaps complemented by a eponymous
 >> buffer-local variable), treated similarly to the likes of
 >> wrap-prefix.

	… Or that could rather be wrap-width, given that Emacs supports
	pixelwise resize now (not to mention variable-width fonts, etc…)

 >> This feature could be used to display format=flowed (RFC 3676) MIME
 >> parts, as well as enriched-mode documents, documents using MediaWiki
 >> markup, SHR-rendered HTML documents, and pretty much any other kind
 >> of text which allows for /both/ wrappable and preformatted parts at
 >> the same time.

 > format=flowed etc. is already supported by word-wrap, isn't it?

	Not in its entirety; consider, e. g. (section 4.1 of RFC 3676):

   If the line ends in a space, the line is flowed.  Otherwise it is
   fixed.  The exception to this rule is a signature separator line,
   described in Section 4.3.  Such lines end in a space but are neither
   flowed nor fixed.

	I know of no way to make the Emacs display engine wrap one line
	but not the other in the very same buffer.

 >> I admit that I know very little of the current Emacs display
 >> implementation.

 > How about biting the bullet and trying to do this yourself?  I can
 > provide guidance and advice, if needed.

	I guess I can, but most probably /not/ in the next few months.

	(The biggest problem for me would be the change of the tools and
	the workflow.  Say, nothing like eval-defun is going to be
	available while working on the C code.  Also, I’m not really
	keen when it comes to non-tty Emacs frames, – never felt those
	as of being of much value for my tasks.)

[…]

 > The fundamental problem here is that the Emacs display engine is
 > based on an "iterator" object that basically walks a buffer and
 > generates "glyph" objects that are then given to the display back-end
 > for actual display.  The iterator object has only a very myopic view
 > of the text it walks through.  Before Emacs 24, that view was
 > one-character long -- we only looked at the next character in the
 > logical order.  With Emacs 24's bidirectional display, the field of
 > view became slightly wider, but it is still limited to a single
 > physical line, and most of the display doesn't even know about that,
 > the single exception being bidi.c.

	“Physical” as in “display” or “buffer”?

 > With your suggestion, once the width of the laid out glyphs reaches
 > some pixel value, the next display element will need to come from a
 > different part of the buffer.  But how to know where in the buffer is
 > that?  You cannot know that until you are done with layout of the
 > entire visible portion of the left-side pane, the one that in the
 > above example ends with "set to 23."

 > So either we need a deep surgery of display_line, so that it acquires
 > the ability to produce layout of each screen line in several parts,
 > or we write some tricky code that would perform all the necessary
 > calculations to find the buffer position of "This yet another
 > example" when we are done producing "This is an example" and want to
 > continue with the same screen line.

	Basically, yes, I thought about the display engine keeping track
	of the latest “wasted” rectangular chunk of screen space, and
	allowing for it to be occupied by the text coming later in the
	“buffer” order.  (Or perhaps up to two such chunks: one to the
	right and one to the left of the text being drawn.)

	IIUC, display_line would potentially have to be called several
	times to draw a single display line.

	And all this behavior only triggered when the text being drawn
	has some specific property; once the property value changes, —
	the state is reset.

 > The former alternative means significant changes all over the display
 > engine, the latter means redisplay will be slower (not sure by how
 > much).  So both are highly non-trivial.

	ACK; thanks for the detailed explanation.

 >> As already imagined in the preceding discussion, forward- and
 >> backward-char commands would then still follow the logical order of
 >> text in the buffer (that is: the “23” sentence, then the “25” one),
 >> while left-char, etc. would follow the visual order (assuming
 >> visual-order-cursor-movement.)

 > That's the least of our trouble: the function that finds the place to
 > put the cursor (set_cursor_from_row) already thoroughly analyzes the
 > window display, and in Emacs 24 was rewritten to make it independent
 > of many assumptions that were broken by bidirectional display.

 > Perhaps you think that Emacs moves cursor visually, in which case it
 > would have had problems when the logical flow of text is broken like
 > that.  But that's not what Emacs does to move cursor: it moves point,
 > updates the display, and then figures out where in the new display to
 > put the cursor.

	That was a pure UI consideration.  (And not even one I’ve
	personally thought of.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Message #20 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Fri, 23 Jan 2015 22:22:56 +0200

> Date: Fri, 23 Jan 2015 17:55:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 19661 <at> debbugs.gnu.org
> 
>  >> This is an example       This is yet another example sentence with line-prefix
>  >> sentence with            and wrap-prefix both set to (space :align-to 25), –
>  >> wrap-column set to 23.   or something like that.
>  >
>  > This is a much harder nut to crack, and having wrap-column doesn't
>  > help with that.
> 
> This could be done with two side-by-side windows, `follow-mode' (Anders
> Lindgren would certainly help with that) and some non-trivial changes in
> window layout.

That'd be a kludge-around.  I thought we were talking about teaching
Emacs new layout tricks, not overloading existing ones with features
they weren't designed to support.  We all know the subtle problems in
follow-mode, right?

Message #23 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column
 text	property?)
Date: Fri, 23 Jan 2015 23:17:48 +0200

> From: Ivan Shmakov <ivan <at> siamics.net>
> Date: Fri, 23 Jan 2015 19:45:31 +0000
> 
>  > format=flowed etc. is already supported by word-wrap, isn't it?
> 
> 	Not in its entirety; consider, e. g. (section 4.1 of RFC 3676):
> 
>    If the line ends in a space, the line is flowed.  Otherwise it is
>    fixed.  The exception to this rule is a signature separator line,
>    described in Section 4.3.  Such lines end in a space but are neither
>    flowed nor fixed.
> 
> 	I know of no way to make the Emacs display engine wrap one line
> 	but not the other in the very same buffer.

But then the feature you suggest will have the same problem, since it
will be build on the same infrastructure as word-wrap.

>  >> I admit that I know very little of the current Emacs display
>  >> implementation.
> 
>  > How about biting the bullet and trying to do this yourself?  I can
>  > provide guidance and advice, if needed.
> 
> 	I guess I can, but most probably /not/ in the next few months.

There's no rush.

> 
> 	(The biggest problem for me would be the change of the tools and
> 	the workflow.  Say, nothing like eval-defun is going to be
> 	available while working on the C code.  Also, I’m not really
> 	keen when it comes to non-tty Emacs frames, – never felt those
> 	as of being of much value for my tasks.)

Something to learn, I guess.

>  > The fundamental problem here is that the Emacs display engine is
>  > based on an "iterator" object that basically walks a buffer and
>  > generates "glyph" objects that are then given to the display back-end
>  > for actual display.  The iterator object has only a very myopic view
>  > of the text it walks through.  Before Emacs 24, that view was
>  > one-character long -- we only looked at the next character in the
>  > logical order.  With Emacs 24's bidirectional display, the field of
>  > view became slightly wider, but it is still limited to a single
>  > physical line, and most of the display doesn't even know about that,
>  > the single exception being bidi.c.
> 
> 	“Physical” as in “display” or “buffer”?

In the buffer, i.e. up to the next newline.

>  > So either we need a deep surgery of display_line, so that it acquires
>  > the ability to produce layout of each screen line in several parts,
>  > or we write some tricky code that would perform all the necessary
>  > calculations to find the buffer position of "This yet another
>  > example" when we are done producing "This is an example" and want to
>  > continue with the same screen line.
> 
> 	Basically, yes, I thought about the display engine keeping track
> 	of the latest “wasted” rectangular chunk of screen space, and
> 	allowing for it to be occupied by the text coming later in the
> 	“buffer” order.  (Or perhaps up to two such chunks: one to the
> 	right and one to the left of the text being drawn.)

That's the whole problem: the current display engine doesn't manage
any rectangular space.  It proceeds one line at a time.

> 	IIUC, display_line would potentially have to be called several
> 	times to draw a single display line.

Several calls is not the problem.  The problem is how to know with
which buffer position to call it.

> 	And all this behavior only triggered when the text being drawn
> 	has some specific property; once the property value changes, —
> 	the state is reset.

Redisplay will take care of that, so again, this isn't the problem.

Message #26 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Sat, 24 Jan 2015 10:08:10 +0100

> 	Yes, I was thinking about something like that.  However, the
> 	ultimate goal is for Emacs to set foot on that wordprocessing
> 	land, so to say; and there, such window layouts may easily
> 	become unmanageable.

And you think the display engine can manage such layouts?

> 	I doubt I really could experiment much with scrollbars with the
> 	tty-only Emacs builds I use exclusively for over a year now.

So you are in the lucky position where you can omit scrollbars from such
experiments.

martin

Message #29 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Sat, 24 Jan 2015 10:08:33 +0100

> That'd be a kludge-around.  I thought we were talking about teaching
> Emacs new layout tricks, not overloading existing ones with features
> they weren't designed to support.

Layouts should be handled at the Elisp level.  Where exactly and how is
a matter of taste.  Currently, windows can provide a tiled layout only.
For example, having (multicolumn) text flow around an image is tedious.
So this would be just an incentive to provide different window layouts
(or layers).

> We all know the subtle problems in
> follow-mode, right?

Which we would have to solve anyway.  I wouldn't reinvent the wheel.

martin

Message #32 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Sat, 24 Jan 2015 11:47:36 +0200

> Date: Sat, 24 Jan 2015 10:08:33 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 19661 <at> debbugs.gnu.org
> 
>  > That'd be a kludge-around.  I thought we were talking about teaching
>  > Emacs new layout tricks, not overloading existing ones with features
>  > they weren't designed to support.
> 
> Layouts should be handled at the Elisp level.

This is impossible with the current Emacs design, and you know it.
The design is that Lisp programs _specify_ the layout, by setting up
text properties, overlays, and local variables.  The actual _handling_
of the layout is done by the display engine, which is not exposed to
Lisp.

So if a particular kind of layout is not supported by the display
engine, you cannot specify it in Lisp.

> For example, having (multicolumn) text flow around an image is tedious.
> So this would be just an incentive to provide different window layouts
> (or layers).

I agree, but I don't think this can or should be done in Lisp.  Over
the years, I've seen many features that attempted to produce fancy
display traits not supported by the engine, and they all look kludgey
to me.  They also break very easily.

>  > We all know the subtle problems in follow-mode, right?
> 
> Which we would have to solve anyway.

The solutions are on the C level, not in Lisp.

> I wouldn't reinvent the wheel.

The wheel should be round, then it's a wheel.

Message #35 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Sun, 25 Jan 2015 11:38:42 +0100

>> Layouts should be handled at the Elisp level.
>
> This is impossible with the current Emacs design, and you know it.
> The design is that Lisp programs _specify_ the layout, by setting up
> text properties, overlays, and local variables.  The actual _handling_
> of the layout is done by the display engine, which is not exposed to
> Lisp.
>
> So if a particular kind of layout is not supported by the display
> engine, you cannot specify it in Lisp.

The windows code does provide the display engine with a clipping
rectangle and two buffer positions where to start displaying text in
that rectangle and where to display the cursor (the latter may be
overridden by the display engine).  Together, these determine the basic
layout of buffer portions on screen and can be used by Lisp programs.

> I agree, but I don't think this can or should be done in Lisp.  Over
> the years, I've seen many features that attempted to produce fancy
> display traits not supported by the engine, and they all look kludgey
> to me.  They also break very easily.

With multiple columns we have to provide an API.  For example, to decide
whether the first character of a buffer's line is also the the first
character of a line in the rectangle displaying that line.  Otherwise,
we cannot provide the navigation facilities Ivan asked for.  If each
column is displayed in a separate rectangle, the first character of a
line is always the first character of the rectangle displaying that line
and you can handle this distinction, and thus provide the API, on the
Lisp level.

> The wheel should be round, then it's a wheel.

And it should spin freely.

martin

Message #38 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Sun, 25 Jan 2015 17:50:53 +0200

> Date: Sun, 25 Jan 2015 11:38:42 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 19661 <at> debbugs.gnu.org
> 
>  >> Layouts should be handled at the Elisp level.
>  >
>  > This is impossible with the current Emacs design, and you know it.
>  > The design is that Lisp programs _specify_ the layout, by setting up
>  > text properties, overlays, and local variables.  The actual _handling_
>  > of the layout is done by the display engine, which is not exposed to
>  > Lisp.
>  >
>  > So if a particular kind of layout is not supported by the display
>  > engine, you cannot specify it in Lisp.
> 
> The windows code does provide the display engine with a clipping
> rectangle and two buffer positions where to start displaying text in
> that rectangle and where to display the cursor (the latter may be
> overridden by the display engine).  Together, these determine the basic
> layout of buffer portions on screen and can be used by Lisp programs.

Sorry for being dense, this being just the first weekday for me, but
what "windows code" does that, please?

In any case, telling the display engine where to start the display is
a far cry from telling it how to lay out the screen from that point
onwards.

>  > I agree, but I don't think this can or should be done in Lisp.  Over
>  > the years, I've seen many features that attempted to produce fancy
>  > display traits not supported by the engine, and they all look kludgey
>  > to me.  They also break very easily.
> 
> With multiple columns we have to provide an API.  For example, to decide
> whether the first character of a buffer's line is also the the first
> character of a line in the rectangle displaying that line.  Otherwise,
> we cannot provide the navigation facilities Ivan asked for.  If each
> column is displayed in a separate rectangle, the first character of a
> line is always the first character of the rectangle displaying that line
> and you can handle this distinction, and thus provide the API, on the
> Lisp level.

Providing an API is not equivalent to implementing it.  In order for
us to be able to provide such an API, the display engine should
implement the support such an API will need.  And that's the hard part
of the job -- how to perform this layout.  Once we figure that out,
providing an API for controlling it will be easy.

Message #41 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Sun, 25 Jan 2015 18:46:34 +0100

> Sorry for being dense, this being just the first weekday for me, but
> what "windows code" does that, please?

The one that calculates the text size of windows.  Or did you read
"Windows code"?

> In any case, telling the display engine where to start the display is
> a far cry from telling it how to lay out the screen from that point
> onwards.

My point was to _not_ change the code of the display engine.

> Providing an API is not equivalent to implementing it.  In order for
> us to be able to provide such an API, the display engine should
> implement the support such an API will need.  And that's the hard part
> of the job -- how to perform this layout.  Once we figure that out,
> providing an API for controlling it will be easy.

It essentially would have to subdivide a window into rectangles.  And I
would do that on the window(s) level to avoid the hard part of the job.

martin

Message #44 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?)
Date: Sun, 25 Jan 2015 20:00:39 +0200

> Date: Sun, 25 Jan 2015 18:46:34 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 19661 <at> debbugs.gnu.org
> 
>  > Sorry for being dense, this being just the first weekday for me, but
>  > what "windows code" does that, please?
> 
> The one that calculates the text size of windows.

OK, but I fail to see how this, or anything similar, can provide the
features being discussed.

>  > In any case, telling the display engine where to start the display is
>  > a far cry from telling it how to lay out the screen from that point
>  > onwards.
> 
> My point was to _not_ change the code of the display engine.

Why not?

>  > Providing an API is not equivalent to implementing it.  In order for
>  > us to be able to provide such an API, the display engine should
>  > implement the support such an API will need.  And that's the hard part
>  > of the job -- how to perform this layout.  Once we figure that out,
>  > providing an API for controlling it will be easy.
> 
> It essentially would have to subdivide a window into rectangles.  And I
> would do that on the window(s) level to avoid the hard part of the job.

Well, like I said, I consider such (ab)using of windows a kludge.

Message #47 received at 19661 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 19661 <at> debbugs.gnu.org
Subject: Re: bug#19661: wrapping before window-width (new wrap-column text
 property?) 
Date: Tue, 27 Jan 2015 22:47:35 +0000

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Fri, 23 Jan 2015 19:45:31 +0000

[…]

 >> I know of no way to make the Emacs display engine wrap one line but
 >> not the other in the very same buffer.

 > But then the feature you suggest will have the same problem, since it
 > will be build on the same infrastructure as word-wrap.

	When I set wrap-width for a specific line to a value greater
	than that line’s own width, I expect the line to no longer be
	wrapped.

	Also, as Stefan suggests, there can be a distinct “infinity”
	value for the property in question, to inhibit wrapping
	unconditionally for the line(s) covered.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.