unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* RE: ECB
@ 2006-03-08  9:50 klaus.berndl
  2006-03-08 14:54 ` ECB Stefan Monnier
  0 siblings, 1 reply; 42+ messages in thread
From: klaus.berndl @ 2006-03-08  9:50 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman wrote:
>     Now i think we would need a more general mechanism which would
>     also prevent such windows from being included in the tree
>     returned by `window-tree' so all features based on new
>     `window-tree' (AFAIK currently only `balance-window') can ignore
> this window from their doing.... 
> 
> Would you like to implement these features, for future installation?

If on c-level then i doubt that i have enough know-how of the c-code of Emacs
to implement a good solution... IMVHO the best would be to check in `display-buffer'
(and also in routines like `window-tree'?!) If a window should be excluded from some
actions... And IMVHO display-buffer should be moved from c-kernel to elisp-code
(as already done by XEmacs ;-)

If we can implement the new feature on elisp-level i would be willing to imlement
it - at least i would try it ;-)

Ciao,
klaus

^ permalink raw reply	[flat|nested] 42+ messages in thread
* RE: ECB
@ 2006-03-08  9:45 klaus.berndl
  2006-03-09 17:13 ` ECB Richard Stallman
  0 siblings, 1 reply; 42+ messages in thread
From: klaus.berndl @ 2006-03-08  9:45 UTC (permalink / raw)
  Cc: monnier, emacs-devel

Richard Stallman wrote:
>     Ah, very interesting - supposed balance-windos obeys
>     window-sized-fixed then ECB could advice `balance-window' and
>     setting window-sized-fix to t temporally for the buffers
>     displayed by the special ECB-windows (which should be ignored for
> balancing)... 
> 
> It should not use advice!
> 
> Why not set window-size-fixed permanently in these buffers?

IMHO this should be the users choice if he/she wants to side-panel
(or top-panal for layouts of type top) of the ECB-windows being fixed
when resizing the ECB-frame.

In general i agree with you concerning using advices, but IMO currently
they are still necessary if one wants to build something like ECB on top
of Emacs and give the users the feeling if the edit-windows of ECB are 
the only windows in the frame and allow all features users are used to 
use (e.g. deciding if they want windows fixed or not...)

Until we have a robust and general mechanism to exclude special windows
from being taken into account by fnctions like deleting, balancing windows
etc.... (as i described in my previous posting) ECB will use advices as
best possible workaround. The advices of ECB are always safe because they
are savely only active when ECB is active...

^ permalink raw reply	[flat|nested] 42+ messages in thread
* RE: ECB
@ 2006-03-07 17:01 klaus.berndl
  2006-03-08  4:22 ` ECB Richard Stallman
  0 siblings, 1 reply; 42+ messages in thread
From: klaus.berndl @ 2006-03-07 17:01 UTC (permalink / raw)
  Cc: rms, emacs-devel

Stefan Monnier wrote:
>> But for now: Are there some work-arounds possible how to exclude some
>> windows from being "balanced" (means ajusted) by the new
>> balance-window? In the old one an advice for `walk-windows' was
>> enough which simply does not walk through these special windows...
>> But now, `walk-windows' is not used but `window-tree'...
> 
> balance-windows should obey `window-size-fixed'.  I don't know
> whether it does, and neither do I know whether ECB can use it. 

Ah, very interesting - supposed balance-windos obeys window-sized-fixed
then ECB could advice `balance-window' and setting window-sized-fix to t temporally
for the buffers displayed by the special ECB-windows (which should be ignored for
balancing)...

Is not a generall solution for such problems (i mentioned in my posting) but sounds
like a promising workaround for making newest balance-windows compatible with ECB...

Thanks!

Ciao,
Klaus

> 
> 
>         Stefan

^ permalink raw reply	[flat|nested] 42+ messages in thread
* RE: ECB
@ 2006-03-07 13:48 klaus.berndl
  2006-03-07 16:48 ` ECB Stefan Monnier
  2006-03-08  4:21 ` ECB Richard Stallman
  0 siblings, 2 replies; 42+ messages in thread
