GNU logs - #19661, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19661: wrapping before window-width (new wrap-column text property?) 
Resent-From: Ivan Shmakov <ivan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jan 2015 13:18:01 +0000
Resent-Message-ID: <handler.19661.B.1422019043765 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 19661 <at> debbugs.gnu.org
From: Ivan Shmakov <ivan@HIDDEN>
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN>
 <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN>
 <878uhrcr5l.fsf@HIDDEN> <83sifzjflk.fsf@HIDDEN>
 <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN>
 <877fxaa49w.fsf@HIDDEN> <831tnicji7.fsf@HIDDEN>
 <jwviogtdei4.fsf-monnier+emacs@HIDDEN> <83y4pp9dku.fsf@HIDDEN>
 <87387w8r2j.fsf@HIDDEN>
Date: Fri, 23 Jan 2015 13:17:08 +0000
In-Reply-To: <87387w8r2j.fsf@HIDDEN> (Ivan Shmakov's message of
 "Wed, 31 Dec 2014 02:56:52 +0000")
Message-ID: <87iofxprfv.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Package:  emacs
Severity: wishlist

	[As suggested in news:jwviogtdei4.fsf-monnier+emacs@HIDDEN,
	news:87387w8r2j.fsf@HIDDEN, 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=3Dflowed (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=E2=80=99d
	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), =E2=80=93 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-pre=
fix
                         and wrap-prefix both set to (space :align-to 25), =
=E2=80=93
                         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-pre=
fix
sentence with            and wrap-prefix both set to (space :align-to 25), =
=E2=80=93
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 =E2=80=9C23=E2=80=9D sentence, then th=
e =E2=80=9C25=E2=80=9D
	one), while left-char, etc. would follow the visual order
	(assuming visual-order-cursor-movement.)

--=20
FSF associate member #7257  np. Mi memoras =E2=80=94 Kajto      =E2=80=A6 3=
013 B6A0 230E 334A

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Ivan Shmakov <ivan@HIDDEN>
Subject: bug#19661: Acknowledgement (wrapping before window-width (new
 wrap-column text property?) )
Message-ID: <handler.19661.B.1422019043765.ack <at> debbugs.gnu.org>
References: <87iofxprfv.fsf_-_@HIDDEN>
X-Gnu-PR-Message: ack 19661
X-Gnu-PR-Package: emacs
Reply-To: 19661 <at> debbugs.gnu.org
Date: Fri, 23 Jan 2015 13:18:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 19661 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
19661: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D19661
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19661: wrapping before window-width (new wrap-column text	property?)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jan 2015 16:12:01 +0000
Resent-Message-ID: <handler.19661.B19661.142202948318249 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ivan Shmakov <ivan@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Date: Fri, 23 Jan 2015 18:11:12 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87iofxprfv.fsf_-_@HIDDEN>
Message-id: <8361bxtr33.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8BIT
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Ivan Shmakov <ivan@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jan 2015 16:57:04 +0000
Resent-Message-ID: <handler.19661.B19661.142203217922387 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Message-ID: <54C27D19.1080102@HIDDEN>
Date: Fri, 23 Jan 2015 17:55:53 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>	<83ioh2nlow.fsf@HIDDEN>
 <87sig6xech.fsf@HIDDEN>	<83fvc5ni0u.fsf@HIDDEN>
 <E1Y4AVO-00035n-PI@HIDDEN>	<87k31fwwyv.fsf@HIDDEN>
 <E1Y4Snj-0004wy-PF@HIDDEN>	<87bnmq9ibf.fsf@HIDDEN>
 <E1Y50Fd-0003BE-GC@HIDDEN>	<jwv3880fumd.fsf-monnier+emacs@HIDDEN>	<87lhlrx5fc.fsf@HIDDEN>	<jwvfvbzh54s.fsf-monnier+emacs@HIDDEN>	<878uhrcr5l.fsf@HIDDEN>	<83sifzjflk.fsf@HIDDEN>
 <87egric2ki.fsf_-_@HIDDEN>	<jwvtx0eee66.fsf-monnier+emacs@HIDDEN>	<877fxaa49w.fsf@HIDDEN>	<831tnicji7.fsf@HIDDEN>
 <jwviogtdei4.fsf-monnier+emacs@HIDDEN>	<83y4pp9dku.fsf@HIDDEN>
 <87387w8r2j.fsf@HIDDEN>	<87iofxprfv.fsf_-_@HIDDEN>
 <8361bxtr33.fsf@HIDDEN>
