Emacs Code Browser

klaus.berndl | 28 Apr 2008 13:50

RE: patch for optional inhibit of delete-other-windows(IDE feature)

joakim <at> verona.se wrote:
> <klaus.berndl <at> sdm.de> writes:
> 
>> Hi,
>> 
>> first of all thanks!
>> 
>> But some remarks:
>> 
>> I'm sure Emacs should offer out-of-the-box internal concepts to
>> allow IDEs like ECB setting up a window-management-engine as needed
>> by a modern IDE - this includes stuff like preventing a window from
>> being deleted by delete-other-windows and something more which has
>> been already discussed...    
>> 
>> But: I'm not sure if doing this a c-level is the right way. Why?
>> IMHO ECB should be runable with Emacs as well with XEmacs. And if
>> all these window-enhancements would be done at c-level at Emacs then
>> the incompatibilities between Emacs and XEmacs would become more and
>> more...    
>> 
>> Of course Emacs and XEmacs are already quite incompatible but IMHO
>> such important basic stuff like preventing windows from some
>> operations should be a concept both flavors should support
>> identically - at least concerning the programming interface a tool
>> like ECB would see and use...    
>> 
>> Your opinion?
> 
> This was discussed on emacs-devel, and the emacs maintainers prefered

(Continue reading)

headers

Henry S. Thompson | 29 Apr 2008 13:26

Re: patch for optional inhibit of delete-other-windows(IDE feature)


[retransmission to correct address glitch, originally
> To: <klaus.berndl <at> sdm.de>
> Cc: <joakim <at> verona.se>,  emacs-devel <at> gnu.org]

Klaus writes:

> 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...

I think this is exactly the right way to state the requirement.

> 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...

I think that would be very valuable.  I would be happy to review it.

ht
--

-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440

(Continue reading)

headers

martin rudalics | 28 Apr 2008 17:34

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 > 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?

 > 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?
What mechanism do you use to access a window outside the edit-area - do
you suspend advices?

 > 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,

(Continue reading)

headers

klaus.berndl | 28 Apr 2008 17:55

RE: patch for optional inhibit of delete-other-windows(IDE feature)

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

(Continue reading)

headers

martin rudalics | 29 Apr 2008 00:01

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 > To all questions: YES, except the recursively subdividing one: What do
 > you mean exactly?

My question was badly formulated.  I wanted to know whether the
edit-area could be always obtained by recursively splitting a window in
some arbitrary way such that the resulting tiling would encompass the
_entire_ edit-area.  That is, none of the windows produced by these
splittings would not be part of the edit-area.

A simple example not following this concept would be: Split a window
vertically, split the lower window vertically, the upper two windows
(and their sub-windows) would constitute the edit-area, the lowest
window would not be part of the edit-area.

I'm asking because currently reasoning about tiling Emacs windows is
purely operational.  A tiling is always the result of recursively
splitting an initial window into sub-windows.

 > Currently the concept of ECB is:
 > - Exactly one frame

Does that mean I can't run ECB in two frames simultaneously?

 > - The is *always* exact ONE edit-area, which is always a rectangle

I suppose this will be the basic invariant.

 > - The special windows are located either at the left, at the right or
 > on top of the edit area

(Continue reading)

headers

Richard M Stallman | 29 Apr 2008 18:35

Re: patch for optional inhibit of delete-other-windows(IDE feature)

I suggest that the best way to design these features is
to think about the actual uses (such as an IDE) and design
features adequate for those uses.  In other words, avoid
ading more generality than we need.

headers

martin rudalics | 29 Apr 2008 23:27

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 > I suggest that the best way to design these features is
 > to think about the actual uses (such as an IDE) and design
 > features adequate for those uses.  In other words, avoid
 > ading more generality than we need.

At the very moment we have to wait for IDE designers and users to tell
us their needs and experiences.  Next we can evaluate (i) what would be
the core requirements for such systems, and (ii) whether there are any
fringe benefits - for example, the idea to pop up a help or compile
window always at the same position, say at the bottom of a frame,
appears intriguing (to me).

headers

Stefan Monnier | 30 Apr 2008 05:26

Re: patch for optional inhibit of delete-other-windows(IDE feature)

