From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Pixel-based display functions Date: Sat, 31 Jan 2015 17:59:31 +1100 Message-ID: <87a90ztoz0.fsf@building.gnus.org> References: <83a914ozsh.fsf@gnu.org> <874mrb1t62.fsf_-_@building.gnus.org> <87vbjrl49k.fsf@violet.siamics.net> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422687629 7781 80.91.229.3 (31 Jan 2015 07:00:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Jan 2015 07:00:29 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 31 08:00:24 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 1YHS2Y-0006zo-Tu for ged-emacs-devel@m.gmane.org; Sat, 31 Jan 2015 08:00:23 +0100 Original-Received: from localhost ([::1]:39848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHS2Y-0006T5-Ep for ged-emacs-devel@m.gmane.org; Sat, 31 Jan 2015 02:00:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHS2J-0006R0-9S for emacs-devel@gnu.org; Sat, 31 Jan 2015 02:00:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YHS2G-0001xu-4I for emacs-devel@gnu.org; Sat, 31 Jan 2015 02:00:07 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]:50527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHS2F-0001rD-TT; Sat, 31 Jan 2015 02:00:04 -0500 Original-Received: from diaman3.lnk.telstra.net ([203.45.116.145] helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1YHS1q-000155-KW; Sat, 31 Jan 2015 07:59:39 +0100 In-Reply-To: (Stefan Monnier's message of "Sat, 31 Jan 2015 01:25:30 -0500") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-MailScanner-ID: 1YHS1q-000155-KW MailScanner-NULL-Check: 1423292379.62052@4HX8hH0/Nr7SwamURka1SA X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.224.195 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:182112 Archived-At: Stefan Monnier writes: > But all those computations of pixel sizes are really what the > redisplay does. When redisplay happens it's kinda too late to make layout decisions. Unless you extend the display engine to allow constraint-based layouts. That'd be cool, but I didn't think that was in the offing? If that's what you're intending, then remember things like that the document language may, for instance, describe a layout like this +---------------+----+----------------+-----------------------+ |R1C1 |R1C2|RA1C2 With Space|R1C2 | +---------------+----+----------------+-----------------------+ |R2C1 and R2C2 in one|RC4-with-a-really-long-unbreakable-thing| |simple box | | +--------------------+----------------------------------------+ where each of the two main columns are said to be 50% of the width, but where one of the elements can't be filled, so you have to extend that column and compress the other columns to make things fit. And you may have columns that themselves contain further column specification, where the same issues apply, so you have to do a descent into each layout cell to try to make things fit. And so on. If this is not what you're planning, then shr needs access to pixel sizes so that it can do these things, and the display engine can just do what it does now. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/