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: Sun, 01 Feb 2015 01:28:16 -0500 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422772119 5257 80.91.229.3 (1 Feb 2015 06:28:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Feb 2015 06:28:39 +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 Sun Feb 01 07:28:38 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 1YHo1N-0000VJ-Lo for ged-emacs-devel@m.gmane.org; Sun, 01 Feb 2015 07:28:37 +0100 Original-Received: from localhost ([::1]:43689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHo1M-0008GH-Jv for ged-emacs-devel@m.gmane.org; Sun, 01 Feb 2015 01:28:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHo1A-0008GB-DM for emacs-devel@gnu.org; Sun, 01 Feb 2015 01:28:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YHo19-0000sq-H0 for emacs-devel@gnu.org; Sun, 01 Feb 2015 01:28:24 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:2327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHo16-0000s7-0Q; Sun, 01 Feb 2015 01:28:20 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsPAOwQflTO+LUv/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAQEdkG8HhEgFiwGSMYM4jkWBeIQZIYJ3AQEB X-IPAS-Result: AjsPAOwQflTO+LUv/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAQEdkG8HhEgFiwGSMYM4jkWBeIQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="109347590" Original-Received: from 206-248-181-47.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([206.248.181.47]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2015 01:28:18 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 3ACD5AE11B; Sun, 1 Feb 2015 01:28:16 -0500 (EST) In-Reply-To: <83wq42i9qn.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 01 Feb 2015 05:36:16 +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:182161 Archived-At: > 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...). 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). Stefan