ECB

ECB

[Dr. F.C.Caner]

Hello everyone,

I wonder if ECB supports any fortran extensions (f77/90/95/2000)?

Cheers,

FCC

Re: ECB

[Klaus Berndl]

On 23 Jan 2003, F. C. Caner wrote:



>  Hello everyone,
>  
>  I wonder if ECB supports any fortran extensions (f77/90/95/2000)?

Currently not, because there is no fortran semantic-parser available and ECB
is based completely on the parsing-capabilities of semantic, means ECB
supports always exactly these languages supported by semantic.

Write a a semantic bnf-file for fortran and ECB will support fortran... ;-)

But i think in the near future there will be released the first beta release
of semantic 2.0 and AFAIK semantic 2.0 supports more languages than current
version 1.4 but i do not know if fortran is included?

Ciao,
Klaus

-- 
Klaus Berndl			mailto: klaus.berndl@sdm.de
sd&m AG				http://www.sdm.de
software design & management	
Thomas-Dehler-Str. 27, 81737 München, Germany
Tel +49 89 63812-392, Fax -220

ECB

[Richard Stallman]

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

Re: ECB

[Jason Rumney]

Richard Stallman wrote:

>Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
>and tell me what you think of it?
>  
>
I use it every day, and I find it useful.

Its purpose is similar to speedbar, but it seperates Directories, Files 
and Tags into separate buffers, which many people find easier to work 
with. It also has some extra buffers that do not have an equivalent in 
speedbar, such as History and can also embed speedbar in one of its 
navigation windows if you prefer speedbar but want to use ECB for some 
reason.

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.

Re: ECB

[Jérôme Marant]

Jason Rumney <jasonr@gnu.org> writes:


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

Cheers,

-- 
Jérôme Marant

Re: ECB

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

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

One difference between an IDE and Emacs is that IDEs often show
various bits of information about the current project in little
windows around the suorce code.  With ECB, Emacs can do the same
thing.

ECB is très cool.

Note that ECB works with CEDET which provides parsing of source
code.  This is a framework that has lots of potential for vastly
improving Emacs' support for different programming languages.  What
we can see in ECB is merely the tip of the iceberg.  I think that
including CEDET in Emacs would enable various other packages to take
advantage of it.  For example, font-lock could be improved by better
parsing, as could syntactic indentation.  CEDET already provides
syntax-driven completion: if x is a struct, then completing after
"x." completes the members of that struct.

CEDET is très cool.

Kai

Re: ECB

[Stefan]

> CEDET is très cool.

Indeed.  But it needs to be made lazier and less global.
Last time I tried to use JDE (which uses CEDET) it ended up taking a very
significant time to open up an Elisp or a C file even though I only ever
used CEDET-related operations on Java files.


        Stefan

Re: ECB

[Richard Stallman]

Does speedbar have any advantages over ECB?  In other words, if
we replaced Speedbar with ECB, would we lose anything?
If so, could those features be added to ECB?

Having both ECB and Speedbar would be duplication, and in general
it is better to avoid duplication when there's no good reason for it.

Re: ECB

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> Does speedbar have any advantages over ECB?  In other words, if
> we replaced Speedbar with ECB, would we lose anything?
> If so, could those features be added to ECB?

It is a different interface which many longtime Emacs users may be
used to. I don't think ECB can display in a seperate frame, though it
might be easy to change it so. There may also be modes that speedbar
supports that ECB does not. Speedbar seems to have special support for
info for instance, which I don't think is present in ECB.

> Having both ECB and Speedbar would be duplication, and in general
> it is better to avoid duplication when there's no good reason for it.

We already have duplication between etags and imenu. And semantic
(part of CEDET, along with speedbar) offers more features over both.
ECB and speedbar are just different ways of presenting the
information etags, imenu and semantic can produce. Speedbar uses one
buffer in a seperate frame containing a single tree heirachy. ECB
uses several buffers for different types of information.

Re: ECB

[Richard Stallman]

    Note that ECB works with CEDET which provides parsing of source
    code.  This is a framework that has lots of potential for vastly
    improving Emacs' support for different programming languages.

Could you tell me more about CEDET?

      I think that
    including CEDET in Emacs would enable various other packages to take
    advantage of it.  For example, font-lock could be improved by better
    parsing, as could syntactic indentation.  CEDET already provides
    syntax-driven completion: if x is a struct, then completing after
    "x." completes the members of that struct.

What language is CEDET written in?  What is its license?  How would we
make Emacs talk with it?

This could be a big step forward IF there is no horrible snag.

Re: ECB

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

>     Note that ECB works with CEDET which provides parsing of source
>     code.  This is a framework that has lots of potential for vastly
>     improving Emacs' support for different programming languages.
>
> Could you tell me more about CEDET?

The home page is cedet.sourceforge.net.  The name stands for
Collection of Emacs Development Environment Tools.  The tool that I
alluded to in my previous message was Semantic.

Semantic is a lexer, a parser generator, and also a parser.  It also
contains some tools to make use of the parsing results.  For example,
Semantic integrates with imenu to provide a better menu.  I think it
also integrates with eldoc to show function prototypes (function
signatures) for more languages.  And I already mentioned the
syntax-driven completion module.  There is also a component for
navigating the source code.  This one can navigate the source
according to syntactic constructs of the language:
forward-identifier, forward-statement, forward-block,
forward-method/subroutine/function/defun, forward-class, ...  There
is also a generalization of backward-up-list which groks statements,
block, classes etc.

My understanding is that the parsers generated by Semantic are
incremental, which is what you need for editing.

In addition to Semantic, there is also EDE which manages projects.
My understanding is that it can parse an AutoMake file and thus knows
which target a certain source file belongs to, so that it can offer
the right make target for compilation.  I guess it can do more that
is not immediately apparent.  There is also another module which can
write Makefiles for you, it appears to be useful for small projects.
Then people don't need to learn make or Autoconf.

Then there is COGRE for drawing diagrams.  It can create UML diagrams
from source code and display them, IIUC.

And then, CEDET contains libraries and utilities that are used for
implementing the other packages.

I hope that I have not misrepresented the CEDET functionality too
much.

>     I think that including CEDET in Emacs would enable various other
>     packages to take advantage of it.  For example, font-lock could
>     be improved by better parsing, as could syntactic indentation.
>     CEDET already provides syntax-driven completion: if x is a
>     struct, then completing after "x." completes the members of that
>     struct.
>
> What language is CEDET written in?

Emacs Lisp.

> What is its license?

GPL.

> How would we make Emacs talk with it?

Like any other Lisp package ;-)

> This could be a big step forward IF there is no horrible snag.

