martin rudalics wrote:
> > Hmm, its a good starting point but not complete. Simply think of
> ECB > as a tool which wants to display some special windows beside an
> > "edit-area" whereas the former one are used to display
> informational > context stuff as parsed tags of the current buffer
> in the edit-area > or a file- and directory tree or a buffer-history
> or or or... > The latter one (the edit-area) should give the user
> the feeling as > if all windows of this edit-area would be the only
> windows in the > frame so all standard operations would act as if
> the edit-windows > would be the only windows in the frame...
>
> Is the edit-area always a rectangle? Can it be always created by
> recursively subdividing an initial window? Is there always at most
> one edit-area? Is there at most one edit-area in one and the same
> frame?
To all questions: YES, except the recursively subdividing one: What do
you mean exactly?
Currently the concept of ECB is:
- Exactly one frame
- The is *always* exact ONE edit-area, which is always a rectangle
- The special windows are located either at the left, at the right or
on top of the edit area
- the edit-arey can be subdivided in as many windows as possible
>
> > Well, a window property for preventing other windows outside the
> > edit-area from being deleted or for a navigation only in the edit-
> > area by other-window would be a good starting point but its not the
> > end of the story:
>
> Can all operations you need be subdivided into whether they either
> apply to all windows in the edit-area or to all windows outside the
> edit-area?
Almost: Currently ECB needs three canonical window-lists:
- full window list of the ECB-frame
- all windows in the edit-area
- all special ECB-windows
- the compile-window (always displayed at bottom) when displayed
canonical means: always the same sequence beginning from top/left-most,
ie. the same order an unadviced version of `next-window' would walk
through
>What mechanism do you use to access a window outside the
> edit-area - do you suspend advices?
What do you mean with "access"?
>
> > What about saving and later restoring the current window layout of
> the > edit-area (means only these windows inside the edit-area)
> without > affecting the layout of the special windows?
>
> Do you also need to save and restore the layout of the non-edit-area?
> Earlier I got the impression that the non-edit-area would be
> immutable, so you could easily include it in the saved configuration.
Yes, currently the layout of the non-edit-area is immutable in this
sense that redrawing the whole layout of the ECB-frame resizes the
special windows back to their cusomized (via customize) sizes
(can be absolute or - prefered - relative) whereas the sizes
of the windows in the edit-area will be preserved by a layout-redraw,
means the sizes the user has choosen by dragging modeline or what else...
> Do you want the edit-area occasionally occupy the entire frame?
Yes, there is a command which allows to hide or to toggle visibility
of the special windows - you can imagine that this needs complex and
smart code-stuff to preserve the window-layout of the edit-area during
that, but it works stable and error-less...
IMHO temporarly hidding the special windows (ie. only the edit-area
and all its windows are visible in the ECB-frame) is a very important
feature of an IDE...
>
> > And how to implement an option like
> > `ecb-layout-always-operate-in-edit-window'
> > (see docstring) without adviceing e.g. switch-to-buffer?
> >
> > Just take a look at the docstring of the adviced
> `switch-to-buffer': > IMHO even with the new pins advices are needed
> to offer a smart and > convenient usage of an IDE like ECB...
>
> Couldn't this be done with the help of a `switch-buffer-function'?
Yes, probably this would be possible!
>
> > maybe i will find next weekend the needed time to write down a
> small > "functional reqirement specification" which core
> functionality would > be required by Emacs to rewrite ECB without a
> lot of its advices or > at least with much simpler advices...
>
> If possible, please list also invariants which can be used to cut down
> the overhead for providing these requirements. Like "for any frame
> the number of edit-areas it displays is zero or one".
yes, this was my intention - see above...
Klaus
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.