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: Fri, 06 Feb 2015 16:12:01 +0200 Message-ID: <831tm3dt8u.fsf@gnu.org> References: <83bnlgkl1s.fsf@gnu.org> <837fw3l7uz.fsf@gnu.org> <54CD4B27.4080201@gmx.at> <874mr6qvi5.fsf@building.gnus.org> <87sieqpfxh.fsf@building.gnus.org> <54CDE908.7050908@gmx.at> <87ioflq0dz.fsf@building.gnus.org> <54CE2187.9070003@gmx.at> <83lhkhiq8t.fsf@gnu.org> <54CE54A3.1020707@gmx.at> <838ughilmo.fsf@gnu.org> <54CE6BD2.8000402@gmx.at> <8361bliin0.fsf@gnu.org> <83386piiby.fsf@gnu.org> <87oap9yoti.fsf@building.gnus.org> <874mqzvnwo.fsf@building.gnus.org> <83h9uzeb4a.fsf@gnu.org> <87bnl7jrr7.fsf@building.gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423232036 27177 80.91.229.3 (6 Feb 2015 14:13:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Feb 2015 14:13:56 +0000 (UTC) Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 06 15:13:51 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 1YJjfL-0003Oh-3a for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 15:13:51 +0100 Original-Received: from localhost ([::1]:48555 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJjfK-00021N-Br for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 09:13:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJjdk-0007mi-Qh for emacs-devel@gnu.org; Fri, 06 Feb 2015 09:12:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJjdf-0004hS-Bw for emacs-devel@gnu.org; Fri, 06 Feb 2015 09:12:12 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJjdf-0004eu-3k for emacs-devel@gnu.org; Fri, 06 Feb 2015 09:12:07 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJC00E00SK9FE00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 06 Feb 2015 16:12:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJC00ENESS3DG20@a-mtaout20.012.net.il>; Fri, 06 Feb 2015 16:12:03 +0200 (IST) In-reply-to: <87bnl7jrr7.fsf@building.gnus.org> 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:182527 Archived-At: > From: Lars Ingebrigtsen > Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > Date: Fri, 06 Feb 2015 20:47:40 +1100 > > shr inserts text as long lines into the buffer, and I then use > `vertical-motion' to go to the desired width, and then backtracking > finding a fill point using the kinsuko algorithm. Then a newline is > inserted, and we repeat until the line is completely filled. When you "repeat", do you start from the part of the line that's left, without the part that is before the just-inserted newline, or from the original long one? The time it takes vertical-motion to do its job will be smaller if the line is shorter. Also, try invoking vertical-motion from a position that is not immediately after a newline, I think this might speed it up a little more. > >> But it's all kinda moot since `window-text-pixel-size' doesn't work on > >> non-displayed buffers (yet). > > > > window-text-pixel-size is equivalent to vertical-motion, so I don't > > understand why you need both. Can you explain? > > `window-text-pixel-size' tells me what width I ended up with, while > `vertical-motion' goes to an approximate fill point. Why do you need to know what width you ended up with? Or maybe I don't understand "ended up with" when -- before or after vertical-motion did its job? IOW, do you need window-text-pixel-size for measuring the long unfilled line, or the lines after filling? > >> I wonder whether a faster interface would be to have a version of > >> `window-text-pixel-size' that returns a vector of glyph sizes. > > > > ??? Isn't that font-get-glyphs that you already tried? If not, why > > not? What API would you like to have for that hypothetical function? > > I though we established pretty thoroughly that for `font-get-glyphs' to > be a solution, we'd have to reimplement too much of the redisplay > algorithm in Emacs Lisp (what with segmenting on scripts and faces, and > then having to see whether a script uses multiple fonts, etc). And it > was too slow during my testing. So what kind of API would you like to have? > >> Of course, computing the vector may be unreasonably slow. > > > > It is again equivalent to vertical-motion and font-get-glyphs, so it's > > not slow. But I don't yet see the issue clearly enough to tell what > > could be done for you, so please post more information about what you > > are trying to do. > > It would be equivalent to a `window-text-pixel-size' that advances one > character at a time (since we'd avoid the entire `font-at' problem), and > returns an vector of pixel points (instead of calling move_it_to just > once). You are describing an implementation. Please describe the API and the contract instead. Also, as long as you use these functions, there's still a problem with visual vs logical order that needs to be solved.