I agree totally.

Kai

Re: ECB

[Jason Rumney]

Kai Grossjohann <kai@emptydomain.de> writes:

> And then, CEDET contains libraries and utilities that are used for
> implementing the other packages.
>
> I hope that I have not misrepresented the CEDET functionality too
> much.

speedbar is also a part of CEDET. My understanding is that these
tools originally started as seperate elisp libraries, but have grown
dependant on each other and the author (Eric Ludlam <zappo@gnu.org>)
has decided to release them as a single package in future.

Re: ECB

[Jens Lautenbacher]

[-- Attachment #1.1: Type: text/plain, Size: 1472 bytes --]

On Sun, 2004-07-04 at 04:13, Richard Stallman wrote:
>     Note that ECB works with CEDET which provides parsing of source
>     code.  This is a framework that has lots of potential for vastly
>     improving Emacs' support for different programming languages.
> 
> Could you tell me more about CEDET?

As far as I know CEDET is the "new" package that encompasses semantic,
speedbar, eieio and oher stuff. Previously these have been separate
packages, of which only speedbar has been included into emacs
distribution (?).  

> This could be a big step forward IF there is no horrible snag.

Indeed. CEDET, together with ECB that uses the facilities of CEDET
provides most of what's needed for a IDE. The nice thing about it that
the ECB features automatically work for EVERY language that has a CEDET
parser. Other, language specific stuff is provided by other languages. I
think the most advanced example is Java, where ECB/CEDET provide the
window layout with source code browsing features, and the special Java
relates stuff is provided by JDE. This includes stuff like running a
Java interpreter in the background to automatically query all classes on
the classpath for their accessible methods etc. which allows for
completion not only in the current soure buffer (or a buffer already
parsed by CEDET) but on every callable class even if you only have it
packed in a .jar file.

In other words: ECB/CEDET together with JDE rocks.

	jtl

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: ECB

[Eric M. Ludlam]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 3195 bytes --]

Hi,

  I get emacs-devel as a digest.  Here is a reply to a few messages
  on the list.

>>> Kai Grossjohann <kai@emptydomain.de> wrote:
>> Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
>> and tell me what you think of it?
>
>One difference between an IDE and Emacs is that IDEs often show
>various bits of information about the current project in little
>windows around the suorce code.  With ECB, Emacs can do the same
>thing.
>
>ECB is très cool.
>
>Note that ECB works with CEDET which provides parsing of source
>code.  This is a framework that has lots of potential for vastly
>improving Emacs' support for different programming languages.  What
>we can see in ECB is merely the tip of the iceberg.  I think that
>including CEDET in Emacs would enable various other packages to take
>advantage of it.  For example, font-lock could be improved by better
>parsing, as could syntactic indentation.  CEDET already provides
>syntax-driven completion: if x is a struct, then completing after
>"x." completes the members of that struct.
>
>CEDET is très cool.

Just as an FYI on CEDET, all of the individual tools in it have
already had papers signed for them and sent in.  I have to get
periodic papers from my employer and a set is currently wandering
through the legal department.

>>> Stefan <monnier@iro.umontreal.ca> wrote:
>> CEDET is très cool.
>
>Indeed.  But it needs to be made lazier and less global.
>Last time I tried to use JDE (which uses CEDET) it ended up taking a very
>significant time to open up an Elisp or a C file even though I only ever
>used CEDET-related operations on Java files.

I recall your email to me.  The current CVS version has since been
updated to delay parsing to an idle timer.  Tools that need the
buffer parsed now must wait until an idle timer goes off, so related
decorations don't show up till a few seconds after the buffer is
visible.  Your other request of disabling parsing for an individual
mode is still on my to-do list but it is unclear to me what to do
about it since all the load-time hooks are auto-generated in
auto-load files.

>>> From: Jason Rumney <jasonr@gnu.org>
>Kai Grossjohann <kai@emptydomain.de> writes:
>
>> And then, CEDET contains libraries and utilities that are used for
>> implementing the other packages.
>>
>> I hope that I have not misrepresented the CEDET functionality too
>> much.
>
>speedbar is also a part of CEDET. My understanding is that these
>tools originally started as seperate elisp libraries, but have grown
>dependant on each other and the author (Eric Ludlam <zappo@gnu.org>)
>has decided to release them as a single package in future.

This is indeed correct.  Releasing one tool often required a new
release of another with only one bug fix in it.  It was quite a
hassle.  Releasing them all at once has simplified things, but made
testing a bit more challenging.

Enjoy
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: ECB

[Stefan]

> I recall your email to me.  The current CVS version has since been
> updated to delay parsing to an idle timer.  Tools that need the
> buffer parsed now must wait until an idle timer goes off, so related
> decorations don't show up till a few seconds after the buffer is
> visible.

Great to hear.

> Your other request of disabling parsing for an individual
> mode is still on my to-do list but it is unclear to me what to do
> about it since all the load-time hooks are auto-generated in
> auto-load files.

I'm not sure whether it should be on the todo list.  I think I mentioned it
more as a "this is so slow, please do *something*".  Other approaches such
as laziness are much better.

But if it's still deemed necessary, a way to "enable for a few specific
modes" would be more useful to me than a way to "disable for a few specific
modes".


        Stefan

Re: ECB

[Richard Stallman]

    We already have duplication between etags and imenu.

I hope you are not arguing that the presence of some of this flaw in
Emacs now means we should not try to avoid adding more.  I disagree
completely.  To have one flaw is not a good reason to add another.  To
the extent there is duplication between etags and imenu, that is
unfortunate.  More duplication would be more unfortunate.

    It is a different interface which many longtime Emacs users may be
    used to. I don't think ECB can display in a seperate frame, though it
    might be easy to change it so. There may also be modes that speedbar
    supports that ECB does not. Speedbar seems to have special support for
    info for instance, which I don't think is present in ECB.

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.

Would someone like to determine precisely which features we would
need to add to ECB to make this possible?

Meanwhile, another question is what needs to be done to integrate
ECB into Emacs cleanly.  Could someone take a look at that?

Neither of these questions is a rush.  We won't be doing any of this
before the next release.

Re: ECB

[Miles Bader]

Richard Stallman <rms@gnu.org> 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.

-Miles
-- 
I'd rather be consing.

Re: ECB

[Jason Rumney]

Miles Bader <miles@lsi.nec.co.jp> writes:

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

It can contain (physically on the screen, not as part of the Lisp
package) speedbar, but that is an option. It also uses speedbar
functionality to support modes that are not supported by semantic.

Re: ECB

