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: Wed, 18 Feb 2015 17:29:42 +0200 Message-ID: <83d2575jbt.fsf@gnu.org> References: <874mqzvnwo.fsf@building.gnus.org> <83h9uzeb4a.fsf@gnu.org> <87bnl7jrr7.fsf@building.gnus.org> <831tm3dt8u.fsf@gnu.org> <87k2zvgj4d.fsf@building.gnus.org> <83siejcahb.fsf@gnu.org> <83sieiar6i.fsf@gnu.org> <83oap5c480.fsf@gnu.org> <87d25lc3xu.fsf@building.gnus.org> <877fvtc2qj.fsf@building.gnus.org> <83wq3s9rmr.fsf@gnu.org> <878ug72064.fsf@building.gnus.org> <838ug79h3x.fsf@gnu.org> <87egpytlrk.fsf@building.gnus.org> <83d25h938i.fsf@gnu.org> <87r3txqajk.fsf@building.gnus.org> <83bnl078jr.fsf@gnu.org> <87r3toaugq.fsf@building.gnus.org> <83ioez6fxy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1424273393 4588 80.91.229.3 (18 Feb 2015 15:29:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2015 15:29:53 +0000 (UTC) Cc: rudalics@gmx.at, larsi@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 18 16:29:45 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 1YO6ZL-0004D5-T1 for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2015 16:29:44 +0100 Original-Received: from localhost ([::1]:51492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YO6ZK-0006aZ-VW for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2015 10:29:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YO6ZE-0006ZL-OC for emacs-devel@gnu.org; Wed, 18 Feb 2015 10:29:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YO6ZA-0003cS-Kd for emacs-devel@gnu.org; Wed, 18 Feb 2015 10:29:36 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YO6ZA-0003cE-Cw for emacs-devel@gnu.org; Wed, 18 Feb 2015 10:29:32 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJZ00F004ACFF00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 18 Feb 2015 17:29:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJZ00FTL4D60OA0@a-mtaout20.012.net.il>; Wed, 18 Feb 2015 17:29:31 +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:183251 Archived-At: > From: Stefan Monnier > Cc: Lars Ingebrigtsen , rudalics@gmx.at, emacs-devel@gnu.org > Date: Wed, 18 Feb 2015 00:53:15 -0500 > > >> The line longest in characters doesn't really say much about what line > >> is longest in pixels. > > I beg to differ. > > They are correlated but I agree with Lars that the correlation is not > strong enough that one can simply take the longest-line-in-chars, > measure it, and expect the result to be the longer in pixel than all > other lines. > > A long line of "llllllll" can be significantly shorter in pixels than > a slightly-less-long line of "mmmmmmm" if you use something > like Helvetica. > > And a long line of "mmmmm" can be significantly shorter than a much > shorter line of "lllll" if the line of "lllll" uses a much larger face > or has an embedded after-string, or ... Granted, I knew that. I never said this was simple, or that the longest line in character units is the only candidate. I suggested to use the character-unit length of the lines inserted into the temporary buffer as a criterion for finding a subset of lines that is large enough to estimate the pixel width of the whole chunk of text, and yet small enough to slash the time needed for window-text-pixel-size to do its job. IOW, I suggested to find a heuristic that would allow to invoke window-text-pixel-size on a shorter chunk of text. Maybe that's unworkable (I didn't try to develop the idea far enough to see if it is), but that's the only idea I had, take it or leave it.