In-Reply-To: <8361bxtr33.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

 >> This is an example       This is yet another example sentence with li=
ne-prefix
 >> sentence with            and wrap-prefix both set to (space :align-to=
 25), =E2=80=93
 >> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?) 
Resent-From: Ivan Shmakov <ivan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jan 2015 19:12:01 +0000
Resent-Message-ID: <handler.19661.B19661.14220402952580 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 19661 <at> debbugs.gnu.org
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.14220402952580
          (code B ref 19661); Fri, 23 Jan 2015 19:12:01 +0000
Received: (at 19661) by debbugs.gnu.org; 23 Jan 2015 19:11:35 +0000
Received: from localhost ([127.0.0.1]:54586 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YEjdi-0000fO-7I
	for submit <at> debbugs.gnu.org; Fri, 23 Jan 2015 14:11:34 -0500
Received: from fely.am-1.org ([78.47.74.50]:50713)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <ivan@HIDDEN>) id 1YEjdb-0000f9-Ub
 for 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 14:11:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=siamics.net;
 s=a2013295; 
 h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:Sender:References:Subject:To:From;
 bh=k58dgWY2tNZ106B6N0MQxDzvqowfBFhclwSIBss1MJ0=; 
 b=ND8+fIx9lEgkHv1YK0SBB5XB6f8iNPoLKee4nu1ZnopIdj6cGCvDmkZ2KZflMlyhTgVGwQWG/ug/rzydX8IHiAkDWgne7YN1HdCFJld2e9u7Z1nXMILhwnPyDmp/UQhTM4szx9N9AsFzsqEFV1Nq9LhayGDWD+DeyrbON2jc4Sk=;
Received: from [2a02:2560:6d4:26ca::1:1d] (helo=violet.siamics.net)
 by fely.am-1.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <ivan@HIDDEN>) id 1YEjdX-0004l9-Hr
 for 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 19:11:20 +0000
Received: from localhost ([::1] helo=violet.siamics.net)
 by violet.siamics.net with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <ivan@HIDDEN>) id 1YEjdP-0003Bg-Ry
 for 19661 <at> debbugs.gnu.org; Sat, 24 Jan 2015 02:11:11 +0700
From: Ivan Shmakov <ivan@HIDDEN>
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <E1Y4AVO-00035n-PI@HIDDEN> <87k31fwwyv.fsf@HIDDEN>
 <E1Y4Snj-0004wy-PF@HIDDEN> <87bnmq9ibf.fsf@HIDDEN>
 <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN>
 <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN>
 <878uhrcr5l.fsf@HIDDEN> <83sifzjflk.fsf@HIDDEN>
 <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN>
 <877fxaa49w.fsf@HIDDEN> <831tnicji7.fsf@HIDDEN>
 <jwviogtdei4.fsf-monnier+emacs@HIDDEN> <83y4pp9dku.fsf@HIDDEN>
 <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN>
Mail-Followup-To: 19661 <at> debbugs.gnu.org
Date: Fri, 23 Jan 2015 19:11:11 +0000
In-Reply-To: <54C27D19.1080102@HIDDEN> (martin rudalics's message of "Fri, 23
 Jan 2015 17:55:53 +0100")
Message-ID: <871tmlnwhc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

>>>>> martin rudalics <rudalics@HIDDEN> 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), =E2=80=93 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.

[=E2=80=A6]

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

--=20
FSF associate member #7257  np. Innocent Exile =E2=80=94 Iron Maiden =E2=80=
=A6 B6A0 230E 334A

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?) 
Resent-From: Ivan Shmakov <ivan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jan 2015 19:46:02 +0000
Resent-Message-ID: <handler.19661.B19661.142204234710939 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 19661 <at> debbugs.gnu.org
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142204234710939
          (code B ref 19661); Fri, 23 Jan 2015 19:46:02 +0000