[Richard Stallman]

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

    It can contain (physically on the screen, not as part of the Lisp
    package) speedbar, but that is an option. It also uses speedbar
    functionality to support modes that are not supported by semantic.

So, does this mean that ECB makes the existing Speebar package
obsolete?

If not, then why not?

Re: ECB

[Berndl, Klaus]

 
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

RE: ECB

[Berndl, Klaus]

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

RE: ECB

[Berndl, Klaus]

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

Re: ECB

[Jérôme Marant]

"Berndl, Klaus" <klaus.berndl@sdm.de> writes:

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

My apologies. While unpacking ecb, I was confused with tree-buffer.el
which my mind turned into tree-widget.el :-)

Cheers,

-- 
Jérôme Marant

Re: ECB

[Richard Stallman]

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

Could ECB implement both interfaces, so that the user use ECB
and still decide for himself which interface he likes more?

Re: ECB

[Richard Stallman]

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

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.

    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?

    - Required packages: either CEDET or the standalone libs eieio, semantic and
      speedbar (the need of the latter one is discussed above)

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?

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.

    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.

I think we do want to integrate it.  This may need multiple steps.

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

Re: ECB

[Richard Stallman]

Could you tell us more about semantic?

For instance, is it written entirely in Emacs Lisp?
If not, what other languages are needed?  Does it use any
separate auxiliary programs?

Are you the author of semantic?
If not, could you tell me how to reach the author?
It seems very desirable to include semantic in Emacs.

Re[2]: ECB

[Eric M. Ludlam]

>>> Richard Stallman <rms@gnu.org> seems to think that:
>Could you tell us more about semantic?
>
>For instance, is it written entirely in Emacs Lisp?
>If not, what other languages are needed?  Does it use any
>separate auxiliary programs?
>
>Are you the author of semantic?
>If not, could you tell me how to reach the author?
>It seems very desirable to include semantic in Emacs.

Semantic, and those other libraries it depends on are all written
entirely in Emacs Lisp.  The doc uses makeinfo.  There are two shell
scripts which are optional that use bash.  The scripts allow creation
of data files by calling Emacs in batch mode.  There is a utility that
generates UML diagrams from source code that calls "dot" (released by
ATT as a graph diagram kind of tool.) which is optional.  There were
rumors of a tool for using PostgreSQL as a database backend but I have
not seen news of it lately.

I am the main author of Semantic and all the items not currently in
Emacs that it depends on.  David Ponce is also a primary contributor.
Paul Kinnucan (author of JDEE) wrote the original imenu support, but
there is very little left of his original work.  Klaus Berndl (ECB
author) wrote a regression test.  All other packages that represent
significant works beyond a small patch by other authors are separated
in a "contrib" directory.

A version of semantic from perhaps around the year 2000 is already
fully assigned to the FSF.  I have my paperwork submitted to my
Employer's legal department for clearance on those intervening years
so the current version can be a part of Emacs too.

Semantic depends on several small utilities written in Emacs Lisp by
either myself or David Ponce including tools for simplified Image
loading and use, progress bar display, runtime version dependency
checking, and an implementation of "mode local" variables/functions.

