headers
Eric M. Ludlam | 2 Feb 2008 23:58
Gravatar

ECB patch

Howdy,

  Last fall I optimized the analyzer, and a slot ECB was using was
deleted.  The following patch (plus comment you can delete at your
leisure) uses a function that ought to work with older versions of
CEDET as well as the CVS version.

  ECB users wrappers for all this stuff so it probably needs some
additional assistance.

  I found a compile warning about a new required argument too, but I
made that optional in CEDET so that code can stay the same.

  I gave it a quick run, and it works against CVS/CEDET.

Enjoy
Eric

---------------------------------
*** ecb-analyse.el	12 May 2006 12:03:11 -0400	1.16
--- ecb-analyse.el	02 Feb 2008 17:56:01 -0500	
***************
*** 270,276 ****

  (defmethod ecb-analyse-more-nodes ((context semantic-analyze-context))
    "Show a set of ecb-nodes specific to CONTEXT."
!   (let ((localvars (oref context localvariables)))
      (when localvars
        (ecb-analyse-add-nodes "Local Variables" "Local Variables" localvars
                               ecb-analyse-nodetype-localvars)))
(Continue reading)

Permalink | Reply | 1 comment |
headers
klaus.berndl | 4 Feb 2008 09:28
Picon

Re: ECB patch

Hi Eric,

thanks for the patch and your effort! I will check this as soon as i find some time ;-)

Ciao,
Klaus

Eric M. Ludlam wrote:
> Howdy,
> 
>   Last fall I optimized the analyzer, and a slot ECB was using was
> deleted.  The following patch (plus comment you can delete at your
> leisure) uses a function that ought to work with older versions of
> CEDET as well as the CVS version.
> 
>   ECB users wrappers for all this stuff so it probably needs some
> additional assistance.
> 
>   I found a compile warning about a new required argument too, but I
> made that optional in CEDET so that code can stay the same.
> 
>   I gave it a quick run, and it works against CVS/CEDET.
> 
> Enjoy
> Eric
> 
> ---------------------------------
> *** ecb-analyse.el	12 May 2006 12:03:11 -0400	1.16
> --- ecb-analyse.el	02 Feb 2008 17:56:01 -0500
> ***************
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen J. Turnbull | 11 Feb 2008 00:36
Picon
Favicon

Re: window configurations no longer (since 21.5) include windows ! ?

Michael Sperber writes:

 > While this wasn't exactly intentional, identity preservation was a
 > kludge with the old implementation that tied down a number of internal
 > invariants related to GC we wanted to get rid of.

Where is this documented?  To the best of my knowledge the window
configuration refactoring just plopped down on XEmacs Patches one day
with no design documentation, and I don't recall ever hearing that it
was related to GC.  I always thought it was about moving to modern
pixel-based dimensions and getting non-performance-critical code out
of C.

 > Identity preservation was (to my knowledge) never documented,

I guess you missed this passage from the XEmacs Lisp manual:

    38.3 Deleting Windows
    =====================

    A window remains visible on its frame unless you "delete" it by
    calling certain functions that delete windows.  A deleted window
    cannot appear on the screen, but continues to exist as a Lisp
    object until there are no references to it.  There is no way to
    cancel the deletion of a window aside from restoring a saved
    window configuration (*note Window Configurations::).  Restoring a
    window configuration also deletes any windows that aren't part of
    that configuration.

The section on window configurations is pretty careful to avoid
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henry S. Thompson | 11 Feb 2008 11:22
Picon
Picon
Favicon

Re: window configurations no longer (since 21.5) include windows ! ?

My reading of the documentation goes with Stephen's, but that's pretty
much beside the point, I guess, although it's also clear that at least
one substantial application, namely ecb, depends on identity
preservation.

The substantive question is: what's the real functionality that is
lost when identity preservation is lost, and can we get it back w/o
losing the major benefits of the 21.5 promotion of much of the window
code from C to elisp?

I can see two alternative paths, doubtless there are others:

 1) (Re-)introduce identity preservation into the code.  I haven't
    looked into this in detail, but a quick look at the code suggests
    that if we a) included the windows themselves in saved
    configurations and b) factored most of split-window out into a
    function with an additional argument, namely the window to use for
    the new pane, and called _that_ from set-window-configuration, we
    could do this.  I _think_ all this would require at the C level
    would be a function which 'revived' a 'dead' window by flipping
    the relevant bit.

 2) Introduce a new souped-up version of save-window-excursion, call
    it save-window-bindings for the sake of argument, looks like this:

    (save-window-bindings (symbols. . .)
       ...)

    where the semantics is as for save-window-excursion, with the
    additional guarantee that each of the symbols which is bound to a
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephen J. Turnbull | 11 Feb 2008 12:44
Picon
Favicon

Re: window configurations no longer (since 21.5) include windows ! ?

Michael Sperber writes:

 > The thing about identity preservation pops up first here:

 > http://osdir.com/ml/emacs.xemacs.patches/2002-11/msg00099.html

Yikes!  Man, that's evil.  Totally counter-intuitive.  "We had to
destroy the window to save it."  All that just to move window-point?!?

Mike, this seriously needs rethinking.  It's just not reasonable to
invalidate window IDs across save-window-excursion under current ways
of thinking.  I agree that the `(setq outwin (display-buffer outbuf))'
idiom is probably going to be available most of the time but it's
ugly, and it's not obvious that such idioms will always work.  I'm not
even sure why it's supposed to work in this case: it seems obscure.

 > Without support from the explicit documentation, I would argue that
 > those assumptions were always unsafe.

I wish our documentation were that good.  I also think that in the
absence of an explicit disclaimer (eg. `delete-extent''s docstring
says "The extent cannot be used thereafter"), a user may reasonably
expect that a Lisp object won't spontaneously become meaningless.

