From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Pixel-based display functions Date: Mon, 02 Feb 2015 11:43:23 -0500 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422895431 10403 80.91.229.3 (2 Feb 2015 16:43:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2015 16:43:51 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 02 17:43:47 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 1YIK6B-0001mC-Rp for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 17:43:44 +0100 Original-Received: from localhost ([::1]:55416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIK6B-00050n-2n for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 11:43:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIK5y-00050d-9M for emacs-devel@gnu.org; Mon, 02 Feb 2015 11:43:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIK5x-0006eL-4l for emacs-devel@gnu.org; Mon, 02 Feb 2015 11:43:30 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:3915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIK5t-0006dT-Fn; Mon, 02 Feb 2015 11:43:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsPAOwQflRsoX+8/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQcCAR+QbweESAWLAYxUl1qBeIQZIYJ3AQEB X-IPAS-Result: AjsPAOwQflRsoX+8/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQcCAR+QbweESAWLAYxUl1qBeIQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="109461067" Original-Received: from 108-161-127-188.dsl.teksavvy.com (HELO ceviche.home) ([108.161.127.188]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2015 11:43:24 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id F259C66100; Mon, 2 Feb 2015 11:43:23 -0500 (EST) In-Reply-To: <83r3u9iqx1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 01 Feb 2015 17:37:30 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:182269 Archived-At: >> 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. All I know is that his code will give wrong results if it doesn't reproduce faithfully enough what the redisplay does. And that to me is a clear sign that it should reuse (some part of) the redisplay code, since it's the simpler and most reliable way to make sure that the behavior is faithful. > (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. > 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*. 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. Maybe the best approach would be to make position-of-pixel-in-text return some info about the reordering that redisplay performs. Stefan 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.