From: <klaus.berndl@sdm.de>
To: <eric@siege-engine.com>, <rms@gnu.org>
Cc: rudalics@gmx.at, emacs-devel@gnu.org, joakim@verona.se,
ecb-list@lists.sourceforge.net
Subject: RE: Re[2]: patch for optional inhibit of delete-other-windows(IDE feature)
Date: Tue, 29 Apr 2008 20:27:59 +0200 [thread overview]
Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E347AC6A@mucmail3.sdm.de> (raw)
In-Reply-To: <200804291804.m3TI4fSp017469@projectile.siege-engine.com>
Eric M. Ludlam wrote:
>>>> Richard M Stallman <rms@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.
I completely agree. Emacs should not be enhanced to support especially
ECB but it should be enhanced in that way so a tool *like* ECB (not
exactly ECB) could be implemented without that heavy advice-stuff
currently needed by ECB.
and IMHO the discussion between Martin and me goes in this direction
(at least this is my intention ;-): I do not want all special stuff
of ECB into the c-core of Emacs but Emacs should offer a well defined
interface to allow tools like ECB introducing a smart window-layout-
engine as needed by IDE-functionality
For this some window-pining and -grouping is needed as suggested by
Joakim (this is nothing special for ECB but can be very useful for
other tools too - maybe speedbar)
Then a mechanism is needed to display certain buffers in certain windows.
For this porting display-buffer to elisp is a great step forward.
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 - i do not know if window-tree already supports that
somehow?!
Eric, do we agree with that?
Klaus
>
> Eric
next prev parent reply other threads:[~2008-04-29 18:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m37iela60f.fsf@verona.se>
[not found] ` <84D8FEFE8D23E94E9C2A6F0C58EE07E3429A02@mucmail3.sdm.de>
2008-04-28 11:14 ` patch for optional inhibit of delete-other-windows(IDE feature) joakim
2008-04-28 11:50 ` klaus.berndl
2008-04-28 15:34 ` martin rudalics
2008-04-28 15:55 ` klaus.berndl
2008-04-28 15:58 ` klaus.berndl
2008-04-28 22:01 ` martin rudalics
2008-04-29 8:46 ` klaus.berndl
2008-04-29 13:30 ` martin rudalics
2008-04-29 14:27 ` klaus.berndl
2008-04-29 15:47 ` martin rudalics
2008-04-29 16:35 ` Richard M Stallman
2008-04-29 18:04 ` Re[2]: " Eric M. Ludlam
2008-04-29 18:27 ` klaus.berndl [this message]
2008-04-29 19:04 ` Eric M. Ludlam
2008-04-29 20:35 ` Stefan Monnier
2008-04-29 21:28 ` martin rudalics
2008-04-29 21:27 ` martin rudalics
2008-04-29 23:08 ` Eric M. Ludlam
2008-04-30 5:37 ` martin rudalics
2008-04-30 11:55 ` Re[2]: " Eric M. Ludlam
2008-04-30 13:43 ` martin rudalics
2008-04-30 15:29 ` Eric M. Ludlam
2008-04-30 15:38 ` Robert J. Chassell
2008-04-29 21:27 ` martin rudalics
2008-04-30 3:26 ` Stefan Monnier
2008-04-29 10:59 ` [ECB-list] patch for optional inhibit of Henry S. Thompson
2008-04-28 19:45 ` patch for optional inhibit of delete-other-windows(IDE feature) Richard M Stallman
2008-04-25 22:35 joakim
2008-04-26 1:25 ` Stefan Monnier
2008-04-26 6:56 ` joakim
2008-04-28 1:20 ` Stefan Monnier
2008-04-28 11:26 ` joakim
2008-04-28 11:41 ` Miles Bader
2008-04-28 18:26 ` Re[2]: " Eric M. Ludlam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84D8FEFE8D23E94E9C2A6F0C58EE07E347AC6A@mucmail3.sdm.de \
--to=klaus.berndl@sdm.de \
--cc=ecb-list@lists.sourceforge.net \
--cc=emacs-devel@gnu.org \
--cc=eric@siege-engine.com \
--cc=joakim@verona.se \
--cc=rms@gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).