> fringe benefits - for example, the idea to pop up a help or compile
> window always at the same position, say at the bottom of a frame,
> appears intriguing (to me).

I've been using that for years, in the form of dedicated frames,

        Stefan

headers

Eric M. Ludlam | 29 Apr 2008 20:04

Re[2]: patch for optional inhibit of delete-other-windows(IDE feature)

>>> Richard M Stallman <rms <at> gnu.org> seems to think that:
>I suggest that the best way to design these features is
>to think about the actual uses (such as an IDE) and design
>features adequate for those uses.  In other words, avoid
>ading more generality than we need.

I agree.  Fiddling Emacs to match a model ECB currently uses will just
make ECB work.  What if there is an ECB and a second program like
Speedbar, that both want to do the same thing.  How do they work
together?

I know speedbar works inside ECB because ECB has special code for it,
but what if it did not?

I'd like to know how ECB, and Speedbar can work at the same time,
without being aware of eachother.  Would the solution really be that
Speedbar needs some ECB client code?

The various MDIs (multi-document interface) programs like Eclipse that
I'm familiar with treat the document area, and the data display
windows as completely different entities.  Eclipse has all these
independent plugins that provide little speedbar like displays that
all get stacked and manipulated by the user in a pretty simple way
that is independent of the document area.

This isn't a dis against ECB, I think it's a great tool, but
architecturally it's a one-way street that starts and ends with ECB.
That could be a positive step in itself, where ECB is the API used for
attaching many different tools around the sides of a set of edit
windows.  If this is a case, we should be explicit about it.

(Continue reading)

headers

martin rudalics | 29 Apr 2008 23:27

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 > The various MDIs (multi-document interface) programs like Eclipse that
 > I'm familiar with treat the document area, and the data display
 > windows as completely different entities.  Eclipse has all these
 > independent plugins that provide little speedbar like displays that
 > all get stacked and manipulated by the user in a pretty simple way
 > that is independent of the document area.

Earlier I wrote my own sidebar because I was not able to use two
speedbars simultaneously - say one for file browsing and the other for
displaying tags.  Has this become possible in the meantime?

headers

Eric M. Ludlam | 30 Apr 2008 01:08

Re: patch for optional inhibit of delete-other-windows(IDE feature)

>>> martin rudalics <rudalics <at> gmx.at> seems to think that:
> > The various MDIs (multi-document interface) programs like Eclipse that
> > I'm familiar with treat the document area, and the data display
> > windows as completely different entities.  Eclipse has all these
> > independent plugins that provide little speedbar like displays that
> > all get stacked and manipulated by the user in a pretty simple way
> > that is independent of the document area.
>
>Earlier I wrote my own sidebar because I was not able to use two
>speedbars simultaneously - say one for file browsing and the other for
>displaying tags.  Has this become possible in the meantime?

Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
gets separated and you can then make a new one.

Sadly, as I just tried this, the new speedbar frame seems to have the
same buffer as the original.  I wonder when that happened.

Eric

--

-- 
          Eric Ludlam:                       eric <at> siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

(Continue reading)

headers

martin rudalics | 30 Apr 2008 07:37

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 > Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
 > gets separated and you can then make a new one.

Do you mean the speedbar shipped with Emacs?  It does not have a menu
and it always appears in a separate frame.

Or do you mean the one bundled with ECB?

headers

Eric M. Ludlam | 30 Apr 2008 13:55

Re[2]: patch for optional inhibit of delete-other-windows(IDE feature)

>>> martin rudalics <rudalics <at> gmx.at> seems to think that:
> > Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
> > gets separated and you can then make a new one.
>
>Do you mean the speedbar shipped with Emacs?  It does not have a menu
>and it always appears in a separate frame.
>
>Or do you mean the one bundled with ECB?

Sorry, if you right click, you get a context menu.  That's the
speedbar menu, with many and various options.

Clicking in the mode-line will also do it.

Eric

--

-- 
          Eric Ludlam:                       eric <at> siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net

headers

martin rudalics | 30 Apr 2008 15:43

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 >>>Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
 >>>gets separated and you can then make a new one.
[....]
 > Sorry, if you right click, you get a context menu.  That's the
 > speedbar menu, with many and various options.
 >
 > Clicking in the mode-line will also do it.