Received: (at 19661) by debbugs.gnu.org; 23 Jan 2015 19:45:47 +0000
Received: from localhost ([127.0.0.1]:54597 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YEkAs-0002qN-Qw
	for submit <at> debbugs.gnu.org; Fri, 23 Jan 2015 14:45:47 -0500
Received: from fely.am-1.org ([78.47.74.50]:50714)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <ivan@HIDDEN>) id 1YEkAm-0002q9-3A
 for 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 14:45:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=siamics.net;
 s=a2013295; 
 h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:Sender:References:Subject:To:From;
 bh=vA2pwUQdOcmE+7QHsMwsZc6qj3jIgBz4XmenKPQaycM=; 
 b=h45uZ9QGNXtz9CYMaGvvMBA2YGOJWBKQ2rjCIHjmx9yVfuFMXlSbrzLR6FblDVXbXE9FRrt+1G4QshoCDkCYp0UNM2VNxEwtfkgfpGiSBS8eP/TjDHmT3JrGEYNXlt8hrqCp0P7jLlyRkx39D3NIKapQJmOxAVD8C1HXNrtHOgM=;
Received: from [2a02:2560:6d4:26ca::1:1d] (helo=violet.siamics.net)
 by fely.am-1.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <ivan@HIDDEN>) id 1YEkAl-0005H5-0E
 for 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 19:45:39 +0000
Received: from localhost ([::1] helo=violet.siamics.net)
 by violet.siamics.net with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <ivan@HIDDEN>) id 1YEkAd-0003G4-Pc
 for 19661 <at> debbugs.gnu.org; Sat, 24 Jan 2015 02:45:31 +0700
From: Ivan Shmakov <ivan@HIDDEN>
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN>
 <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN>
 <878uhrcr5l.fsf@HIDDEN> <83sifzjflk.fsf@HIDDEN>
 <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN>
 <877fxaa49w.fsf@HIDDEN> <831tnicji7.fsf@HIDDEN>
 <jwviogtdei4.fsf-monnier+emacs@HIDDEN> <83y4pp9dku.fsf@HIDDEN>
 <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
Mail-Followup-To: 19661 <at> debbugs.gnu.org
Date: Fri, 23 Jan 2015 19:45:31 +0000
In-Reply-To: <8361bxtr33.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 23 Jan
 2015 18:11:12 +0200")
Message-ID: <87wq4dmgbo.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

>>>>> Eli Zaretskii <eliz@HIDDEN> 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.

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

 >> This feature could be used to display format=3Dflowed (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=3Dflowed 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=E2=80=99m not really
	keen when it comes to non-tty Emacs frames, =E2=80=93 never felt those
	as of being of much value for my tasks.)

[=E2=80=A6]

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

	=E2=80=9CPhysical=E2=80=9D as in =E2=80=9Cdisplay=E2=80=9D or =E2=80=9Cbuf=
fer=E2=80=9D?

 > 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 =E2=80=9Cwasted=E2=80=9D rectangular chunk of screen space, =
and
	allowing for it to be occupied by the text coming later in the
	=E2=80=9Cbuffer=E2=80=9D 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, =E2=80=94
	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 =E2=80=9C23=E2=80=9D sentence, then th=
e =E2=80=9C25=E2=80=9D 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=E2=80=99ve
	personally thought of.)

--=20
FSF associate member #7257  http://boycottsystemd.org/  =E2=80=A6 3013 B6A0=
 230E 334A

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jan 2015 20:24:02 +0000
Resent-Message-ID: <handler.19661.B19661.142204458414364 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142204458414364
          (code B ref 19661); Fri, 23 Jan 2015 20:24:02 +0000