I highly recommend using mode-local.el.  I think it could greatly
simplify the construction of any tool that has slightly different
behaviors in different major modes, or the major modes themselves.
It eliminates the need for hooks or complex functions that contain
lots of `setq' calls, or functions that branch based on a alist of
major modes.

http://cvs.sourceforge.net/viewcvs.py/cedet/cedet/common/mode-local.el?view=markup

Semantic also depends on EIEIO which is a CLOS layer also previously
assigned to the FSF.  It too is in the CEDET collection.

You can read about all the tools in the CEDET collection at this web
site:

http://cedet.sourceforge.net

The CEDET package scheme and related Makefiles are merely a
convenience for releasing and building all those tools together.  The
Makefiles are generated by EDE, which adds project management and
Makefile construction with a nifty GUI inside Emacs.

The most complex part of the build is converting grammar files (.by,
or .wy) into Emacs Lisp.  This requires a calling Emacs in batch mode
with Semantic loaded to perform the generation.

Also involved is a special autoload file generator.  It is a copy of
the one that comes with Emacs and modified to handle CLOS constructs
and some Semantic macros.

I hope this answers your questions.
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

RE: ECB

[Berndl, Klaus]

>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

Re: ECB

[Richard Stallman]

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

Re: ECB

[Richard Stallman]

    First of all we would have to specify what it is that "speedbar-like"-behavior.

I would define it as "whatever behavior Speedbar offers
that users would miss if they had to switch to ECB."
										    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)

In principle, any and all of these that a substantial number of users
like.  Perhaps users don't really like #1; they might generally prefer
the ECB approach.  I don't know whether users like #2, but I suspect
some do.  #3 and #4 are features, so I'm sure users like them.

transparent emacs

[Nic Ferrier]

Has anyone thought about making Emacs transparent since Miles Bader
did some work on emacs 20?

I've been playing with GTK Emacs... I can make the background come up
in the content pane but I can't stop the background color on the
words.

Transparent Emacs would be so cool.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: transparent emacs

[Miles Bader]

On Sat, Aug 07, 2004 at 12:10:24AM +0100, Nic Ferrier wrote:
> Has anyone thought about making Emacs transparent since Miles Bader
> did some work on emacs 20?

Note that my current "transparent emacs" (really, "tiling") emacs branch is
kept up-to-date with the CVS trunk (more or less; last merge about 1 week
ago).

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: transparent emacs

[Nic Ferrier]

Miles Bader <miles@gnu.org> 
 writes:

> On Sat, Aug 07, 2004 at 12:10:24AM +0100, Nic Ferrier wrote:
> > Has anyone thought about making Emacs transparent since Miles Bader
> > did some work on emacs 20?
> 
> Note that my current "transparent emacs" (really, "tiling") emacs branch is
> kept up-to-date with the CVS trunk (more or less; last merge about 1 week
> ago).

Is it still only in arch? Google didn't find an obvious working
download.


Nic

Re: transparent emacs

[Miles Bader]

On Sat, Aug 07, 2004 at 02:15:52AM +0100, Nic Ferrier wrote:
> > Note that my current "transparent emacs" (really, "tiling") emacs branch is
> > kept up-to-date with the CVS trunk (more or less; last merge about 1 week
> > ago).
> 
> Is it still only in arch? Google didn't find an obvious working
> download.

Yes, but if you can't get arch to work for some reason, I can easily send you
a patch against a recent CVS emacs.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: transparent emacs

[Romain Francoise]

Miles Bader <miles@gnu.org> writes:

> Note that my current "transparent emacs" (really, "tiling") emacs branch is
> kept up-to-date with the CVS trunk (more or less; last merge about 1 week
> ago).

For the record, I'll mention that I use this Emacs branch and like the
feature very much.  It might not be the most essential thing in an
editor but having a good-looking Emacs environment is nice, and it
integrates well with other "transparent" applications. [1]

I do hope it will get merged in the main trunk along with multi-tty and
Unicode changes for Emacs 22.

Cheers,

-- 
Romain Francoise <romain@orebokech.com> | It's in your reach.
it's a miracle -- http://orebokech.com/ | Concentrate.

Footnotes:
[1] <URL: http://orebokech.com/my/shot_tiling.png>

GTK emacs (and access to GTK)

[Nic Ferrier]

I started to use GTK emacs a few months ago... Life was a bit busy so
I forgot to say "the GTK port of Emacs is brilliant!"

So I'm going to say it now:

The GTK port of Emacs is brilliant.

Well done to everybody involved in hacking it.


A related question: what are the views about allowing Emacs to create
GTK objects directly? 

I know it is generally frowned upon to export native window system
primitives into Emacs but because GTK is a GNU lib maybe there could
be an exception. 

William Perry already wrote some code for XEmacs which could maybe
serve as a guide?

  http://www.cs.indiana.edu/elisp/gui-xemacs/


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: GTK emacs (and access to GTK)

[David Kastrup]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I started to use GTK emacs a few months ago... Life was a bit busy so
> I forgot to say "the GTK port of Emacs is brilliant!"
>
> So I'm going to say it now:
>
> The GTK port of Emacs is brilliant.
>
> Well done to everybody involved in hacking it.

Well, I am missing an option to use Athena style scrollbars.
Actually, this is more a GTK shortcoming (that you can't just
configure Athena behavior for all GTK apps), but if I at least have
the option to override this at compile time of my most important
application, it would be a good consolation.

I'd prefer it if somebody implemented an Athena-behavior option for
GTK in general.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: GTK emacs (and access to GTK)

[Jan D.]

Nic Ferrier wrote:
> I started to use GTK emacs a few months ago... Life was a bit busy so
> I forgot to say "the GTK port of Emacs is brilliant!"
> 
> So I'm going to say it now:
> 
> The GTK port of Emacs is brilliant.
> 
> Well done to everybody involved in hacking it.

Thank you.

> 
> 
> A related question: what are the views about allowing Emacs to create
> GTK objects directly? 
> 
> I know it is generally frowned upon to export native window system
> primitives into Emacs but because GTK is a GNU lib maybe there could
> be an exception. 
> 
> William Perry already wrote some code for XEmacs which could maybe
> serve as a guide?
> 
>   http://www.cs.indiana.edu/elisp/gui-xemacs/

I haven't looked at that code, so I can't say how much effort there is to do 
this.  It is something for the future, and has some advantages.  For example, 
Emacs could make its own file dialog where things like tramp works.

	Jan D.

Re: GTK emacs (and access to GTK)

[Jan D.]

David Kastrup wrote:
> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> 
> 
>>I started to use GTK emacs a few months ago... Life was a bit busy so
>>I forgot to say "the GTK port of Emacs is brilliant!"
>>
>>So I'm going to say it now:
>>
>>The GTK port of Emacs is brilliant.
>>
>>Well done to everybody involved in hacking it.
> 
> 
> Well, I am missing an option to use Athena style scrollbars.
> Actually, this is more a GTK shortcoming (that you can't just
> configure Athena behavior for all GTK apps), but if I at least have
> the option to override this at compile time of my most important
> application, it would be a good consolation.

You can at least use Emacs native scroll bars with GTK now (a minor bug 
prevented that previously).

	Jan D.

Re: GTK emacs (and access to GTK)

[Nic Ferrier]

"Jan D." <jan.h.d@swipnet.se> writes:

> > A related question: what are the views about allowing Emacs to create
> > GTK objects directly? 
> > 
> > I know it is generally frowned upon to export native window system
> > primitives into Emacs but because GTK is a GNU lib maybe there could
> > be an exception. 
> > 
> > William Perry already wrote some code for XEmacs which could maybe
> > serve as a guide?
> > 
> >   http://www.cs.indiana.edu/elisp/gui-xemacs/
> 
> I haven't looked at that code, so I can't say how much effort there is to do 
> this.  It is something for the future, and has some advantages.  For example, 
> Emacs could make its own file dialog where things like tramp works.

I think it would improve usability for newbies because things like
configuration buffers could be made to appear (by preference) as GTK
dialogs.

As you say: things like tramp and even search and replace, could have
GTK facades.

Of course, no one here would use them. But I know a lot of programmers
who are just too scared to learn emacs, if they could fool themselves
into thinking it was just an editor they might take the plunge.

/8->

I'd be interested in helping hacking on this if someone else led the
effort.


Nic

Re: GTK emacs (and access to GTK)

[Peter Heslin]

On 2004-11-02, Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:
>  The GTK port of Emacs is brilliant.

Indeed it is.  One query: is the lack of support for the GTK
menu-accelerator keystrokes (eg. hitting F10 and navigating the menus
by using the cursor keys) regarded as an outstanding bug to be fixed
for the next release, as a wish-list feature, or as a rejected and
undesirable feature?  I, for one, find that the support of XEmacs for
this feature is one of the few places where it has an advantage over
GNU Emacs.

It would be nice if it could be fixed for the next release, but it may
be a non-trivial task.  I once looked at the code, and saw that this
GTK feature was explicitly disabled by Emacs.  I tried enabling it,
and saw that there were weird side-effects in which point moved in the
buffer in addition to the menu navigation, and so I gave up
investigating it.

Peter

Re: GTK emacs (and access to GTK)

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> David Kastrup wrote:
>> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>> 
>>>I started to use GTK emacs a few months ago... Life was a bit busy so
>>>I forgot to say "the GTK port of Emacs is brilliant!"
>>>
>>>So I'm going to say it now:
>>>
>>>The GTK port of Emacs is brilliant.
>>>
>>>Well done to everybody involved in hacking it.
>> Well, I am missing an option to use Athena style scrollbars.
>> Actually, this is more a GTK shortcoming (that you can't just
>> configure Athena behavior for all GTK apps), but if I at least have
>> the option to override this at compile time of my most important
>> application, it would be a good consolation.
>
> You can at least use Emacs native scroll bars with GTK now (a minor
> bug prevented that previously).

Do you happen to know whether they have the three-button Athena
semantics (left/right buttons scroll up/down by equal amounts
proportional to click position, middle button "teleports")?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: GTK emacs (and access to GTK)

[Jan D.]

David Kastrup wrote:

>>You can at least use Emacs native scroll bars with GTK now (a minor
>>bug prevented that previously).
> 
> 
> Do you happen to know whether they have the three-button Athena
> semantics (left/right buttons scroll up/down by equal amounts
> proportional to click position, middle button "teleports")?

Yes they do, AFAIK the sematics are identical, they even use the same mouse 
pointer shapes.   I have not used native or Athena scroll bars much, but as for 
sematics, I can't tell the difference.

	Jan D.

Re: GTK emacs (and access to GTK)

[Jan D.]

> On 2004-11-02, Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:
>>  The GTK port of Emacs is brilliant.
>
> Indeed it is.  One query: is the lack of support for the GTK
> menu-accelerator keystrokes (eg. hitting F10 and navigating the menus
> by using the cursor keys) regarded as an outstanding bug to be fixed
> for the next release, as a wish-list feature, or as a rejected and
> undesirable feature?  I, for one, find that the support of XEmacs for
> this feature is one of the few places where it has an advantage over
> GNU Emacs.

The first, i.e. an outstanding bug to be fixed, but it is not critical 
for the next release.

>
> It would be nice if it could be fixed for the next release, but it may
> be a non-trivial task.  I once looked at the code, and saw that this
> GTK feature was explicitly disabled by Emacs.  I tried enabling it,
> and saw that there were weird side-effects in which point moved in the
> buffer in addition to the menu navigation, and so I gave up
> investigating it.

That sums up the work to be done quite nicely :-)

	Jan D.

Re: GTK emacs (and access to GTK)

[Nic Ferrier]

Peter Heslin <public@heslin.eclipse.co.uk> writes:

> On 2004-11-02, Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:
> >  The GTK port of Emacs is brilliant.
> 
> Indeed it is.  One query: is the lack of support for the GTK
> menu-accelerator keystrokes (eg. hitting F10 and navigating the menus
> by using the cursor keys) regarded as an outstanding bug to be fixed
> for the next release, as a wish-list feature, or as a rejected and
> undesirable feature?  I, for one, find that the support of XEmacs for
> this feature is one of the few places where it has an advantage over
> GNU Emacs.
> 
> It would be nice if it could be fixed for the next release, but it may
> be a non-trivial task.  I once looked at the code, and saw that this
> GTK feature was explicitly disabled by Emacs.  I tried enabling it,
> and saw that there were weird side-effects in which point moved in the
> buffer in addition to the menu navigation, and so I gave up
> investigating it.

I'm guessing that Emacs keymaps would get in the way.

So one would have to have a key binding that passed through the key
event to the GTK control.

This is the sort of thing that I'm talking about: tighter integration
with GTK as an option for Emacs. So by default Emacs (even Emacs/GTK)
would not have this stuff turned on but it would be available.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

java and tag completion

[Nic Ferrier]

Can anyone tell me if tag completion works properly for Java source
files?

I've built a tags table in the correct way and I can find tags in the
source tree (which is useful) but what I really want is 'proper'
completion, ie: I type an instance variable "." half a method name and
Emacs works out what method I am using.

For example, in the following code:

  com.nic.Xyz x = new com.nic.Xyz("hello");
  x.foo

If I do tag completion now I would expect Emacs to complete the
code thusly:

  x.fooBar(

It doesn't. It does work sometimes...

Is it expected to work? Or is Java a bit too odd to do traditional tag
completion?


(I am sketching out an alternative using a similar system to tags).

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

show-paren-mode stuffed in latest CVS

[Nic Ferrier]

I don't know much about show-paren-mode so I'm not sure I can spend
time trying to fix it.

But in the latest CVS build (today at 3pm GMT) it doesn't work
(there's just no highlight)


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

As we are all aware, certain Emacs interactions are not as useful as
their shell like counterparts.

For example, using sql-mode to interact with PostgreSQL is not as
useful as doing it outside of Emacs.

The reason for this is that comint mode cannot effectively communicate
with certain programs to do things like completion.

I have a proposal for fixing that and this email describes it.

Most of the programs whose integration with Emacs we want to improve
use the GNU Readline library. This is why they have sophisticated
completion mechanisms.

GNU Readline works by defining an API for the things that a shell like
program will want to do and allowing keys to be bound to those API
functions.

So my suggestion for improving Emacs access to such programs is to add
an option to the GNU Readline library which allows Emacs to
call Readline API functions 'out of band'.

In effect this would work like this:

- Emacs starts a Readline program, eg: psql (the PostgreSQL client)
  with a special option specifying signifying this mode of operation.

- Readline somehow sees the option (maybe it is passed as an ENV var)
  and configures itself for this mode of operation

Readline and Emacs are now connected by some sort of stream (probably
just a standard comint/stdin scheme).

- Readline advertises to Emacs the functions the current program
  supports  by writing the information (a sexp?) to the stream

- Emacs reads the config from Readline and configures itself
  appropriately to bind Emacs keys to functions which send API calls
  to Readline over the stream.

- Readline communicates the status of the current line, and other
  status information (eg: completions) back over the stream for Emacs to
  display.


This seems like it wouldn't be that hard to add to Emacs and probably
not to Readline either.

Anyone have any thoughts?

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Stefan Monnier]

> - Emacs starts a Readline program, eg: psql (the PostgreSQL client)
>   with a special option specifying signifying this mode of operation.

A command-line argument is probably a bad idea (for cases like when you
start psql via a script (or a make file), ...).  An env-var would be good.

> This seems like it wouldn't be that hard to add to Emacs and probably
> not to Readline either.

Sounds like a good idea.

Such tools often offer things like a `listcompletions' commands which
Emacs can use to implement the completion itself.  Such a thing is used by
GUD for gdb.  Standardizing support for such things directly in comint might
also be a good idea, tho not as good because it only works for those
programs that go to the trouble of providing a `listcompletions' command.


        Stefan

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> - Emacs starts a Readline program, eg: psql (the PostgreSQL client)
>>   with a special option specifying signifying this mode of operation.
>
> A command-line argument is probably a bad idea (for cases like when you
> start psql via a script (or a make file), ...).  An env-var would be good.
>
>> This seems like it wouldn't be that hard to add to Emacs and probably
>> not to Readline either.
>
> Sounds like a good idea.
>
> Such tools often offer things like a `listcompletions' commands which
> Emacs can use to implement the completion itself.  Such a thing is used by
> GUD for gdb.  

