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 23:17:48 +0200 Message-ID: <83sif1rybn.fsf@gnu.org> 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> <87wq4dmgbo.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 1422047894 26442 80.91.229.3 (23 Jan 2015 21:18:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 21:18:14 +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 22:18:13 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 1YElcK-0006q6-VL for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 22:18:13 +0100 Original-Received: from localhost ([::1]:33188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YElcJ-0006qR-Ql for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 16:18:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YElcF-0006qA-Rw for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:18:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YElcA-0001DF-NI for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:18:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YElcA-0001DB-KC for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YElcA-00052Q-E7 for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:18: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 21:18: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.142204787619351 (code B ref 19661); Fri, 23 Jan 2015 21:18:02 +0000 Original-Received: (at 19661) by debbugs.gnu.org; 23 Jan 2015 21:17:56 +0000 Original-Received: from localhost ([127.0.0.1]:54625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElc3-000523-Pg for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:17:56 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:50698) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElc0-00051o-2V for 19661@debbugs.gnu.org; Fri, 23 Jan 2015 16:17:53 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NIN00I00EYQP700@mtaout26.012.net.il> for 19661@debbugs.gnu.org; Fri, 23 Jan 2015 23:17:39 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIN009U4F5EQT70@mtaout26.012.net.il>; Fri, 23 Jan 2015 23:17:39 +0200 (IST) In-reply-to: <87wq4dmgbo.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:98654 Archived-At: > From: Ivan Shmakov > 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.