emacs-devel
[Top][All Lists]
Advanced

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

Re: Infrastructural complexity.


From: joakim
Subject: Re: Infrastructural complexity.
Date: Thu, 23 Jul 2009 22:35:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)

Lennart Borgman <address@hidden> writes:

> On Thu, Jul 23, 2009 at 9:17 PM, <address@hidden> wrote:
>
>>> That is, it seems to me - and yes this is
>>> necessarily just an opinion about user
>>> interfaces - that the edit area windows
>>> should behave exactly like a traditional
>>> Emacs frame.  For example, C-x o navigates
>>> (normally) just among the edit area windows.
>>> Normal splitting or deleting of a window changes
>>> only edit area windows.  Programs that look for,
>>> say, a largest window to use to pop up some
>>> buffer should look only to the edit area (unless
>>> explicitly written to do otherwise).  It should
>>> take a special gesture (keystroke or mouse, different
>>> from C-x o) to select a window in a control panel
>>> and, once its selected the set of windows in that
>>> control panel are then the focus (the C-x o ring,
>>> etc.).
>>
>> The way I see window groups, they behave like you describe.
>
>
> I think there is one more part of Thomas suggestion: that there should
> be default framelets/window groups at each frame border (the 16
> configs).

In my view that sort of functionality goes on top of window groups.
Framelets could go on top of window groups, and ECB on top of
Framelets.

There are 2 proposals for window groups, mine and Martins(which is
probably more advanced than mine). I initialy just wanted to be able to
"pin" windows, so they werent affected by c-x 1 and stuff like that. I
really just wanted a small window to hold the information the mode-line
normaly is misused to hold. So I wanted something lighter than a
frame. Oh wait, thats a framelet :)

Anyway, blue sky visions of what Emacs could do is good.

Looking at actual code that implements nearly everything of the blue sky
visions is also good. 


> It might be a good idea that they are there by default. ECB for
> example works according to a similar visual model.
>
> One way to make it simple to implement that idea could be to have
> hidden windows corresponding to those framelets (ie the framelets
> should live inside them). That way iit could be easy to hide/show them
> and one could make a set of function for handling them.
>
> But then we need to have hidden windows though, but that does not seem
> fantastically difficult. At least not to me that never tried to look
> at that code ...
>
>
-- 
Joakim Verona




reply via email to

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