From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Pixel-based display functions Date: Mon, 02 Feb 2015 19:21:58 +0200 Message-ID: <83fvaogrex.fsf@gnu.org> References: <87k306pfi9.fsf@building.gnus.org> <87egqekrd7.fsf@building.gnus.org> <877fw53eat.fsf@building.gnus.org> <877fw4zsdv.fsf@building.gnus.org> <831tmcn4k4.fsf@gnu.org> <87386szq1w.fsf@building.gnus.org> <83wq44ljm9.fsf@gnu.org> <87vbjowlqv.fsf@building.gnus.org> <83oapglbx6.fsf@gnu.org> <83lhkkl23i.fsf@gnu.org> <83bnlgkl1s.fsf@gnu.org> <837fw3l7uz.fsf@gnu.org> <83wq42i9qn.fsf@gnu.org> <83r3u9iqx1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422897773 18760 80.91.229.3 (2 Feb 2015 17:22:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2015 17:22:53 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 02 18:22:52 2015 Return-path: Envelope-to: ged-emacs-devel@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 1YIKi3-0008AV-G5 for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 18:22:52 +0100 Original-Received: from localhost ([::1]:55716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIKi2-0007EN-O5 for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 12:22:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIKhb-00077j-Gl for emacs-devel@gnu.org; Mon, 02 Feb 2015 12:22:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIKhW-00082B-BG for emacs-devel@gnu.org; Mon, 02 Feb 2015 12:22:23 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIKhW-0007yq-4V for emacs-devel@gnu.org; Mon, 02 Feb 2015 12:22:18 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJ500M00MV96V00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 02 Feb 2015 19:22:11 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJ500LICMWZS6A0@a-mtaout20.012.net.il>; Mon, 02 Feb 2015 19:22:11 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182273 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Mon, 02 Feb 2015 11:43:23 -0500 > > > I don't think Lars's Elisp does what the display engine does. > > All I know is that his code will give wrong results if it doesn't > reproduce faithfully enough what the redisplay does. Not necessarily, since an HTML browser doesn't need to implement all the gazillion display features that redisplay needs to handle. Not even close. It just needs to render text with faces and sometimes with images. > And that to me is a clear sign that it should reuse (some part of) > the redisplay code I agree, and it does. font-get-glyphs, window-text-pixel-size, vertical-motion, etc. all reuse the display engine code. > > (Of course, he could insert each string into a scratch buffer, but > > that's a waste, and doesn't solve the other problem, described below.) > > I think this "waste" would be negligible. Maybe, maybe not. It all depends on how many small strings will be needed to be rendered. > > Second, there's a subtlety in move_it_* functions that was never > > explicitly raised in this discussion, but which becomes rather > > important if you want to consider reusing the move_it_* functions for > > this use case: they produce glyphs in the _visual_ order. So if the > > text to be rendered includes R2L characters, you might break text > > between screen lines incorrectly. (If this isn't clear enough, I can > > elaborate.) Also, you will have to deal with the situation where > > (position-of-pixel-in-text FROM TO) is _less_ than > > (position-of-pixel-in-text FROM (1- TO)). That is a complication that > > Lars would surely like to avoid, I presume. By contrast, > > font-get-glyphs works in the logical order. > > I think solving this problem is *hard*. I explicitly suggested a way that avoids the need to solve it. > The problem is not just whether you work on the logical or visual > order, but in order to get the right behavior when filling bidi text > inside columns, is that you'll have to partly reimplement the bidi > code. Not really. Certainly not when the screen lines are L2R and there's some R2L text in it. R2L lines are slightly harder, in that you need to append to such lines a 'space' display property of a suitably calculated width, to make them flushed to the right. What other issues do you envision? And what do you think the display engine does to fill bidi text, anyway? > Maybe the best approach would be to make position-of-pixel-in-text > return some info about the reordering that redisplay performs. What information would that be? Why would an application be interested in it? > PS: who still would prefer refilling single-column text in the redisplay > itself, since it makes it lazy, and makes it work right even when the > buffer is displayed in different windows/frames with different fonts. I agree that this feature would be useful. However, how to use it in this case is not clear to me: recall that there's no buffer to render here, only a bunch of strings, each one with some kind of specification, lifted from the HTML source, regarding their layout in table cells. The display engine cannot work with such kind of layout spec, we'd need to invent some new machinery on top of teaching it how to wrap at arbitrary pixel coordinate.