Readline has a few standard functions:

  int rl_complete_internal (int what_to_do)

  int rl_complete (int ignore, int invoking_key)

  int rl_possible_completions (int count, int invoking_key)

  int rl_insert_completions (int count, int invoking_key)

  int rl_completion_mode (rl_command_func_t *cfunc)

Which, AFAIK, is what *most* programs doing completion use.  This is
what Readline should advertise to Emacs (or whatever, this wouldn't be
Emacs specific necessarily).

There are a number of other Readline completion tools and, with
slightly a complex advertising protocol, it would be possible to hook
those in too.


> Standardizing support for such things directly in comint might
> also be a good idea, tho not as good because it only works for those
> programs that go to the trouble of providing a `listcompletions'
> command.

But it wouldn't be difficult for comint to detect when this behaviour
is offered by Readline, either:

- do a version detect on the readline .so

- have this feature make readline send a "hello", when the "hello"
  isn't received then comint will know this feature is not available.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Sam Steingold]

> * Nic Ferrier <asreevre@gncfryysreevre.pb.hx> [2004-11-08 15:14:06 +0000]:
>
> But in the latest CVS build (today at 3pm GMT) it doesn't work
> (there's just no highlight)
confirmed...
-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
A slave dreams not of Freedom, but of owning his own slaves.

Re: show-paren-mode stuffed in latest CVS

[Kim F. Storm]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I don't know much about show-paren-mode so I'm not sure I can spend
> time trying to fix it.
>
> But in the latest CVS build (today at 3pm GMT) it doesn't work
> (there's just no highlight)

Works here.

Did you try make bootstrap ?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

storm@cua.dk (Kim F. Storm) writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>
>> I don't know much about show-paren-mode so I'm not sure I can spend
>> time trying to fix it.
>>
>> But in the latest CVS build (today at 3pm GMT) it doesn't work
>> (there's just no highlight)
>
> Works here.
>
> Did you try make bootstrap ?

Yup.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Luc Teirlinck]

Nic Ferrier wrote:

   >> But in the latest CVS build (today at 3pm GMT) it doesn't work
   >> (there's just no highlight)
   >
   > Works here.
   >
   > Did you try make bootstrap ?

   Yup.

And you did this Monday or later?  (Kim fixed `make bootstrap' some
time Sunday.)