From: klaus.berndl @ 2006-03-07 13:48 UTC (permalink / raw)
  Cc: emacs-devel

Hello,

Sorry for reactivating such an old thread but the latest cvs-Emacs pops this
up for me:

I saw, that balance-window has been completely reimplemented on base of
a new c-level-function `window-tree'...fine, but:

Tools like ECB makes a lot of handstands to exclude some windows (the
special ECB-windows which display stuff like dirs, files and file-
contents from being deleted by command like delete-other-windows etc...
Or in general: To exclude these special ECB-windos from being taken into
account in general (e.g. also by count-windows, walk-windows in special
situations).

This is done by advices which are save and only active when ECB is active...

Richard, do you remember this thread - see below?
We had discussed how to prevent some special windows from being deleted?
Now i think we would need a more general mechanism which would also prevent
such windows from being included in the tree returned by `window-tree' so
all features based on new `window-tree' (AFAIK currently only `balance-window')
can ignore this window from their doing....

I think this is not necessary for the current Emacs-release but a least then, when
ECB should be integrated into Emacs (at least if this is intended ;-)

But for now: Are there some work-arounds possible how to exclude some windows
from being "balanced" (means ajusted) by the new balance-window?
In the old one an advice for `walk-windows' was enough which simply does not
walk through these special windows... But now, `walk-windows' is not used but
`window-tree'...

Any suggestions?

Thanks a lot in advance!

Ciao,
klaus

Richard Stallman wrote:
>     >Do you think that this feature should be integrated into Emacs
>     at the >C level?
> 
>     Hmm, depends. IMO Emacs is not really designed for having a
>     window-layout where some windows should be permanent and should
>     always contain some certain stuff (like the special
>     ECB-browsing-tree-buffers/windows) and the rest of the windows
>     which can be deleted and created by the user (like the
>     editing-area of ECB).
> 
> Not now; that's why I'm suggesting to change it.
> 
>     BTW: If you remember we had already a short discussion about the
>     adding a mechanism (flag) to the c-level so a window can be marked
>     to be excluded from delete-other-window... please apologize but i
>     haven't still found enough time to implement this.
> 
> I remembered having that discussion, but not who I had discussed it
> with.  It sounds like ECB has implemented the same feature (more or 
> less) at Lisp level.  Do you agree that C level would be the best
> place to put it? 
> 
> 
>     Example: ECB advices the `display-buffer' so it displays all
>     "compilation"-buffers (buffers which fulfill criterias a user has
>     defined so they should be displayed in the
>     compilation-output-window of ECB) in the
>     compilation-output-window of ECB (an optional but then permanent
>     window at the bottom of the ecb-frame), all special ecb-buffers
>     in the assigned ecb-window and for the rest of the buffers it
>     uses the edit-area of the ecb-frame as if this area would be the
>     whole frame. Works save and like a charm but needs for this a big
>     and - i admit - complex advice. So IMHO it would make sense for
>     some mechanisms (needed by ECB) to be included in the Emacs-core
>     because IMHO it is always better - regardless of the code-quality
>     and the saveness of an advive of an internal central function
>     like display-buffer - to implement this in the emacs-core instead
> with an advice. 
> 
> That's exactly what I think.  In fact, we want to avoid defining any
> advice in Emacs itself. 
> 
> 			The question is if it should be at the c-level
> 			or at the lisp-level?
> 
> It should be implemented within display-buffer, which means, in C
> level. 
> 
> To rewrite display-buffer in Lisp is a separate idea.  I'm not
> against it, if someone wants to do it.  Not right now; now our focus
> is on getting a release to work.  But if you want to do that, it
> would be ok, and we could install that just before installing ECB.   

