all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: ECB
Date: Wed, 14 Jul 2004 14:26:08 -0400	[thread overview]
Message-ID: <E1BkoSG-0003pC-CR@fencepost.gnu.org> (raw)
In-Reply-To: <1B3ACCFD5694A94DBA4E231402B0E9ED040976@mucmail1.sdm.de> (klaus.berndl@sdm.de)

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

  reply	other threads:[~2004-07-14 18:26 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-13 12:42 ECB Berndl, Klaus
2004-07-14 18:26 ` Richard Stallman [this message]
2004-07-14 18:27 ` ECB Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
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
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-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
2003-01-23 14:06 ECB Dr. F.C.Caner
2003-01-23 15:36 ` ECB Klaus Berndl

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1BkoSG-0003pC-CR@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.