You mean that after:

emacs -q
M-x show-paren-mode
(abc)

you do not see the parentheses highlighted?

I do see the highlight.

Sincerely,

Luc.

Re: show-paren-mode stuffed in latest CVS

[Denis Bueno]

On 09 Nov 2004, at 11.30, Nic Ferrier wrote:
> storm@cua.dk (Kim F. Storm) writes:
>
>> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>>
>>> I don't know much about show-paren-mode so I'm not sure I can spend
>>> time trying to fix it.
>>>
>>> But in the latest CVS build (today at 3pm GMT) it doesn't work
>>> (there's just no highlight)
>>
>> Works here.
>>
>> Did you try make bootstrap ?
>
> Yup.

Broken here also, OS X 10.3.6. Did make maintainer-clean, ./configure 
--without-x --enable-carbon-app, make bootstrap.

--
Denis Bueno
PGP: http://pgp.mit.edu:11371/pks/lookup?search=0xA1B51B4B&op=index
"Politeness, n. The most acceptable hypocrisy." - Ambrose Bierce, The 
Devil's Dictionary

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    - Readline advertises to Emacs the functions the current program
      supports  by writing the information (a sexp?) to the stream

I am not quite sure what this means.  What questions would this
information answer?  Could you give an example?

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Nic Ferrier wrote:
>
>    >> But in the latest CVS build (today at 3pm GMT) it doesn't work
>    >> (there's just no highlight)
>    >
>    > Works here.
>    >
>    > Did you try make bootstrap ?
>
>    Yup.
>
> And you did this Monday or later?  (Kim fixed `make bootstrap' some
> time Sunday.)

I believe I gave a GMT reference on my original email. The timestamp
of the email will also tell you what day, but in short, yes: Monday.

I noticed that there were more changes checked in to the relevant
elisp file so I'm rebuilding again.

I'll let the list know what happens.



> You mean that after:
>
> emacs -q
> M-x show-paren-mode
> (abc)
>
> you do not see the parentheses highlighted?

Er, yes. That's what I mean.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

")
Message-ID: <87lldawrag.fsf@tapsellferrier.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Richard Stallman <rms@gnu.org> writes:

>     - Readline advertises to Emacs the functions the current program
>       supports  by writing the information (a sexp?) to the stream
>
> I am not quite sure what this means.  What questions would this
> information answer?  Could you give an example?

Sure.

Let's imagine I want to start psql (the PostgreSQL command line
client) in Emacs. This is what might happen, given my suggestion:

Emacs does:  READLINE_CTRL=API psql somedb

This opens the normal stream between the two programs, but puts
libreadline into 'api' mode


psql/Readline sends: (readline-api rl_insert_text 
                                   rl_delete_text
                                   rl_copy_text
                                   rl_kill_text
                                   rl_complete  
                                   rl_possible_completions
                                   rl_insert_completions)


This tells Emacs what function calls the readline program can accept.

The next step is that the user gives some input to emacs:

   select * from 

and then she presses C-TAB (the completion key). Emacs doesn't know
how to complete the line but it does know that psql/Readline supports
rl_complete so:

Emacs sends: (rl_complete "select * from ")

psql/Readline accepts the command, performs it and then:

psql/Readline sends: ("invoices" "orders" "expenses" "users")

and Emacs can display the completion list. The user types an "i" and
presses C-TAB so now....

Emacs sends: (rl_complete "select * from i")

and psql/Readline responds with: ("nvoices")

so now there is only one completion item Emacs can display the line:

    select * from invoices

At some point the user presses enter and Emacs passes the line to
psql/Readline again in some form that causes psql/Readline to execute
the line and send the output to the stream.



This would be a very cool way to solve the problem of getting at
completion services provided by, in particular, Readline enabled
programs.

It would require quite a lot of work to make Readline do it though.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

It's working again now as of CVS at 9th Novemeber 2004 15:00 GMT

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Richard Stallman]

I fixed this a day ago--does it work now?

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

> I fixed this a day ago--does it work now?

Yes.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    Let's imagine I want to start psql (the PostgreSQL command line
    client) in Emacs. This is what might happen, given my suggestion:

    Emacs does:  READLINE_CTRL=API psql somedb

    This opens the normal stream between the two programs, but puts
    libreadline into 'api' mode

It would be misleading to name this mode `api'.  Readline, being a
library, has an api.  That api is how the application communicates
with Readline.  It is always the same.

    psql/Readline sends: (readline-api rl_insert_text 
				       rl_delete_text
				       rl_copy_text
				       rl_kill_text
				       rl_complete  
				       rl_possible_completions
				       rl_insert_completions)


    This tells Emacs what function calls the readline program can accept.

Do you mean, commands to accept from Emacs?  If so, please don't call
them "function calls"; that is confusing.  Function calls into
Readline come from the app.

    Emacs sends: (rl_complete "select * from ")

    psql/Readline accepts the command, performs it and then:

That I can understand.  I think there needs to be some sort of quoting
convention, so that real user input can be distinguished from commands
to Readline itself.

I don't understand why there needs to be more than one command.  What
is it that Emacs needs to do other than use rl_complete?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

")
Message-ID: <873bzgbub2.fsf@tapsellferrier.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Richard Stallman <rms@gnu.org> writes:

>     Emacs sends: (rl_complete "select * from ")
>
>     psql/Readline accepts the command, performs it and then:
>
> That I can understand.  I think there needs to be some sort of quoting
> convention, so that real user input can be distinguished from commands
> to Readline itself.
>
> I don't understand why there needs to be more than one command.  What
> is it that Emacs needs to do other than use rl_complete?

What about history? Emacs' comint mode keeps quite a small history by
default and also doesn't save the history in a file, many Readline
programs do offer this.


If one used a quoting convention as you suggested then only one or two
commands would be necessary.

A quoting convention would be quite neat... but the trouble is it's
difficult to choose a quote.

So I was proposing a completly new way of communicating with
Readline. 

But maybe I should look again at a quoting convention.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Kai Grossjohann]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> So I was proposing a completly new way of communicating with
> Readline. 

You mean, a way where readline doesn't read from stdin or from the
terminal?  Readline could open a Unix domain socket, I guess.

Kai

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Kai Grossjohann <kai@emptydomain.de> writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>
>> So I was proposing a completly new way of communicating with
>> Readline. 
>
> You mean, a way where readline doesn't read from stdin or from the
> terminal?  Readline could open a Unix domain socket, I guess.

The communication channel doesn't matter. It's what Readline does with
it that counts.

I was proposing having a new mode where Readline reads *commands* from a
stream, instead of keydata.

Right now what Readline does is this:

- read a character (or a keypress) from the input
- lookup the command the key is bound to
- execute the command

I was proposing an alternative communication system which would go
like this:

- read a command name and some arguments from the input
- execute the command

What rms is saying is that one could adapt the current Readline
communication channel to break out of the normal reading and switch
into the new mode. Maybe he's right. I'm not sure if it wouldn't be
more complicated to manage the state of the current line once commands
were being sent.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Kai Grossjohann]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> What rms is saying is that one could adapt the current Readline
> communication channel to break out of the normal reading and switch
> into the new mode. Maybe he's right. I'm not sure if it wouldn't be
> more complicated to manage the state of the current line once commands
> were being sent.

For Emacs interaction, the normal mode might not be needed at all.
WDYT?

The command-oriented mode could provide a special command to accept
and process a line.

Kai

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Kai Grossjohann <kai@emptydomain.de> writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>
>> What rms is saying is that one could adapt the current Readline
>> communication channel to break out of the normal reading and switch
>> into the new mode. Maybe he's right. I'm not sure if it wouldn't be
>> more complicated to manage the state of the current line once commands
>> were being sent.
>
> For Emacs interaction, the normal mode might not be needed at all.
> WDYT?

That's right.


> The command-oriented mode could provide a special command to accept
> and process a line.

That's right. That was the idea.


But rms was suggesting that Readline already has all the functionality
for receiving lines (/8-) but a breakout might be useful to allow
Emacs to collect completions (and maybe history).

The trouble is how do you keep it all synchronized?


The user is entering a line in Emacs, with the text being sent to the
process so that Readline can see it in the normal way. So far she's
typed:

   select * from 

and now she presses C-TAB. Emacs has to ask Readline to do completion
of the current line and get the completions back. How does it do this?

Some quote thing could be sent, followed by a command. I guess what
Realine would have to do is:

- stop associating the input stream with the current line
- read the command
- execute the command
- respond with the output (delimitted in some way, maybe sexps?)
- go back to associating the input stream with the current line


So that might work.

But what quote to use?


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    What about history? Emacs' comint mode keeps quite a small history by
    default and also doesn't save the history in a file, many Readline
    programs do offer this.

If you are using comint, you have all the history in Emacs.
The history commands do not need to interact with the program.

    So I was proposing a completly new way of communicating with
    Readline. 

I thought these command would go thru the pty to the subprogram.
Are you thinking that Readline would talk to Emacs thru a socket?
That's ok if you make it work.

But you have not said what method of communication you have in mind.
Would you please say what it is?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     What about history? Emacs' comint mode keeps quite a small history by
>     default and also doesn't save the history in a file, many Readline
>     programs do offer this.
>
> If you are using comint, you have all the history in Emacs.
> The history commands do not need to interact with the program.

But comint's history is not as functional as the history provided by
some Readline programs:

- Readline programs often keep their history over invocations, comint
  does not

- Readline programs often have very large line historys, but comint
  tends to have a small line history (I guess this is changeable but
  it would be expensive for all comint buffers)

Also, Emacs does not 'add value' to line historys... so if they could
be delegated (if the sub program does have Readline and history
support then use it) it would be a good thing I think.


>     So I was proposing a completly new way of communicating with
>     Readline. 
>
> I thought these command would go thru the pty to the subprogram.
> Are you thinking that Readline would talk to Emacs thru a socket?
> That's ok if you make it work.

No. I think they would go through the pty to the subprogram. I was
suggesting that Readline would stop seeing the pty as a pty and treat
it more like a stream.

I am examining ways to achieve better integration with programs that
offer sophisticated command line facilities.

I may have a muck around with comint to see if I can get it to use
Readline expansions in a generic way.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Kim F. Storm]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