^ permalink raw reply	[flat|nested] 42+ messages in thread
* RE: ECB
@ 2004-07-13 12:42 Berndl, Klaus
  2004-07-14 18:26 ` ECB Richard Stallman
  2004-07-14 18:27 ` ECB Richard Stallman
  0 siblings, 2 replies; 42+ messages in thread
From: Berndl, Klaus @ 2004-07-13 12:42 UTC (permalink / raw)
  Cc: 'emacs-devel@gnu.org '

>I agree it would be good to offer the user both interfaces.
>One way to do that is by having both ECB and Speedbar in Emacs.
>But that is not the clean way to do it.

>Could you implement speedbar-like behavior as an option in ECB?  If
>that is easy to do, it would be a big simplification.  We would not
>have to maintain both (all of) Speedbar and ECB.  The parts of
>Speedbar that ECB needs, we could integrate into ECB.

First of all we would have to specify what it is that "speedbar-like"-behavior. Is it:
1. The combination of directory- and file-content-browsing within one 
   window (ECB separates the directory- and file-browser and the 
   contents-browser in different windows whereas speedbar displays all 
   stuff in one big tree
2. Displaying all stuff in an extra frame
3. Offering all the special-modes of speedbar, e.g. "buffers"-mode, 
   "info"-mode etc...
4. Supporting all packages which currently use the speedbar-API to display
   special views for certain code-types (e.g. vhdl-mode.el)

Point 1 would be hard to implement but IMHO i would always prefer different windows for different content so i would plead for not porting this speedbar behavior to ECB. But maybe this is a matter of taste (a pro argument for offering speedbar also in the future?!)

Point 2 could probably be implemented in ECB but would need some significant work.

Point 3 is probably quite easy to introduce into ECB

Point 4 would be possible too. But this would need some additional work for the ECB-API (but this is not hard and also not many effort) and - which is a lot of more effort - this would mean that every package which currently uses the speedbar-API for special displays has to be ported to the ECB-API to display its own stuff - see the speedbar-homepage for a list of elisp-packages which currently use the speedbar-API for that. IMHO another pro argument for supporting both speedbar and ECB in the future.

>>    ECB has currently a quite powerful layout-engine which allows an
>>    user to create its own window-layout interactively and on the other 
>>    hand offers a programming-API to program/create completely new 
>>    special windows (to display whatever you want) and synchronize it 
>>    with the editing-area of ECB.

>That sounds quite interesting.

>Do you think that this feature should be integrated into Emacs at the
>C level?

Hmm, depends. IMO Emacs is not really designed for having a window-layout where some windows should be permanent and should always contain some certain stuff (like the special ECB-browsing-tree-buffers/windows) and the rest of the windows which can be deleted and created by the user (like the editing-area of ECB). For example one problem is, that currently Emacs has the dedicated-window concept but has no mechanism to prevent that commands like delete-other-window exclude some windows from this deletion. So ECB makes really some hard handstands ;-) to achieve this goal. This results in sophisticated advices of functions like split-window, delete-window. delete-other-windows, display-buffer (one of the most important adviced, because ECB needs full controll where to display certain buffers!)

BTW: If you remember we had already a short discussion about the adding a mechanism (flag) to the c-level so a window can be marked to be excluded from delete-other-window... please apologize but i haven't still found enough time to implement this.

