[Top][All Lists]
[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
- Re: Infrastructural complexity., (continued)
- Re: Infrastructural complexity., martin rudalics, 2009/07/21
- Re: Infrastructural complexity., Thomas Lord, 2009/07/21
- Re: Infrastructural complexity., martin rudalics, 2009/07/22
- Re: Infrastructural complexity., Thomas Lord, 2009/07/22
- Re: Infrastructural complexity., martin rudalics, 2009/07/22
- Re: Infrastructural complexity., Thomas Lord, 2009/07/22
- Re: Infrastructural complexity., martin rudalics, 2009/07/23
- Re: Infrastructural complexity., Thomas Lord, 2009/07/23
- Re: Infrastructural complexity., joakim, 2009/07/23
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/23
- Re: Infrastructural complexity.,
joakim <=
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/23
- Re: Infrastructural complexity., Thomas Lord, 2009/07/23
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24