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: Sun, 01 Feb 2015 17:37:30 +0200 Message-ID: <83r3u9iqx1.fsf@gnu.org> References: <8361bqogah.fsf@gnu.org> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422805086 25055 80.91.229.3 (1 Feb 2015 15:38:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Feb 2015 15:38:06 +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 Sun Feb 01 16:38:02 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 1YHwb2-0005lV-P9 for ged-emacs-devel@m.gmane.org; Sun, 01 Feb 2015 16:38:00 +0100 Original-Received: from localhost ([::1]:50876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHwb2-0003Mq-5O for ged-emacs-devel@m.gmane.org; Sun, 01 Feb 2015 10:38:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHwav-0003Mf-HN for emacs-devel@gnu.org; Sun, 01 Feb 2015 10:37:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YHwaq-0007Lo-I3 for emacs-devel@gnu.org; Sun, 01 Feb 2015 10:37:53 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:54704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHwaq-0007Lc-6H for emacs-devel@gnu.org; Sun, 01 Feb 2015 10:37:48 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NJ300H00N31JV00@mtaout29.012.net.il> for emacs-devel@gnu.org; Sun, 01 Feb 2015 17:34:09 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJ300HLPN8XQ700@mtaout29.012.net.il>; Sun, 01 Feb 2015 17:34:09 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 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:182175 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Sun, 01 Feb 2015 01:28:16 -0500 > > > Or maybe I don't understand which functions you want to expose, so > > please elaborate. > > I just don't want Elisp code to compute pixel sizes based on > glyph info. It's what the C code already does. So whenever Elisp code > tries to do that, it's a mistake (not so much because we should do it > in C, but because we end up having to reproduce in new code what > existing code already does, which is exactly what's going on with this > whole discussion about guessing which chunks of text will use the same > font and how we should handle chars which aren't covered by the font > etc...). I don't think Lars's Elisp does what the display engine does. It's close, but different enough to warrant a different approach. See below. > IIUC in the case at hand, the function which Lars needs is slightly > different from what we already expose. Instead of > pixel-size-of-chunk-of-text, we want to have position-of-pixel-in-text > (i.e. you pass a chunk of text, along with a pixel position, and it > returns the position of that pixel in the text). I.e. something more > like vertical-motion (which receives a pixel horizontal coordinate and > figures out where that is in the text). I explicitly mentioned vertical-motion in one of my previous messages, and explained there how to use it to find buffer position that corresponds to a given pixel coordinate. Lars said it wasn't what he needed, I don't know why. I assume he will be able to explain that. If he can use vertical-motion, that's fine with me. If not, your position-of-pixel-in-text suggestion will suffer from the same problem. I also briefly considered writing a primitive such as position-of-pixel-in-text, but eventually decided against it, because I don't think that's what Lars needs. Here's why. First, Lars has no "text" in the sense that there's no buffer text to render. What he has is a _spec_ for the layout, in the form of HTML. That spec provides a bunch of strings that need to be rendered under certain constraints, but these strings are not inserted into any buffer by the time the code we are discussing runs, and the move_it_* functions we use in vertical-motion and elsewhere won't help us, because they do need a buffer to iterate over. (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.) 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.