All the advices of ECB are completely save, ie. behave only special in the ecb-frame (in all other frames they behave like the original), are only activated if ECB is activated (==> all advices will be first activated when ECB is activated and will be deactivated when ECB will be deactivated!) and so on: Example: ECB advices the `display-buffer' so it displays all "compilation"-buffers (buffers which fulfill criterias a user has defined so they should be displayed in the compilation-output-window of ECB) in the compilation-output-window of ECB (an optional but then permanent window at the bottom of the ecb-frame), all special ecb-buffers in the assigned ecb-window and for the rest of the buffers it uses the edit-area of the ecb-frame as if this area would be the whole frame. Works save and like a charm but needs for this a big and - i admit - complex advice. So IMHO it would make sense f
 or some mechanisms (needed by ECB) to be included in the Emacs-core because IMHO it is always better - regardless of the code-quality and the saveness of an advive of an internal central function like display-buffer - to implement this in the emacs-core instead with an advice. The question is if it should be at the c-level or at the lisp-level?  For example the XEmacs-crew has implemented the full display-buffer function in emacs-lisp which has IMHO some advantages over the c-level version of GNU Emacs...

Summary: ECB needs some special and new window-mechanism (mainly in the context, how to exclude certain windows to be deleted by delete-other-window, how to prevent certain windows from being splitted and how to ensure that a certain buffer will be always displayed in a certain window of a frame (but not in the meaning of the same window-object but more in the meaning of the same logical window of a frame, because switching to another window-layout of ECB (ECB offers a lot of prebuzild layouts and the user can create own layouts) would destroy all existing window-objects and create completely new window-objects buf the buffers should still being displayed in the same logical windows - sorry, but i can not describe it better at the moment)

See the ECB-info-manual to get a list which functions are adviced by ECB!

>Is it accurate to describe CEDET as a packaging of eieio, semantic,
>and speedbar?  If not, could you clear up my misunderstanding?
>Does CEDET contain other things aside from eieio, semantic, and
>speedbar?

generally speaking you understand it right. It contains in addition some utility sublibs like a progress-bar, a mode-local lib etc... but i think Eric has already answered this in more detail in another posting?!

>If we want to put eieio and semantic into Emacs, I think we would be
>better off without having them packaged in the form of CEDET.  Emacs
>has its own system of makefiles, and to get clean results, we would
>want to handle eieio and semantic like all the rest of the Lisp code
>in Emacs.

Of course but for this i think we should integrate Eric Ludlum because he can give the best answeres to this problems.

>Can you tell me how many lines of code are in ECB, in eieio, and in
>semantic?

Can only speak for ECB (for the cedet-libs ERic can give the answers)

All lines in the *.el-files of ECB (wc -l *.el): ~ 26000
All lines without empty lines: ~ 23000
All lines without empty lines and without pure comment-lines: ~ 20000

/Klaus

^ permalink raw reply	[flat|nested] 42+ messages in thread
* RE: ECB
@ 2004-07-07 16:57 Berndl, Klaus
  2004-07-07 20:50 ` ECB Jérôme Marant
  0 siblings, 1 reply; 42+ messages in thread
From: Berndl, Klaus @ 2004-07-07 16:57 UTC (permalink / raw)
  Cc: 'emacs-devel@gnu.org'

Berndl, Klaus wrote:
>>> The biggest difference between ECB and speedbar is that speedbar
>>> always appears in a seperate frame (it can be forced into another
>>> frame, but it is not easy), whereas ECB has several layout options,
>>> AFAIK all of which use windows within the current frame. Many people
>>> are used to working in other programs within the same frame, so they
>>> may see this as an improvement over speedbar.
> 
>> IIRC, ECB uses tree-widget, which has recently been added to the
>> Emacs trunk. I think this is what you compare with speedbar.
> 
> No, ECB doesn't use the tree-widget lib it uses its own tree-library!
> 
> Klaus
> 
> Klaus Berndl                     mailto: klaus.berndl@sdm.de
> sd&m AG                         http://www.sdm.de
> software design & management
> Carl-Wery-Str. 42, 81739 Muenchen, Germany
> Tel +49 89 63812-392, Fax -220

^ permalink raw reply	[flat|nested] 42+ messages in thread
* RE: ECB
@ 2004-07-07 16:54 Berndl, Klaus
  2004-07-08 23:18 ` ECB Richard Stallman
  2004-07-11 23:24 ` ECB Richard Stallman
  0 siblings, 2 replies; 42+ messages in thread
From: Berndl, Klaus @ 2004-07-07 16:54 UTC (permalink / raw)