There's no "detach" in that menu with speedbar version 1.0 and the
doc-string of `speedbar-frame-mode' says

"Currently, only one speedbar is supported at a time."

Are we missing some interesting developments here?

headers

Eric M. Ludlam | 30 Apr 2008 17:29

Re: patch for optional inhibit of delete-other-windows(IDE feature)

>>> martin rudalics <rudalics <at> gmx.at> seems to think that:
> >>>Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
> >>>gets separated and you can then make a new one.
>[....]
> > Sorry, if you right click, you get a context menu.  That's the
> > speedbar menu, with many and various options.
> >
> > Clicking in the mode-line will also do it.
>
>There's no "detach" in that menu with speedbar version 1.0 and the
>doc-string of `speedbar-frame-mode' says
>
>"Currently, only one speedbar is supported at a time."
>
>Are we missing some interesting developments here?

Huh, you are right.  That's been in my version since 2000:

|---
| revision 1.170
| date: 2000/06/11 18:44:00;  author: zappo;  state: Exp;  lines: +26 -2
| Added `speedbar-detatch' so we can have multiple speedbars.
| Fixed `speedbar-trim-words-tag-hierarchy' to work w/ semantic.
|---

and when I look in the Emacs/CVS version, it is not there, but
comments about it are.

In ChangeLog.12 I found this:

(Continue reading)

headers

Robert J. Chassell | 30 Apr 2008 17:38

Re: patch for optional inhibit of delete-other-windows(IDE feature)

    > > Yes.  Go into the speedbar menu, and choose "detach". ...

    Sorry, if you right click, you get a context menu.  That's the
    speedbar menu ...

In today's GNU Emacs CVS snapshot, Wed, 2008 Apr 30 09:45 UTC
GNU Emacs 23.0.60.29 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
started with

     emacs -Q -D

     speedbar-version "1.0"

there is no `detach' on the speedbar menu.

--

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob <at> rattlesnake.com                         bob <at> gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

headers

klaus.berndl | 29 Apr 2008 20:27

RE: Re[2]: patch for optional inhibit of delete-other-windows(IDE feature)

Eric M. Ludlam wrote:
>>>> Richard M Stallman <rms <at> gnu.org> seems to think that:
>> I suggest that the best way to design these features is
>> to think about the actual uses (such as an IDE) and design
>> features adequate for those uses.  In other words, avoid
>> ading more generality than we need.
> 
> 
> I agree.  Fiddling Emacs to match a model ECB currently uses will just
> make ECB work.  What if there is an ECB and a second program like
> Speedbar, that both want to do the same thing.  How do they work
> together?
> 
> I know speedbar works inside ECB because ECB has special code for it,
> but what if it did not?
> 
> I'd like to know how ECB, and Speedbar can work at the same time,
> without being aware of eachother.  Would the solution really be that
> Speedbar needs some ECB client code?
> 
> The various MDIs (multi-document interface) programs like Eclipse that
> I'm familiar with treat the document area, and the data display
> windows as completely different entities.  Eclipse has all these
> independent plugins that provide little speedbar like displays that
> all get stacked and manipulated by the user in a pretty simple way
> that is independent of the document area.
> 
> This isn't a dis against ECB, I think it's a great tool, but
> architecturally it's a one-way street that starts and ends with ECB.
> That could be a positive step in itself, where ECB is the API used for

(Continue reading)

headers

Stefan Monnier | 29 Apr 2008 22:35

Re: patch for optional inhibit of delete-other-windows(IDE feature)

> Also very helpful could be to save not only the window-configuration of the
> whole frame but also to save and restore the current subwindow-configuration
> of a certain window

Yes, we want this feature but I don't think we have it yet.  IIUC it
shouldn't be too difficult to add it to the Elisp implementation of
window configurations (which also provide the ability to save a config
on a frame and restore it on another frame, or in another Emacs session
altogether),

That reminds me: is there any progress on this front?

        Stefan

headers

martin rudalics | 29 Apr 2008 23:28

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 >>Also very helpful could be to save not only the window-configuration of the
 >>whole frame but also to save and restore the current subwindow-configuration
 >>of a certain window
 >
 > Yes, we want this feature but I don't think we have it yet.  IIUC it
 > shouldn't be too difficult to add it to the Elisp implementation of

Elisp, really?  That is, using `split-window'z?  IIUC that's precisely
what Klaus has implemented for ECB.

 > window configurations (which also provide the ability to save a config
 > on a frame and restore it on another frame, or in another Emacs session
 > altogether),
 >
 > That reminds me: is there any progress on this front?

