Re: Infrastructural complexity.

[Thomas Lord <lord@emf.net>]

Martin,

Thank you for the time you've taken.  I, at least,
found your input helpful (see below).

On Fri, 2009-07-31 at 11:08 +0200, martin rudalics wrote:

> Mixing concepts like frames, windows and fringes is beyond my
> imagination.

FWIW, it's a simple point.  You raised concern
that if the edit area is regarded as the same
frame as the frame that owns the window system
window, full width edit area windows won't be as
wide as the frame.  I pointed out that that the
redisplay code already has support for that
situation in the form of fringes.  (That answers
the question for width.  I'm less certain how
height works out.)

>  > Again, I don't see why "fringe" doesn't already
>  > handle this.

> I don't see why and how it does.

You asked how a macro that checks to see if
a window is full width would work and I 
explained how it might work with minimal 
changes to the redisplay engine.

> Sorry, that's too much Infrastructural complexity for my taste so I
> shall give up here.  You'll have to talk this over with someone else.

Please feel no need to apologize.

Again, allow me to thank you for the time you
took and especially for your pointed question 
about the full width window macro.  That question
helped orient me better towards the relevant redisplay
code.

Not to perpetuate an argument but just to sum up
my view, for what it's worth:

At the elisp and command level, one of two concepts must bear
the brunt of newly added complexity: frames or windows.

Windows are already the more complicated abstraction.
They are the more venerable.  They are the more commonly
encountered at the command level.  Window configurations
are an area ripe for improvement and complicating windows
for the sake of control panels will make that improvement
harder.

Frames are a simpler abstraction upon which less relies.
The command set encourages fewer, weaker assumptions by
users about how frames work.

So, adding the new complexity mainly to frames seems
a better idea.  It better fits the mental model that
users already have.  It better preserves some of the 
longest lasting and most successful parts of the elisp
interface.

Additionally, it has been mentioned that if we have
"window groups", there will follow desire to make them
visually distinct.   It seems to me that this will introduce
a mechanism isomorphic to frame properties, and yet
strangely, arbitrarily distinct from frame properties.

Additionally, in "other applications", control panels
often have elements such as toolbars - just as do
Emacs frames.   Having used such applications, I'm inclined
to think that that's a nice feature.  Adding toolbar
support to window groups would be another way in which
the question arises: "Why aren't these frames?  Isn't
this a redundant abstraction?"

I can think of but one advantage to window groups 
instead of attached frames and that is simply that
*initially* window groups can probably be implemented 
without touching the redisplay code.   That is not a 
small advantage, I'm sure.   The price for claiming that
advantage seems a bit too high, to me.

-t