Sorry for my late interaction but i have just subscribed to this list...
But as the maintainer of ECB and currently the main-developer i think
i should write down some aspects and answers to the previous postings:

1. Coexistence of speedbar and ECB and current dependencies

Currently ECB uses some speedbar-code to display the contents of files
which are currently not supported by the semantic-package (either the
standalone semantic 1.4.X or the cedet-version of semantic which is shipped
with the CEDET-suite. For such files (perl, html and others for which no
semantic-parser currently exists) ECB merely uses the interface the
speedbar package offers over the etags- and imenu-parsing-engines -
so ECB has no need to deal with etags or imenu itself but can use
this speedbar-interface. But this code could probably quite easy fully
integrated into ECB itself so the dependency to speedbar could go away -
but needs some extra programming in ECB.

In general some people have already described the situation very well:
ECB is another interface to display the contents of directories and 
of the source-files itself. Concerning displaying file-contents IMHO ECB
is better and more powerful than speedbar, concering browsing directories
it is probably a matter of taste... In general the look&feel of ECB is more
like currently offered IDEs as Visual Studio etc... and therefore it might
be more intuitive to use for many people - especially for Emacs-Newbies -
also because it displays all its information windows (directories, files,
file-contents etc.) in one frame one can be faster switch between its
code-editing-aplication (Emacs) and other applications. On the other side
speedbar has some more mode beside directory- and file-browsing, so e.g.
a quity nifty buffer-browser and some more.
Maybe Eric Ludlum can give us more advantages of speedbar over ECB ;-)

But IMO it would make sense to offer both ECB and speedbar so a user can
deside for himself which interface he likes more...

2. Flexibility for integration of other elisp-applications

ECB has currently a quite powerful layout-engine which allows an user
to create its own window-layout interactively and on the other hand offers a
programming-API to program/create completely new special windows (to display
whatever you want) and synchronize it with the editing-area of ECB.

3. Which features are needed in ECB to subsume speedbar?

Most things speedbar can do ECB can already do too. I can not judge the demand
people have for the buffer-mode of speedbar or the info-mode. As said under 2.
ECB offers already a powerful API to create new special windows which can
display what you want and also a powerful tree-buffer library so all these
speedbar-modes could in general be reimplemented in ECB.

4. What to do for integrating ECB cleanly into Emacs

AFAICS this should be quite simple:

- Required packages: either CEDET or the standalone libs eieio, semantic and
  speedbar (the need of the latter one is discussed above)
- Internal structure of ECB: All lisp-files reside in one plain directory,
  the needed image-files for the icopn-displays of the tree-buffers reside
  currently in a deeply nested subdir ecb-images (this could be moved to etc
  of the Emacs dir-structure e.g.), ECB offers its help in info- and html-
  format ehich reside each in an own subdir info-help and html-help.
  I assume integrating ECB into Emacs would need a changed structure of ECB
  and for this some small code-changes would be necessary (so ECB can find its
  files) but all are quite simple.

Conclusion: If the Emacs-team wants to integrate ECB into Emacs i would be glad
to hear this and it goes withourt saying that i will help and support as well
as possible.

Klaus

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: ECB
@ 2004-07-07 16:47 Berndl, Klaus
  0 siblings, 0 replies; 42+ messages in thread
From: Berndl, Klaus @ 2004-07-07 16:47 UTC (permalink / raw)
  Cc: 'emacs-devel@gnu.org'

 
Richard Stallman <address@bogus.example.com> writes:
>> Assuming ECB is well written and that it can be integrated well with
>> Emacs, we have a choice between installing ECB along with Speedbar, or
>> improving ECB to do all the things that Speedbar does, and replacing
>> Speedbar.  Making ECB subsume Speedbar would produce a simpler editor
>> that is easier to maintain, so that's the option we should aim for.

>I thought (from other posts) that ECB essentially _contained_ speedbar,
>though probably an updated version -- so it seems like there would be
>little pain in moving to ECB from that perspective.