There was never any consensus on any format.

headers

Eric M. Ludlam | 29 Apr 2008 21:04

Re: patch for optional inhibit of delete-other-windows(IDE feature)

>>> <klaus.berndl <at> sdm.de> seems to think that:
>Eric M. Ludlam wrote:
>>>>> Richard M Stallman <rms <at> gnu.org> seems to think that:
>>> I suggest that the best way to design these features is
>>> to think about the actual uses (such as an IDE) and design
>>> features adequate for those uses.  In other words, avoid
>>> ading more generality than we need.
>> 
>> 
>> I agree.  Fiddling Emacs to match a model ECB currently uses will just
>> make ECB work.  What if there is an ECB and a second program like
>> Speedbar, that both want to do the same thing.  How do they work
>> together?
>> 
>> I know speedbar works inside ECB because ECB has special code for it,
>> but what if it did not?
>> 
>> I'd like to know how ECB, and Speedbar can work at the same time,
>> without being aware of eachother.  Would the solution really be that
>> Speedbar needs some ECB client code?
>> 
>> The various MDIs (multi-document interface) programs like Eclipse that
>> I'm familiar with treat the document area, and the data display
>> windows as completely different entities.  Eclipse has all these
>> independent plugins that provide little speedbar like displays that
>> all get stacked and manipulated by the user in a pretty simple way
>> that is independent of the document area.
>> 
>> This isn't a dis against ECB, I think it's a great tool, but
>> architecturally it's a one-way street that starts and ends with ECB.

(Continue reading)

headers

klaus.berndl | 29 Apr 2008 10:46

RE: patch for optional inhibit of delete-other-windows(IDE feature)

martin rudalics wrote:
>  > To all questions: YES, except the recursively subdividing one:
>  What do > you mean exactly?
> 
> My question was badly formulated.  I wanted to know whether the
> edit-area could be always obtained by recursively splitting a window
> in some arbitrary way such that the resulting tiling would encompass
> the _entire_ edit-area.  That is, none of the windows produced by
> these splittings would not be part of the edit-area.
> 
> A simple example not following this concept would be: Split a window
> vertically, split the lower window vertically, the upper two windows
> (and their sub-windows) would constitute the edit-area, the lowest
> window would not be part of the edit-area.
> 
> I'm asking because currently reasoning about tiling Emacs windows is
> purely operational.  A tiling is always the result of recursively
> splitting an initial window into sub-windows.