>> I thought these command would go thru the pty to the subprogram.
>> Are you thinking that Readline would talk to Emacs thru a socket?
>> That's ok if you make it work.
>
> No. I think they would go through the pty to the subprogram. I was
> suggesting that Readline would stop seeing the pty as a pty and treat
> it more like a stream.

That's a bad idea, imo.

Consider if the subprogram is a shell that can launch another program.
Then the readline extensions should only be used when the shell
has control, but not when other programs are running.

But how can you know when the shell is reading from the stream, or
when it is the sub-subprogram that's reading?


If you go to the trouble of improving this, it would be better to
have a control socket into readline which could ALSO inform comint
whether the readline API is currently active or not, i.e. it would
send messages like:

rl_ready
rl_hold
rl_continue
rl_exit

to inform you of whether it makes any sense to use any of the
rl_api functions.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    > If you are using comint, you have all the history in Emacs.
    > The history commands do not need to interact with the program.

    But comint's history is not as functional as the history provided by
    some Readline programs:

That's too bad, but if you're in comint, you get comint's history
feature.  That is the only thing that makes sense.  However, we could
arrange for comint to save history from one invocation to the next, if
that is desired.

    No. I think they would go through the pty to the subprogram. I was
    suggesting that Readline would stop seeing the pty as a pty and treat
    it more like a stream.

