From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Wed, 12 Aug 2009 17:57:17 +0200 Message-ID: References: <4A7010D7.3050305@gmx.at> <4A81374E.9050401@gmx.at> <4A8283EF.5080007@gmx.at> <4A82C49A.4000209@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250092658 29137 80.91.229.12 (12 Aug 2009 15:57:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Aug 2009 15:57:38 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 12 17:57:32 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MbGCh-0002Kq-Fd for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2009 17:57:31 +0200 Original-Received: from localhost ([127.0.0.1]:58054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbGCe-0007c1-NB for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2009 11:57:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbGCZ-0007bI-TX for emacs-devel@gnu.org; Wed, 12 Aug 2009 11:57:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbGCU-0007Yr-Pt for emacs-devel@gnu.org; Wed, 12 Aug 2009 11:57:23 -0400 Original-Received: from [199.232.76.173] (port=58185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbGCU-0007Yo-Mw for emacs-devel@gnu.org; Wed, 12 Aug 2009 11:57:18 -0400 Original-Received: from mail-yx0-f172.google.com ([209.85.210.172]:41224) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbGCU-0006eL-80 for emacs-devel@gnu.org; Wed, 12 Aug 2009 11:57:18 -0400 Original-Received: by yxe2 with SMTP id 2so153413yxe.14 for ; Wed, 12 Aug 2009 08:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/OOXaRvR7yRQZGGOUhyTd1Ae4E8d6QMBapTF5iSUdtA=; b=CBtszQN361BoOR/6TceXpdd5ln1DKWWKJL1KhFhfvLDUIFerRRpPQAmXOEYkE2wS9I bSE7XxXOqkHhA0waqEpq1pThdd9O6XyDG6nWzqq4IRHZOM9UImuZaxGviMSZKMnYi++4 fuDNKykfj5cTRDQMG89OVBUPd2OkN1ACezh/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TKgCqoPCwBJ+QFYcSskAbbkX8SMfYlIgvkNOJEuD+DlqVOLZxUUiq8Gf0TKA98qU07 wtYH4gtqAG5wTCBnjU2dFYEudF1g3aDr6c5NqBEr32gHrX61/TR9F3/WDHA7cO0XKfqa hpeb946Ric9kzK4nNf32dwA9najnOHGUtREP0= Original-Received: by 10.100.197.19 with SMTP id u19mr195463anf.178.1250092637613; Wed, 12 Aug 2009 08:57:17 -0700 (PDT) In-Reply-To: <4A82C49A.4000209@gmx.at> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114146 Archived-At: On Wed, Aug 12, 2009 at 3:33 PM, martin rudalics wrote: > ... It can make it loop infinitely. =C2=A0ISTR an early problem with (La)= TeX > really hanging when inserting a footnote would make a page overfull, > leaving it away underfull. I think the problems in the currently used logic may show up like that, yes. But I am sure you know much more about that. >> I do not understand what you mean. You have found that it can't be >> solved in this case, or? What am I missing? > > I don't know. =C2=A0I'm still waiting to see how your algorithm handles > windows getting too small and fixed size windows. I do not think that fixed size windows is any problem in the algorithm I gave. You just use that size both when walking up and collecting (minimal) sizes and when walking down to compute sizes to apply. There is so to say no way to get too small windows when computing sizes to apply, but you can of course find that there is not enough space if the "sum" of the minimum sizes is too large. But you will easily see that since on each level when you are going down you know how much space each sublevel as a mininum needs. I forgot to say that you of course have to use the algorithm separately for widht and height. Maybe I think totally wrong (I admitedly do that sometimes ... ;-) so please help me and tell me what problems you see in the above. If the space is not enough then there is a problem, yes, but that is a real world problem so to say. It must be handled with a decision. We must make some rules for it. I suggest simply FAIL, raise an error. (Maybe catch+throw would be better since this really is expected behaviour, but we have no structure, no predefined "catch names" that could make this understandable by the programmer/user. And no messages tied to it.) >> Yes. The primitives must be changed so there is a chance of putting >> back the tree in 4 at all. (But I think I have said that several >> times.) > > Which primitives? =C2=A0What does "putting back the tree" mean? A very good question. First the code that computes the sizes must be breaken out so the above algorithm can be used when walking up and just collecting the sizes. (Nothing is changed when walking up and collecting sizes.) Then maybe some code must be changed so that you can walk down and apply the sizes - without anything jumping in and preventing it. I guess I might be missing something there, but I thought collecting the sizes first should prevent anything bad happening when applying them. However I think you understand this better. Is there something I am missing in this step? > martin >