[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: |
Sun, 19 Jul 2009 13:12:55 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) |
martin rudalics <address@hidden> writes:
>> One large difference, though, is that framelets really require
>> more changes to the C code of Emacs while window groups can
>> get away with little or 0 changes to the C code. From some of the
>> conversation, I suspect that this is one of the big reasons that
>> there is support for window groups. I sympathize with that
>> but I think that the proposed complexity in core lisp code
>> is sufficiently problematic that it's at the very least not
>> an obviously good idea to go with window groups.
>
> I'm afraid that window groups won't get away with little or 0 changes to
> the C code. OTOH, framelets could get away with hardly any changes to C
Yes, the current Window Groups patch touches nearly only C code.
> code. Speedbar has its separate frame, initially attached to some
> existing frame, can be torn off and moved around. There's no reason why
> we can't additionally build around an existing Emacs frame a message
> frame, a log frame, a tools frame. All these would come (optionally)
> with their own tool bar, menu bar, tabs, mode-/header-line and could be
> handled by the window manager of your choice. The display code might
> need some additional means to handle zero sized frames or windows, but
> that's all IMHO.
> Personally, I prefer to always stay within one and the same frame and
> therefore never use the speedbar. So in practice I probably would never
> work with code based on distinct frames. Maybe also, converting
> existing ECB code by substituting windows with say root-windows of
> frames might be difficult but likely no more than making it work with
> window groups.
I also prefer to work with only 1 frame. ECB has code to make the
Speedbar live in an Emacs window, which makes Speedbar very nice for me.
> martin
--
Joakim Verona
- Re: Infrastructural complexity., (continued)
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/18
- Re: Infrastructural complexity., Thomas Lord, 2009/07/19
- 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Lennart Borgman, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Lennart Borgman, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: Infrastructural complexity., martin rudalics, 2009/07/19
- Re: Infrastructural complexity.,
joakim <=
- Re: Infrastructural complexity., Miles Bader, 2009/07/19
- Re: Infrastructural complexity., martin rudalics, 2009/07/20
- Re: Infrastructural complexity., Miles Bader, 2009/07/20
- Re: Infrastructural complexity., martin rudalics, 2009/07/20
- Re: Infrastructural complexity., Chong Yidong, 2009/07/20
- Re: Infrastructural complexity., Miles Bader, 2009/07/20
- Re: Infrastructural complexity., martin rudalics, 2009/07/20
- Re: Infrastructural complexity., Miles Bader, 2009/07/20
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/20
- Re: Infrastructural complexity., Thomas Lord, 2009/07/20