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#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Date: Sat, 02 Feb 2013 20:36:10 +0200 Message-ID: <837gmqbm1x.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> <510D58FC.2030605@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1359830233 2563 80.91.229.3 (2 Feb 2013 18:37:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Feb 2013 18:37:13 +0000 (UTC) Cc: 13399@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 02 19:37:33 2013 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 1U1hy0-0002Tm-Oo for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Feb 2013 19:37:32 +0100 Original-Received: from localhost ([::1]:52644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1hxi-0002S7-Gz for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Feb 2013 13:37:14 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1hxe-0002N1-8g for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 13:37:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U1hxc-0001e4-6W for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 13:37:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55940) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1hxc-0001dY-2H for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 13:37:08 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U1hyU-0008QB-I5 for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 13:38:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Feb 2013 18:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13399 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13399-submit@debbugs.gnu.org id=B13399.135983024132276 (code B ref 13399); Sat, 02 Feb 2013 18:38:02 +0000 Original-Received: (at 13399) by debbugs.gnu.org; 2 Feb 2013 18:37:21 +0000 Original-Received: from localhost ([127.0.0.1]:33170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hxo-0008OV-Ic for submit@debbugs.gnu.org; Sat, 02 Feb 2013 13:37:20 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:33407) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hxl-0008OI-Cw for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 13:37:18 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MHL00L00UICQB00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 20:36:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHL00LTOVO7Q950@a-mtaout22.012.net.il>; Sat, 02 Feb 2013 20:36:07 +0200 (IST) In-reply-to: <510D58FC.2030605@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:70615 Archived-At: > Date: Sat, 02 Feb 2013 19:20:44 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org > > >> + /* Maximum x pixel position encountered within a display line. */ > >> + int max_current_x; > > > > Adding a struct member for the sake of just one user sounds > > unjustified. Can we instead make move_it_to accumulate the value > > internally and return it? > > I don't know. IIUC most iterator functions never return something > useful. Because there was no need. Now there is. > And if one wants to glue together the results of subsequent calls of > move_it_to, it might make sense to not reset the value internally. It should be simple enough to add them up externally. Adding a member to 'struct it' has the downside of enlarging the structure, which slows down any code that copies such structs. We are going to punish all the users for the benefit of just one. So I think we should avoid that. > > In any case, the comment is inaccurate, since the value is accumulated > > across all the display lines traversed by the iterator, not computed > > per display line. > > Would "within any line traversed by the iterator" be better? Yes. > > >> +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size, Swindow_buffer_pixel_size, 0, 5, 0, > > > > Why not window-text-pixel-size? The "buffer" part doesn't belong > > here, I think. > > Since I also look at buffer portions outside the window, such a term > wouldn't be very accurate either. Then how about text-pixel-size? > >> + /* Actually, we never want move_it_to stop at to_x. But to make sure > >> + that move_it_in_display_line_to always moves far enough, we set it > >> + to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X. */ > >> + move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1, > >> + MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y); > > > > Did you test what this does when END is covered by a display string? > > No. I didn't try invisible text and other atrocities either. In fact, > I never experimented with a non-ZV end position so far. Which problems > do you see? move_it_to might overshoot in those cases, i.e. you get more pixels than strictly needed. But OTOH, I see no way of asking for more specific limits in these cases, nor a use-case where that could be needed. So I guess we are okay until someone hollers.