From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19661: wrapping before window-width (new wrap-column text property?) Date: Fri, 23 Jan 2015 18:11:12 +0200 Message-ID: <8361bxtr33.fsf@gnu.org> References: <83ioh2nlow.fsf@gnu.org> <87sig6xech.fsf@ferrier.me.uk> <83fvc5ni0u.fsf@gnu.org> <87k31fwwyv.fsf@ferrier.me.uk> <87bnmq9ibf.fsf@ferrier.me.uk> <87lhlrx5fc.fsf@building.gnus.org> <878uhrcr5l.fsf@building.gnus.org> <83sifzjflk.fsf@gnu.org> <87egric2ki.fsf_-_@violet.siamics.net> <877fxaa49w.fsf@violet.siamics.net> <831tnicji7.fsf@gnu.org> <83y4pp9dku.fsf@gnu.org> <87387w8r2j.fsf@violet.siamics.net> <87iofxprfv.fsf_-_@violet.siamics.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1422029533 23794 80.91.229.3 (23 Jan 2015 16:12:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 16:12:13 +0000 (UTC) Cc: 19661@debbugs.gnu.org To: Ivan Shmakov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 17:12:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YEgqA-0001Bb-7N for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 17:12:10 +0100 Original-Received: from localhost ([::1]:60132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEgq9-0004L6-IL for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 11:12:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEgq5-0004Kq-T0 for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 11:12:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEgq2-00018r-LD for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 11:12:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEgq2-00018n-Hz for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 11:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YEgq1-0004lA-Pv for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 11:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Jan 2015 16:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19661 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19661-submit@debbugs.gnu.org id=B19661.142202948318249 (code B ref 19661); Fri, 23 Jan 2015 16:12:01 +0000 Original-Received: (at 19661) by debbugs.gnu.org; 23 Jan 2015 16:11:23 +0000 Original-Received: from localhost ([127.0.0.1]:54493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEgpO-0004kF-I3 for submit@debbugs.gnu.org; Fri, 23 Jan 2015 11:11:23 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:65486) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEgpJ-0004jw-Vu for 19661@debbugs.gnu.org; Fri, 23 Jan 2015 11:11:19 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NIN00G000VVJA00@a-mtaout20.012.net.il> for 19661@debbugs.gnu.org; Fri, 23 Jan 2015 18:11:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIN00GDX0YM8JB0@a-mtaout20.012.net.il>; Fri, 23 Jan 2015 18:11:10 +0200 (IST) In-reply-to: <87iofxprfv.fsf_-_@violet.siamics.net> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98635 Archived-At: > 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. > > 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.