Received: (at 19661) by debbugs.gnu.org; 23 Jan 2015 20:23:04 +0000
Received: from localhost ([127.0.0.1]:54601 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YEkkx-0003jb-F9
	for submit <at> debbugs.gnu.org; Fri, 23 Jan 2015 15:23:03 -0500
Received: from mtaout28.012.net.il ([80.179.55.184]:59094)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1YEkku-0003iy-JW
 for 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 15:23:01 -0500
Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il
 (HyperSendmail v2007.08) id <0NIN00K00C83BK00@HIDDEN> for
 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 22:21:00 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NIN00JXWCIZ8810@HIDDEN>; Fri, 23 Jan 2015 22:21:00 +0200 (IST)
Date: Fri, 23 Jan 2015 22:22:56 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <54C27D19.1080102@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <83y4ots0v3.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8BIT
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN>
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Fri, 23 Jan 2015 17:55:53 +0100
> From: martin rudalics <rudalics@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text	property?)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jan 2015 21:18:02 +0000
Resent-Message-ID: <handler.19661.B19661.142204787619351 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ivan Shmakov <ivan@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142204787619351
          (code B ref 19661); Fri, 23 Jan 2015 21:18:02 +0000
Received: (at 19661) by debbugs.gnu.org; 23 Jan 2015 21:17:56 +0000
Received: from localhost ([127.0.0.1]:54625 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YElc3-000523-Pg
	for submit <at> debbugs.gnu.org; Fri, 23 Jan 2015 16:17:56 -0500
Received: from mtaout26.012.net.il ([80.179.55.182]:50698)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1YElc0-00051o-2V
 for 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 16:17:53 -0500
Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il
 (HyperSendmail v2007.08) id <0NIN00I00EYQP700@HIDDEN> for
 19661 <at> debbugs.gnu.org; Fri, 23 Jan 2015 23:17:39 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NIN009U4F5EQT70@HIDDEN>; Fri, 23 Jan 2015 23:17:39 +0200 (IST)
Date: Fri, 23 Jan 2015 23:17:48 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87wq4dmgbo.fsf_-_@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <83sif1rybn.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8BIT
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <87wq4dmgbo.fsf_-_@HIDDEN>
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> From: Ivan Shmakov <ivan@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 24 Jan 2015 09:09:02 +0000
Resent-Message-ID: <handler.19661.B19661.142209050832282 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 19661 <at> debbugs.gnu.org
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142209050832282
          (code B ref 19661); Sat, 24 Jan 2015 09:09:02 +0000
Received: (at 19661) by debbugs.gnu.org; 24 Jan 2015 09:08:28 +0000
Received: from localhost ([127.0.0.1]:54785 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YEwhg-0008Oc-0X
	for submit <at> debbugs.gnu.org; Sat, 24 Jan 2015 04:08:28 -0500
Received: from mout.gmx.net ([212.227.15.18]:49558)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1YEwhd-0008OP-Nw
 for 19661 <at> debbugs.gnu.org; Sat, 24 Jan 2015 04:08:26 -0500
Received: from [178.189.207.245] ([178.189.207.245]) by mail.gmx.com
 (mrgmx002) with ESMTPSA (Nemesis) id 0MAPoQ-1YPN6X29bW-00Bf1O for
 <19661 <at> debbugs.gnu.org>; Sat, 24 Jan 2015 10:08:19 +0100
Message-ID: <54C360FA.1070209@HIDDEN>
Date: Sat, 24 Jan 2015 10:08:10 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>	<E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN>	<E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN>	<E1Y50Fd-0003BE-GC@HIDDEN>	<jwv3880fumd.fsf-monnier+emacs@HIDDEN>	<87lhlrx5fc.fsf@HIDDEN>	<jwvfvbzh54s.fsf-monnier+emacs@HIDDEN>	<878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN>	<87egric2ki.fsf_-_@HIDDEN>	<jwvtx0eee66.fsf-monnier+emacs@HIDDEN>	<877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN>	<jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN>	<87387w8r2j.fsf@HIDDEN>	<87iofxprfv.fsf_-_@HIDDEN>
 <8361bxtr33.fsf@HIDDEN>	<54C27D19.1080102@HIDDEN>
 <871tmlnwhc.fsf@HIDDEN>
In-Reply-To: <871tmlnwhc.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:glrHE+NyhZRSvwp4pbEd0pqQ5aUqoybrJs3D/USIcF3vDhBOKn3
 k9WuQxdoAxaTDiy8k6dEX+H65lSazVFKVIw2ImXyCOb4uwZtlaB4yAgkg5NQ/YN9if09Py3
 CUQjp7uuICDdTLVHgyu1tBGzgMugj8D8Px5EVqfzZUoLwbObm1IjJgTJbjGkIWj1CdA3j2l
 jxBFkbPy7XIsrUuRzVABw==
X-UI-Out-Filterresults: notjunk:1;
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

 > 	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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 24 Jan 2015 09:09:02 +0000
Resent-Message-ID: <handler.19661.B19661.142209053432330 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142209053432330
          (code B ref 19661); Sat, 24 Jan 2015 09:09:02 +0000
Received: (at 19661) by debbugs.gnu.org; 24 Jan 2015 09:08:54 +0000
Received: from localhost ([127.0.0.1]:54788 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YEwi6-0008PN-BQ
	for submit <at> debbugs.gnu.org; Sat, 24 Jan 2015 04:08:54 -0500
Received: from mout.gmx.net ([212.227.15.15]:57938)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1YEwi4-0008P8-FM
 for 19661 <at> debbugs.gnu.org; Sat, 24 Jan 2015 04:08:52 -0500
Received: from [178.189.207.245] ([178.189.207.245]) by mail.gmx.com
 (mrgmx003) with ESMTPSA (Nemesis) id 0LcShi-1XpCwe2TcE-00jozI; Sat, 24 Jan
 2015 10:08:42 +0100
Message-ID: <54C36111.8030003@HIDDEN>
Date: Sat, 24 Jan 2015 10:08:33 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN> <83y4ots0v3.fsf@HIDDEN>
In-Reply-To: <83y4ots0v3.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:DrBvNwdkgLHRrn52LviOsOPw4pOgPMoQkdvDa+hFscrsToGCjC7
 zWe4h2F975MxtW3Igevyl+7nga+XCk9QZOaRRwJI/LRpi8uXHk2NLe5jBbZb1XD1RzY94be
 2vOletYvcBSdotFeBFA0AwfJtmYn+rhJC2xGAr9VcM24Kgr7LhYiL+p6CMyux0RE3dU0MDU
 sRoDTHV7V+zqjzlJxTKDw==
X-UI-Out-Filterresults: notjunk:1;
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

 > 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 24 Jan 2015 09:48:01 +0000
Resent-Message-ID: <handler.19661.B19661.14220928613720 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.14220928613720
          (code B ref 19661); Sat, 24 Jan 2015 09:48:01 +0000
Received: (at 19661) by debbugs.gnu.org; 24 Jan 2015 09:47:41 +0000
Received: from localhost ([127.0.0.1]:54810 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YExJc-0000xu-Lj
	for submit <at> debbugs.gnu.org; Sat, 24 Jan 2015 04:47:40 -0500
Received: from mtaout22.012.net.il ([80.179.55.172]:49946)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1YExJa-0000xf-Hu
 for 19661 <at> debbugs.gnu.org; Sat, 24 Jan 2015 04:47:39 -0500
Received: from conversion-daemon.a-mtaout22.012.net.il by
 a-mtaout22.012.net.il (HyperSendmail v2007.08) id
 <0NIO00100DFFHI00@HIDDEN> for 19661 <at> debbugs.gnu.org;
 Sat, 24 Jan 2015 11:47:31 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NIO000GVDV7XSB0@HIDDEN>;
 Sat, 24 Jan 2015 11:47:31 +0200 (IST)
Date: Sat, 24 Jan 2015 11:47:36 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <54C36111.8030003@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <83fvb0se6f.fsf@HIDDEN>
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN> <83y4ots0v3.fsf@HIDDEN> <54C36111.8030003@HIDDEN>
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sat, 24 Jan 2015 10:08:33 +0100
> From: martin rudalics <rudalics@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 25 Jan 2015 10:40:03 +0000
Resent-Message-ID: <handler.19661.B19661.142218234625203 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142218234625203
          (code B ref 19661); Sun, 25 Jan 2015 10:40:03 +0000
Received: (at 19661) by debbugs.gnu.org; 25 Jan 2015 10:39:06 +0000
Received: from localhost ([127.0.0.1]:55604 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YFKav-0006YR-Np
	for submit <at> debbugs.gnu.org; Sun, 25 Jan 2015 05:39:06 -0500
Received: from mout.gmx.net ([212.227.15.15]:55322)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1YFKar-0006Xr-UN
 for 19661 <at> debbugs.gnu.org; Sun, 25 Jan 2015 05:39:03 -0500
Received: from [93.82.15.236] ([93.82.15.236]) by mail.gmx.com (mrgmx001) with
 ESMTPSA (Nemesis) id 0LdpcB-1XpePN0V8t-00iz63;
 Sun, 25 Jan 2015 11:38:54 +0100
Message-ID: <54C4C7B2.1080708@HIDDEN>
Date: Sun, 25 Jan 2015 11:38:42 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN> <83y4ots0v3.fsf@HIDDEN> <54C36111.8030003@HIDDEN>
 <83fvb0se6f.fsf@HIDDEN>
In-Reply-To: <83fvb0se6f.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:e9h5ON5/ZpeeLYo0dTqn9JxM70eZBPjYsymHBHIJr8AmoQnCOgK
 jkxUGG62nIbR7QehP3hHYtaLr4zMpgBUdkt+f1d+iE+3LlwMgXDX2ktYjWsAtfdHCD1xrve
 TtFroyEj2WH9mY0mAPIsGFBUnNq8XgUA3gA1nnjXfrJ+xjxZov5JbRAoROJIjUzVSmvKg9D
 u3iMwjBy7xSEnXTF7QZrg==
X-UI-Out-Filterresults: notjunk:1;
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

 >> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 25 Jan 2015 15:52:02 +0000
Resent-Message-ID: <handler.19661.B19661.142220107828044 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142220107828044
          (code B ref 19661); Sun, 25 Jan 2015 15:52:02 +0000
Received: (at 19661) by debbugs.gnu.org; 25 Jan 2015 15:51:18 +0000
Received: from localhost ([127.0.0.1]:55973 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YFPT3-0007IF-Jv
	for submit <at> debbugs.gnu.org; Sun, 25 Jan 2015 10:51:18 -0500
Received: from mtaout20.012.net.il ([80.179.55.166]:40150)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1YFPT1-0007Ho-8C
 for 19661 <at> debbugs.gnu.org; Sun, 25 Jan 2015 10:51:16 -0500
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0NIQ00B00P6HYU00@HIDDEN> for 19661 <at> debbugs.gnu.org;
 Sun, 25 Jan 2015 17:51:08 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NIQ00BU2PD8LY70@HIDDEN>;
 Sun, 25 Jan 2015 17:51:08 +0200 (IST)
Date: Sun, 25 Jan 2015 17:50:53 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <54C4C7B2.1080708@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <831tmisvtu.fsf@HIDDEN>
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN> <83y4ots0v3.fsf@HIDDEN> <54C36111.8030003@HIDDEN>
 <83fvb0se6f.fsf@HIDDEN> <54C4C7B2.1080708@HIDDEN>
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sun, 25 Jan 2015 11:38:42 +0100
> From: martin rudalics <rudalics@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 25 Jan 2015 17:47:01 +0000
Resent-Message-ID: <handler.19661.B19661.142220800826903 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142220800826903
          (code B ref 19661); Sun, 25 Jan 2015 17:47:01 +0000
Received: (at 19661) by debbugs.gnu.org; 25 Jan 2015 17:46:48 +0000
Received: from localhost ([127.0.0.1]:56169 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YFRGp-0006zk-Ub
	for submit <at> debbugs.gnu.org; Sun, 25 Jan 2015 12:46:48 -0500
Received: from mout.gmx.net ([212.227.17.21]:50966)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rudalics@HIDDEN>) id 1YFRGn-0006t9-0Q
 for 19661 <at> debbugs.gnu.org; Sun, 25 Jan 2015 12:46:45 -0500
Received: from [93.82.15.78] ([93.82.15.78]) by mail.gmx.com (mrgmx103) with
 ESMTPSA (Nemesis) id 0MQih7-1Y7UcY2qi5-00U2A2; Sun, 25 Jan 2015 18:46:35
 +0100
Message-ID: <54C52BFA.1080308@HIDDEN>
Date: Sun, 25 Jan 2015 18:46:34 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN> <83y4ots0v3.fsf@HIDDEN> <54C36111.8030003@HIDDEN>
 <83fvb0se6f.fsf@HIDDEN> <54C4C7B2.1080708@HIDDEN> <831tmisvtu.fsf@HIDDEN>
In-Reply-To: <831tmisvtu.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:lyakB4wapHVcuVvvz5g70IjOfOXj1w9fiq7wKyt/cmjUat0x0xr
 0x9kB1Yv0X+iuUIzv7aFM2qRb2A3XoBZQ0lxuoRQtIR2aTXxV/sV+yXACsiUw+AR1EVnr5M
 wpiZAEx5SXyfvRlq0t0koJCuVHRJj/hXlzFy4wRofOE7S9SfZ7uUWcKsUnXKOA06KsPjlbd
 V0tuwI9sOKoAD8kf/fxQw==
X-UI-Out-Filterresults: notjunk:1;
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

 > 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 25 Jan 2015 18:02:01 +0000
Resent-Message-ID: <handler.19661.B19661.14222088821711 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 19661 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.14222088821711
          (code B ref 19661); Sun, 25 Jan 2015 18:02:01 +0000
Received: (at 19661) by debbugs.gnu.org; 25 Jan 2015 18:01:22 +0000
Received: from localhost ([127.0.0.1]:56190 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YFRUv-0000Qp-Fc
	for submit <at> debbugs.gnu.org; Sun, 25 Jan 2015 13:01:22 -0500
Received: from mtaout22.012.net.il ([80.179.55.172]:40396)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1YFRUs-0000IS-KM
 for 19661 <at> debbugs.gnu.org; Sun, 25 Jan 2015 13:01:19 -0500
Received: from conversion-daemon.a-mtaout22.012.net.il by
 a-mtaout22.012.net.il (HyperSendmail v2007.08) id
 <0NIQ00G00VCS9Z00@HIDDEN> for 19661 <at> debbugs.gnu.org;
 Sun, 25 Jan 2015 20:00:54 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0NIQ00GJ4VDI2A50@HIDDEN>;
 Sun, 25 Jan 2015 20:00:54 +0200 (IST)
Date: Sun, 25 Jan 2015 20:00:39 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <54C52BFA.1080308@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <83mw56rb94.fsf@HIDDEN>
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <83ioh2nlow.fsf@HIDDEN> <87sig6xech.fsf@HIDDEN>
 <83fvc5ni0u.fsf@HIDDEN> <E1Y4AVO-00035n-PI@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN> <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN> <878uhrcr5l.fsf@HIDDEN>
 <83sifzjflk.fsf@HIDDEN> <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN> <877fxaa49w.fsf@HIDDEN>
 <831tnicji7.fsf@HIDDEN> <jwviogtdei4.fsf-monnier+emacs@HIDDEN>
 <83y4pp9dku.fsf@HIDDEN> <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <54C27D19.1080102@HIDDEN> <83y4ots0v3.fsf@HIDDEN> <54C36111.8030003@HIDDEN>
 <83fvb0se6f.fsf@HIDDEN> <54C4C7B2.1080708@HIDDEN> <831tmisvtu.fsf@HIDDEN>
 <54C52BFA.1080308@HIDDEN>
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> Date: Sun, 25 Jan 2015 18:46:34 +0100
> From: martin rudalics <rudalics@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19661: wrapping before window-width (new wrap-column text property?) 
Resent-From: Ivan Shmakov <ivan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 27 Jan 2015 22:48:01 +0000
Resent-Message-ID: <handler.19661.B19661.142239886818315 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19661
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 19661 <at> debbugs.gnu.org
Received: via spool by 19661-submit <at> debbugs.gnu.org id=B19661.142239886818315
          (code B ref 19661); Tue, 27 Jan 2015 22:48:01 +0000
Received: (at 19661) by debbugs.gnu.org; 27 Jan 2015 22:47:48 +0000
Received: from localhost ([127.0.0.1]:58368 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YGEvE-0004lK-2F
	for submit <at> debbugs.gnu.org; Tue, 27 Jan 2015 17:47:48 -0500
Received: from fely.am-1.org ([78.47.74.50]:51187)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <ivan@HIDDEN>) id 1YGEvC-0004l7-3W
 for 19661 <at> debbugs.gnu.org; Tue, 27 Jan 2015 17:47:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=siamics.net;
 s=a2013295; 
 h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:Sender:References:Subject:To:From;
 bh=KKLVjKGlXXuK/z91HF24ZmFhjLdRtwEpQAvUbRFKJ+o=; 
 b=gy4VsBfx17DZOCaBt3/OBJBvV+EYT2VtQs/f2ajQTKAW0MOYbaoeOq0S5h793iQd6QhWyowisaylsHL6+p3eR2RlkofLKkyrHBSa6VscaDyzh2RVU/8n8yUB6LCT6RPr/yJfoSpRTVrWY2k4TjzMR/4LzBHz5u1zTVX/E50UMK0=;
Received: from [2a02:2560:6d4:26ca::1:1d] (helo=violet.siamics.net)
 by fely.am-1.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <ivan@HIDDEN>) id 1YGEv8-0004zi-SO
 for 19661 <at> debbugs.gnu.org; Tue, 27 Jan 2015 22:47:43 +0000
Received: from localhost ([::1] helo=violet.siamics.net)
 by violet.siamics.net with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <ivan@HIDDEN>) id 1YGEv1-0002bV-N5
 for 19661 <at> debbugs.gnu.org; Wed, 28 Jan 2015 05:47:35 +0700
From: Ivan Shmakov <ivan@HIDDEN>
References: <CAP1yDHYm2uJ1fnObdN3F4X44w+9nVxHCaFULH9bM-M8Dz207Mw@HIDDEN>
 <87k31fwwyv.fsf@HIDDEN> <E1Y4Snj-0004wy-PF@HIDDEN>
 <87bnmq9ibf.fsf@HIDDEN> <E1Y50Fd-0003BE-GC@HIDDEN>
 <jwv3880fumd.fsf-monnier+emacs@HIDDEN>
 <87lhlrx5fc.fsf@HIDDEN>
 <jwvfvbzh54s.fsf-monnier+emacs@HIDDEN>
 <878uhrcr5l.fsf@HIDDEN> <83sifzjflk.fsf@HIDDEN>
 <87egric2ki.fsf_-_@HIDDEN>
 <jwvtx0eee66.fsf-monnier+emacs@HIDDEN>
 <877fxaa49w.fsf@HIDDEN> <831tnicji7.fsf@HIDDEN>
 <jwviogtdei4.fsf-monnier+emacs@HIDDEN> <83y4pp9dku.fsf@HIDDEN>
 <87387w8r2j.fsf@HIDDEN>
 <87iofxprfv.fsf_-_@HIDDEN> <8361bxtr33.fsf@HIDDEN>
 <87wq4dmgbo.fsf_-_@HIDDEN> <83sif1rybn.fsf@HIDDEN>
Mail-Followup-To: 19661 <at> debbugs.gnu.org
Date: Tue, 27 Jan 2015 22:47:35 +0000
In-Reply-To: <83sif1rybn.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 23 Jan
 2015 23:17:48 +0200")
Message-ID: <87zj93lu2g.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

>>>>> Eli Zaretskii <eliz@HIDDEN> writes:
>>>>> From: Ivan Shmakov  Date: Fri, 23 Jan 2015 19:45:31 +0000

[=E2=80=A6]

 >> 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=E2=80=99s own width, I expect the line to no longer be
	wrapped.

	Also, as Stefan suggests, there can be a distinct =E2=80=9Cinfinity=E2=80=
=9D
	value for the property in question, to inhibit wrapping
	unconditionally for the line(s) covered.

[=E2=80=A6]

--=20
FSF associate member #7257  http://boycottsystemd.org/  =E2=80=A6 3013 B6A0=
 230E 334A

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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