emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: moving window handling into lisp


From: Lennart Borgman
Subject: Re: moving window handling into lisp
Date: Wed, 12 Aug 2009 17:57:17 +0200

On Wed, Aug 12, 2009 at 3:33 PM, martin rudalics<address@hidden> wrote:

> ... It can make it loop infinitely.  ISTR 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.  I'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?  What 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
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]