Ok, now i understand, thanks. well, the answer is YES, means, each window
produced by splitting a window already contained in the edit-area (at
beginning the edit-area consists of exactly one window, obviously 
will be part of the edit-area too.

> 
>  > Currently the concept of ECB is:
>  > - Exactly one frame
> 
> Does that mean I can't run ECB in two frames simultaneously?

(Continue reading)

headers

martin rudalics | 29 Apr 2008 15:30

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 > The compile-window is used to display all stuff like help-buffers, compile-
 > grep-buffer etc...

Do you mean that C-h ... are not allowed to display the help buffer in
the edit-area?  How do you achieve that?

 > is customizable by mode and regexp which buffers should
 > be automatically alwasy being displayed in the compile-buffer - example:
 > When you do switch-to-buffer in one of the edit-windows and you insert a
 > buffer which is customized to be displayed in the compile-window then
 > ECB will switch to this buffer in the compile-window (if it is displayed
 > in the current layout) - in generell the advices of switch-to-buffer and
 > pop-to-buffer are one of the most important ones currently because
 > the do all the needed smartness to display the right buffer in the right
 > window...

Did you ever try to tackle these problems with `same-window-regexps' or
`same-window-buffer-names'?  Though I suppose they are too fuzzy for
your purposes.

 > Redraw the ECB screen according to the layout set in `ecb-layout-name'.

How do you get the structure needed for splitting windows into a layout
- do you use the `window-tree' function?

 > After
 > this function the edit-window is selected which was current before redrawing.
 > If no-buffer-sync is not nil then the ecb-buffers will not be synchronized. If
 > ecb-windows-creator is not nil then it will be used to draw the layout instead
 > of the standard layout. If window-configuration-data is not nil it must be an

(Continue reading)

headers

klaus.berndl | 29 Apr 2008 16:27

RE: patch for optional inhibit of delete-other-windows(IDE feature)

martin rudalics wrote:
>  > The compile-window is used to display all stuff like help-buffers,
>  compile- > grep-buffer etc...
> 
> Do you mean that C-h ... are not allowed to display the help buffer in
> the edit-area?  How do you achieve that?

By setting `temp-buffer-show-function' to the following ecb-function
which does this.
You see that it uses at the end the adviced `display-buffer' of ECB which
does the final trick, i.e. using the compile-window for all buffers
an ECB user has to customized being displayed in the compile window
(default is all help-buffers, the compile, grep and some others...)

-------
(defun ecb-temp-buffer-show-function-emacs (buf)
  ;; cause of running the hooks in `temp-buffer-show-hook' we must use
  ;; save-selected-window (s.b.). But maybe `display-buffer' calls
  ;; `ecb-toggle-compile-window' which completely destroy all windows and
  ;; redraw the layout. This conflicts with the save-selected-window.
  ;; Therefore we toggle the compile-window before the save-selected-window!
  (when (ecb-compilation-buffer-p buf)
    (ecb-layout-debug-error "ecb-temp-buffer-show-function-emacs: comp-buffer: %s"
                            buf)
    (when (and (equal (selected-frame) ecb-frame)
               (equal 'hidden (ecb-compile-window-state))
               ;; calling this from minibuffer (e.g. completions)
               ;; seems to cause problems
               (not (equal (minibuffer-window ecb-frame) (selected-window))))
      (ecb-layout-debug-error "ecb-temp-buffer-show-function-emacs: comp-win will toggled")

(Continue reading)

headers

martin rudalics | 29 Apr 2008 17:47

Re: patch for optional inhibit of delete-other-windows(IDE feature)

 > By setting `temp-buffer-show-function' to the following ecb-function
 > which does this.

I see.  Maybe we could introduce an option which makes temporary buffers
always appear in a window on the bottom of the frame, technically spoken
in a subwindow of the root-window of that frame.  If Emacs can handle
resizing the remaining windows well this wouldn't be very hard.  What
happens when you want to display a compile- and a help-window (or Info
window) appear all at the same time?

 > To make a long story short: It would be very very great if there is
 > a commitment that *each* command or function which has to display
 > a buffer in a window uses internaly `display-buffer', because then
 > it would probably sufficient for ECB to patch this machanism (either
 > by adding a full featured display-buffer-function or by advicing
 > display-buffer itself).
 >
 > What is the current state with this respect?

`switch-to-buffer' surely won't.

 > ecb-redraw-layout-full performs all the layouting. For this it does
 > all the window-structure-independ stuff out-of-the-box and then it
 > calls a special layout-function `ecb-layout-function-≤layoutname>'
 > which performs all the splits necessary for a certain layout...

We can't do this in window.c.  We would have to be able to get the
current layout independently from how it was obtained in the first
place.

(Continue reading)

headers

klaus.berndl | 28 Apr 2008 17:58

RE: patch for optional inhibit of delete-other-windows(IDE feature)

klaus.berndl <at> sdm.de wrote:
> 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

sorry, misunderstandable: Must be: Exactly one frame *for ECB*
(of course there can be opened other coexistent frames used for
'not-ECB-editing' - all ECB-operations always affect the ECB-frame,
no other frame, all adviced are 100% save concerning this)

> - 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

(Continue reading)

headers

Henry S. Thompson | 29 Apr 2008 12:59

Re: [ECB-list] patch for optional inhibit of


Klaus writes:

> 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...

I think this is exactly the right way to state the requirement.

> 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...

I think that would be very valuable.  I would be happy to review it.

ht
--

-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht <at> inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

(Continue reading)