From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ivan Shmakov Newsgroups: gmane.emacs.bugs Subject: bug#19661: wrapping before window-width (new wrap-column text property?) Date: Fri, 23 Jan 2015 19:45:31 +0000 Message-ID: <87wq4dmgbo.fsf_-_@violet.siamics.net> References: <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> <8361bxtr33.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422042381 736 80.91.229.3 (23 Jan 2015 19:46:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 19:46:21 +0000 (UTC) To: 19661@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 20:46:15 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 1YEkBK-00036n-Er for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 20:46:14 +0100 Original-Received: from localhost ([::1]:32843 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEkBJ-0001p1-Pa for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 14:46:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEkBF-0001ot-1a for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 14:46:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEkB9-0001iA-8K for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 14:46:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEkB8-0001i3-RE for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 14:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YEkB8-0002qt-9W for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 14:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ivan Shmakov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Jan 2015 19:46:02 +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.142204234710939 (code B ref 19661); Fri, 23 Jan 2015 19:46:02 +0000 Original-Received: (at 19661) by debbugs.gnu.org; 23 Jan 2015 19:45:47 +0000 Original-Received: from localhost ([127.0.0.1]:54597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEkAs-0002qN-Qw for submit@debbugs.gnu.org; Fri, 23 Jan 2015 14:45:47 -0500 Original-Received: from fely.am-1.org ([78.47.74.50]:50714) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEkAm-0002q9-3A for 19661@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=; Original-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 ) id 1YEkAl-0005H5-0E for 19661@debbugs.gnu.org; Fri, 23 Jan 2015 19:45:39 +0000 Original-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 ) id 1YEkAd-0003G4-Pc for 19661@debbugs.gnu.org; Sat, 24 Jan 2015 02:45:31 +0700 Mail-Followup-To: 19661@debbugs.gnu.org In-Reply-To: <8361bxtr33.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 23 Jan 2015 18:11:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) 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:98648 Archived-At: >>>>> Eli Zaretskii 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