What exactly would tell Readline to start treating the pty that way?
That is, how does Readline know it is time to read a completion
command rather than a line of input?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     No. I think they would go through the pty to the subprogram. I was
>     suggesting that Readline would stop seeing the pty as a pty and treat
>     it more like a stream.
>
> What exactly would tell Readline to start treating the pty that way?
> That is, how does Readline know it is time to read a completion
> command rather than a line of input?

An environment variable on the sub-program invocation.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> That's too bad, but if you're in comint, you get comint's history
> feature.  That is the only thing that makes sense.  However, we could
> arrange for comint to save history from one invocation to the next, if
> that is desired.

Right now it is up to the authors of comint-using modes to do that.
sql-mode for example does this at the end:

  ;; People wanting a different history file for each
  ;; buffer/process/client/whatever can change separator and file-name
  ;; on the sql-interactive-mode-hook.
  (setq comint-input-ring-separator sql-input-ring-separator
	comint-input-ring-file-name sql-input-ring-file-name)
  ;; Calling the hook before calling comint-read-input-ring allows users
  ;; to set comint-input-ring-file-name in sql-interactive-mode-hook.
  (comint-read-input-ring t)

And when the process is stopped:

  (comint-write-input-ring)

So the machinery is already in place.

I do agree that the history is far too small for today's standards.
comint-input-ring-size's value is 32 -- this is ok if all you can do
is move up and down the list, but these days we can list all matching
input, we can search backwards, etc.  32 makes no sense.  On my system
I set it to 500.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: a suggested solution for better external' completion in certain emacs modes

[Stefan]

> But how can you know when the shell is reading from the stream, or
> when it is the sub-subprogram that's reading?

Yup, that's a very difficult problem.

> If you go to the trouble of improving this, it would be better to
> have a control socket into readline which could ALSO inform comint
> whether the readline API is currently active or not, i.e. it would
> send messages like:

A separate socket is very limiting since it only works for the
"original" program.  If you run a program from within your original program,
it won't work any more.  E.g. it won't work for a shell run via ssh on
a remote host; it won't work for a shell run via `su' or `sudo'; ...


        Stefan

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

I will change the default for comint-input-ring-size to 150.

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    > What exactly would tell Readline to start treating the pty that way?
    > That is, how does Readline know it is time to read a completion
    > command rather than a line of input?

    An environment variable on the sub-program invocation.

The environment variable can't be changed during sub-program execution.
Are you saying that ALL communication with the subprogram will
use this new command protocol?  Not just when the user asks for
completion?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     > What exactly would tell Readline to start treating the pty that way?
>     > That is, how does Readline know it is time to read a completion
>     > command rather than a line of input?
>
>     An environment variable on the sub-program invocation.
>
> The environment variable can't be changed during sub-program execution.
> Are you saying that ALL communication with the subprogram will
> use this new command protocol?  Not just when the user asks for
> completion?

Yes. It would be a completely new way for Emacs to communicate with
Readline programs. But it would still be implemented in comint so that
comint could pick when to use the new method and when to use ordinary
pty communication.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    Yes. It would be a completely new way for Emacs to communicate with
    Readline programs. But it would still be implemented in comint so that
    comint could pick when to use the new method and when to use ordinary
    pty communication.

How would comint know when the process reading input is a
readline-using program?  Suppose I am talking to bash, which uses
readline.  Then I run ftp, which does not use readline.
If comint tries to keep using this new command protocol,
ftp would get totally confused.

There may be a way to resolve this problem.
However, what we want to do here now is make progress towards
a release, not discuss ideas for new features.  So I suggest
that those interested in trying to implement this sort of thing
should contact you, and you can discuss the idea outside this list
and see if you can make it work.

RE: ECB

[klaus.berndl]

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.   

Re: ECB

[Stefan Monnier]

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


        Stefan

RE: ECB

[klaus.berndl]

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

Re: ECB

[Richard Stallman]

    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?

Re: ECB

[Richard Stallman]

    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?

RE: ECB

[klaus.berndl]

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

RE: ECB

[klaus.berndl]

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

Re: ECB

[Stefan Monnier]

> And IMVHO display-buffer should be moved from c-kernel to elisp-code

100% agreement.


        Stefan

RE: ECB

[Drew Adams]

    > And IMVHO display-buffer should be moved from c-kernel to elisp-code
    
    100% agreement.
    
Me too.

Re: ECB

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 08 Mar 2006 09:54:33 -0500
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> > And IMVHO display-buffer should be moved from c-kernel to elisp-code
> 
> 100% agreement.

Based on what, exactly?  Do we know for a fact that its performance is
so unimportant that the slower running times of Lisp will go
unnoticed?

Re: ECB

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>     > And IMVHO display-buffer should be moved from c-kernel to elisp-code
>
>     100% agreement.
>
> Me too.

In general it's nice ... but to enable the use of "defadvice" isn't
exactly the best motivation!

-miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: ECB

[Stefan Monnier]

>> > And IMVHO display-buffer should be moved from c-kernel to elisp-code
>> 100% agreement.
> Based on what, exactly?  Do we know for a fact that its performance is
> so unimportant that the slower running times of Lisp will go
> unnoticed?

I must say I'd be stunned if you could show me any evidence that an elisp
implementation would incur any noticeable preformance hit: if you look at
the C code of display-buffer you'll see it has no loop, and if you look at
the calls to display-buffer you'll see it's never called inside a loop.
I.e. its performance is completely uninteresting.


        Stefan

Re: ECB

[Richard Stallman]

    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.

Please don't implement this through advice!  Implement this through
extending the primitives to do what you need!

Re: ECB

[Eli Zaretskii]

> Cc: klaus.berndl@sdm.de,  rms@gnu.org,  emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 09 Mar 2006 11:04:23 -0500
> 
> I must say I'd be stunned if you could show me any evidence that an elisp
> implementation would incur any noticeable preformance hit

I don't need to show any evidence because I'm not arguing for any
change.

Re: ECB

[Juri Linkov]

>> And IMVHO display-buffer should be moved from c-kernel to elisp-code
>
> 100% agreement.

Rewriting display-buffer in C will also help implement a new option for
a persistent horizontal split:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2005-12/msg00267.html

-- 
Juri Linkov
http://www.jurta.org/emacs/