Anyway, IMO Section 38.3 as quoted is sufficiently explicit.  Windows
are persistent objects and they can be revived.
Permalink | Reply | 1 comment |
headers
Michael Reiher | 11 Feb 2008 13:54
Picon
Picon

ECB-2.32 -- Treebuffer minimize problem

Please enter the details of your bug report here

Hi!

I just upgraded my ECB to 2.32 and while I was at it I did some slight 
reconfiguration. The problem I have now is, that tree buffers that 
automaximize don't minimize anymore upon selection of an entry. Strangely 
this seems to happen only with the two layouts I've choosen to use...: left5 
and a self created one (see below). It works all nicely with e.g. left4 or 
left6. Up to now I used left8, this also works fine. It also seems to happen 
only when selecting with the mouse. Pressing Return it behaves normally and 
minimizes. A manual "Redraw layout" also brings back the minimized windows. I 
tried to remove .xemacs-custom, but this didn't help either.

My custom layout (from .ecb-user-layouts.el):

(ecb-layout-define "left-symbols-custom" left nil
  (ecb-split-ver 0.6 t)
  (if (fboundp (quote ecb-set-methods-buffer)) (ecb-set-methods-buffer) 
(ecb-set-default-ecb-buffer))
  (dotimes (i 1) (other-window 1) (if (equal (selected-window) 
ecb-compile-window) (other-window 1)))
  (if (fboundp (quote ecb-set-analyse-buffer)) (ecb-set-analyse-buffer) 
(ecb-set-default-ecb-buffer))
  (dotimes (i 2) (other-window 1) (if (equal (selected-window) 
ecb-compile-window) (other-window 1)))
  (dotimes (i 2) (other-window 1) (if (equal (selected-window) 
ecb-compile-window) (other-window 1)))
  )
(Continue reading)

Permalink | Reply | 4 comments |
headers
klaus.berndl | 11 Feb 2008 14:20
Picon

Re: ECB-2.32 -- Treebuffer minimize problem

If i remember right, there is a drawback with XEmacs...
when i find some time i will take a look into the code
and send you a response if i find a solution...

Klaus

Michael Reiher wrote:
> Please enter the details of your bug report here
> 
> Hi!
> 
> I just upgraded my ECB to 2.32 and while I was at it I did some slight
> reconfiguration. The problem I have now is, that tree buffers that
> automaximize don't minimize anymore upon selection of an entry.
> Strangely 
> this seems to happen only with the two layouts I've choosen to
> use...: left5 and a self created one (see below). It works all nicely
> with e.g. left4 or left6. Up to now I used left8, this also works
> fine. It also seems to happen only when selecting with the mouse.
> Pressing Return it behaves normally and minimizes. A manual "Redraw
> layout" also brings back the minimized windows. I tried to remove
> .xemacs-custom, but this didn't help either. 
> 
> 
> My custom layout (from .ecb-user-layouts.el):
> 
> (ecb-layout-define "left-symbols-custom" left nil
>   (ecb-split-ver 0.6 t)
>   (if (fboundp (quote ecb-set-methods-buffer))
> (ecb-set-methods-buffer) (ecb-set-default-ecb-buffer))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefano Sabatini | 12 Feb 2008 11:36
Picon
Favicon

ecb-toggle-compile-window, python-mode and python-send-*

Hi all,

I'm trying python-mode with ECB.

I setted up it in this way:

(add-hook 'python-mode-hook
	  (lambda ()
            (add-to-list 'ecb-compilation-buffer-names '("*Python*"))))

In this way when I use the C-c C-c shortcut (python-send-buffer) or
another similiar python-send command I get the output sent to the
*Python* interaction buffer, which appears in the compilation-window
of the ECB layout.

Now I would like to activate the ecb-toggle-compile-window every time
a send command is executed, that is I would like to see the
compile-window raises if already it isn't, in a way similiar to what
happens when a compilation process is run for a C program.

I could redefine the various send functions to do it, then rebind the
various C-c C-r, C-c C-c etc shortcuts, but I wonder if there is a
more clever way, which maybe require some ECB hacking which I can't
tell (the same kind of magic which works on the compile command).

Any hints?

Best regards and thanks in advance.
--

-- 
Stefano Sabatini
(Continue reading)

Permalink | Reply | 2 comments |
headers
Prashanth | 12 Feb 2008 12:46
Picon
Gravatar

ECB with svn problem

Hi,

           I found this ECB and started using it, the problem that i
face is if there is a file under svn i couldn't able to alter the
buffer there are some options said in the doc to activate and
deactivate the version control which i couldn't find that with M-x.
So, what should i do to alter the files under version control.

--

-- 
regards,

Prashanth
http://munichlinux.blogspot.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 1 comment |
headers
klaus.berndl | 12 Feb 2008 12:47
Picon

Re: ecb-toggle-compile-window, python-mode and python-send-*

Hi,

see the documentation of `ecb-compilation-buffer-names' and 
`ecb-compilation-major-modes' ...

And see the node "Using a persistent compile window" in the
info manual for further information...

So (without knowing phython modes): maybe you have to add
something suitable to one of these mentioned options (s.a.)

Does this help?

Klaus

Stefano Sabatini wrote:
> Hi all,
> 
> I'm trying python-mode with ECB.
> 
> I setted up it in this way:
> 
> (add-hook 'python-mode-hook
> 	  (lambda ()
>             (add-to-list 'ecb-compilation-buffer-names
> '("*Python*")))) 
> 
> In this way when I use the C-c C-c shortcut (python-send-buffer) or
> another similiar python-send command I get the output sent to the
> *Python* interaction buffer, which appears in the compilation-window
(Continue reading)

Permalink | Reply | 1 comment |

Gmane