No, this isn't true. ECB can display speedbar in one of its special
buffers/windows but this is more like an additional feature for people
who like speedbar but do not like the extra-frame of speedbar.

Klaus

Klaus Berndl                     mailto: klaus.berndl@sdm.de
sd&m AG                         http://www.sdm.de
software design & management
Carl-Wery-Str. 42, 81739 Muenchen, Germany
Tel +49 89 63812-392, Fax -220

^ permalink raw reply	[flat|nested] 42+ messages in thread
[parent not found: <E1Bgmxo-0006Bh-0o@monty-python.gnu.org>]
* ECB
@ 2004-07-02 17:51 Richard Stallman
  2004-07-02 18:10 ` ECB Jason Rumney
  2004-07-03 15:22 ` ECB Kai Grossjohann
  0 siblings, 2 replies; 42+ messages in thread
From: Richard Stallman @ 2004-07-02 17:51 UTC (permalink / raw)


Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
and tell me what you think of it?

^ permalink raw reply	[flat|nested] 42+ messages in thread
end of thread, other threads:[~2006-03-11 22:05 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-08  9:50 ECB klaus.berndl
2006-03-08 14:54 ` ECB Stefan Monnier
2006-03-08 15:08   ` ECB Drew Adams
2006-03-09  4:44     ` ECB Miles Bader
2006-03-08 22:18   ` ECB Eli Zaretskii
2006-03-09 16:04     ` ECB Stefan Monnier
2006-03-09 19:59       ` ECB Eli Zaretskii
2006-03-11 22:05   ` ECB Juri Linkov
  -- strict thread matches above, loose matches on Subject: below --
2006-03-08  9:45 ECB klaus.berndl
2006-03-09 17:13 ` ECB Richard Stallman
2006-03-07 17:01 ECB klaus.berndl
2006-03-08  4:22 ` ECB Richard Stallman
2006-03-07 13:48 ECB klaus.berndl
2006-03-07 16:48 ` ECB Stefan Monnier
2006-03-08  4:21 ` ECB Richard Stallman
2004-07-13 12:42 ECB Berndl, Klaus
2004-07-14 18:26 ` ECB Richard Stallman
2004-07-14 18:27 ` ECB Richard Stallman
2004-07-07 16:57 ECB Berndl, Klaus
2004-07-07 20:50 ` ECB Jérôme Marant
2004-07-07 16:54 ECB Berndl, Klaus
2004-07-08 23:18 ` ECB Richard Stallman
2004-07-11 23:24 ` ECB Richard Stallman
2004-07-07 16:47 ECB Berndl, Klaus
     [not found] <E1Bgmxo-0006Bh-0o@monty-python.gnu.org>
2004-07-05 12:06 ` ECB Eric M. Ludlam
2004-07-05 12:53   ` ECB Stefan
     [not found]   ` <E1BhoWE-0004n3-7k@fencepost.gnu.org>
     [not found]     ` <200407061241.i66CfX1w016798@projectile.siege-engine.com>
2004-07-12 23:58       ` ECB Richard Stallman
2004-07-02 17:51 ECB Richard Stallman
2004-07-02 18:10 ` ECB Jason Rumney
2004-07-02 20:29   ` ECB Jérôme Marant
2004-07-03 18:21   ` ECB Richard Stallman
2004-07-03 21:56     ` ECB Jason Rumney
2004-07-05 14:23       ` ECB Richard Stallman
2004-07-06  1:29         ` ECB Miles Bader
2004-07-06  7:41           ` ECB Jason Rumney
2004-07-06 21:59             ` ECB Richard Stallman
2004-07-03 15:22 ` ECB Kai Grossjohann
2004-07-03 17:05   ` ECB Stefan
2004-07-04  2:13   ` ECB Richard Stallman
2004-07-04  9:38     ` ECB Kai Grossjohann
2004-07-04 10:24       ` ECB Jason Rumney
2004-07-04 12:01     ` ECB Jens Lautenbacher

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).