ECB-users willing to pretest the next ECB-release

Hi,

yes, I am really willing to test the next release as the last cedet /ecb 
combinations from CVS are not working with my setup.
My machine run WinXP SP3, XEmacs (only some weeks old), cedet and ecb just 
grabbed from cvs some minutes ago.

The startup is rather small:

(load-file (expand-file-name "~/.xemacs/site-lisp/cedet/common/cedet.el"))
(add-to-list 'load-path (expand-file-name 
"~/.xemacs/site-lisp/cedet/ecb"))
(require 'ecb-autoloads)

That's the end of the story because of missing loaddefs 
(show-message-log):

Setting up CEDET packages...done
Cannot open load file: "contrib-loaddefs"
Cannot open load file: "cogre-loaddefs"
Cannot open load file: "speedbar-loaddefs"
Cannot open load file: "ede-loaddefs"
Loading ede-speedbar...done
Loading ede-speedbar...
Loading efs-cu...done
Loading efs-cu...
Cannot open load file: "srecode-loaddefs"
Cannot open load file: "semantic-loaddefs"
Cannot open load file: "eieio-loaddefs"
Cannot open load file: "cedet-loaddefs"
Setting up CEDET packages...

Hopefully getting a working version on WinXP and XEmacs the next time.

I really appreciate the great work done uptonow.
Iff you need additional information or I should do some tests, just let me 
know.

Oskar






[email protected] 
07.05.2009 10:03
Bitte antworten an
[email protected]


An
[email protected]
Kopie

Thema
Ecb-list Digest, Vol 30, Issue 2






Send Ecb-list mailing list submissions to
                 [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
                 https://lists.sourceforge.net/lists/listinfo/ecb-list
or, via email, send a message with subject or body 'help' to
                 [email protected]

You can reach the person managing the list at
                 [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ecb-list digest..."


Today's Topics:

   1. Are there ECB-users willing to pretest the next forthcoming
      ECB-release with a lot of NEWS? ([email protected])


----------------------------------------------------------------------

Message: 1
Date: Thu, 7 May 2009 10:03:14 +0200
From: <[email protected]>
Subject: [ECB-list] Are there ECB-users willing to pretest the next
                 forthcoming ECB-release with a lot of NEWS?
To: <[email protected]>,
                 <[email protected]>,
                 <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Hi,
 
first of all sorry for using the cedet-mailing-lists for that but my hope 
is that there are also some ECB-users... ;-)
 
After almost 4 years without new ECB-releases: The next ECB-release is 
just around the corner ;-)
 
Coding and documentation has been finished, testing is on the way, but it 
would very good, if users could use the next-release candidate for their 
work so there are chances to detect bugs i can not find for myself...
 
Especially tests with XEmacs would be very appreciated, because i'm not a 
XEmacs user so my own test are very rudimentary - quite the same for next 
GNU Emacs 23 - i have installed it and performed some tests and also fixed 
some compatibility bugs. With Emacs 22 and 23 now all things seem working 
fine, but who knows.... ;-)
 
So my plea: If you are willing to do some beta-tests for the current 
CVS-version of ECB this would be very helpfull for a "bugfree" 
ECB-release....
 
If you are willing: Either check out latest CVS from the ECB-repository or 
download and install latest CVS-snapshot from 
http://ecb.sourceforge.net/downloads.html <
http://ecb.sourceforge.net/downloads.html> 
 
Please note: Next (and also current CVS-version) ECB-release needs 
obligatory CEDET >= 1.0pre6 (get it from CEDET-website) - the preinstalled 
semantic, eieio and speedbar-packages of Xemacs are not longer supported 
(to outdated)!
 
If you encounter any problems please report them...
 
Thanks a lot in advance.
 
Ciao,
Klaus
 
P.S. The NEWS of the next release:
* Changes for ECB version 2.33
 
** ECB now requires full CEDET-suite being installed (at least version 
1.0pre6)
 
   This means the support for the single packages semantic 1.4.X, eieio 
0.X
   and speedbar 0.X is completely switched off.
 
   As a consequence ECB is no longer runnable as XEmacs-package via the
   package-manager of XEmacs. This is because CEDET is not available as
   XEmacs-package. Therefore ECB can also not be run as XEmacs-package. If
   CEDET will later become a XEmacs-package then probably ECB will come 
back
   as XEmacs-package. But in the meanwhile you have to install ECB "by 
hand".
 
   In general the current CEDET is much more powerful than older
   semantic-versions and ECB uses this power, especially the power of the
   semantic-analyzer.
 
** Better compatibility with CEDET 1.0preX and semantic 2.0preX
 
*** The ECB-analyse-window now works very well with current semantic 
analyzer
    There is an own synchronize-option-set for the analyse-window:
    `ecb-analyse-buffer-sync', `ecb-analyse-buffer-sync-delay' and
    `ecb-analyse-buffer-sync-hook'. See the docstrings. The advantage is, 
that
    now the synchronizing of the analyse-window can be customized 
separately
    from the other ECB-windows. THis is important because for the
    analyse-window a higher delay (or even disabled auto.synchronizing)
    increases usability a lot. See the info-manual.
 
*** Fix compatibility about some changes of semantic concerning adopting
    external member-functions (as in C++ or eieio).
 
*** ECB now works very well with semantic-idle-scheduler-mode (s.a.)
 
** Completely reworked synchronizing mechanism of the ECB-windows
 
   Now there are separate options for synchronizing:
 
   - The basic ECB-windows (directories, sources, methods, history):
     `ecb-basic-buffer-sync', `ecb-basic-buffer-sync-delay' and
     `ecb-basic-buffer-sync-hook'.
   - The analyser-window (s.a.): `ecb-analyse-buffer-sync',
     `ecb-analyse-buffer-sync-delay' and `ecb-analyse-buffer-sync-hook'
   - The symboldef-window: `ecb-symboldef-buffer-sync',
     `ecb-symboldef-buffer-sync-delay' and 
`ecb-symboldef-buffer-sync-hook'
   - The integrated speedbar (if used): `ecb-speedbar-buffer-sync',
     `ecb-speedbar-buffer-sync-delay' and `ecb-speedbar-buffer-sync-hook'
   - The integrated eshell-support (if used): `ecb-eshell-buffer-sync',
     `ecb-eshell-buffer-sync-delay' and `ecb-eshell-buffer-sync-hook'
 
   But all options for synchronizing not the basic ECB-windows offer an
   additional choice 'basic: Then ECB uses the setting of the related 
option
   for the basic ECB-windows! Example: If you set `ecb-eshell-buffer-sync' 
to
   'basic then the value of `ecb-basic-buffer-sync' is used. If you set
   `ecb-eshell-buffer-sync-delay' to 'basic then the value of
   `ecb-basic-buffer-sync-delay' is used.
 
   The enhancement allows much more control for the synchronizing of 
certain
   windows.
 
** More user-responsible buffer-parsing based on the idle-mechanism of 
semantic
 
   Force a reparse of the semantic-source if the idle-scheduler is off.
   Generally ECB calls semantic to get the list of tags for current
   source-file of current edit-window. Per default ECB does never
   automatically force a reparse of the source-file - this is only done on
   demand by calling `ecb-rebuild-methods-buffer'. So per default the
   idle-scheduler of semantic is responsible for reparsing the source-file 
and
   when this is necessary (see `semantic-idle-scheduler-mode' for further
   details). This is the most user-resonsible and therefore the 
recommended
   approach.
 
   So it's strongly recommended to enable `semantic-idle-scheduler-mode'
   because then reparsing is always done during idle-time of Emacs and is 
also
   interruptable.
 
   But if this idle-scheduler is switched off then ECB offers now two
   possibilities (via 
`ecb-force-reparse-when-semantic-idle-scheduler-off'):
 
   - Not forcing itself a reparse when tags are needed by ECB: then a user
     declines knowingly Emacs/semantic-driven parsing of code when he/she
     switches off the idle-mode of semantic. This is the default behavior 
of
     ECB and the default value of this option. But this has also the
     consequence that the methods-buffer is only filed on demand via
     `ecb-rebuild-methods-buffer' (bound to \[C-c . r])!
 
     This means also in consequence that the methods-buffer is not
     automatically filled when a source-file is opened but first on demand
     after calling the command `ecb-rebuild-methods-buffer'!
 
   - Forcing a reparse when tags are needed: Then ECB forces semantic to 
parse
     the source-file when ECB needs tags to display. For this behavior 
this
     option has to be set to not nil.
 
   The term "forcing a reparse by semantic" is a simplification: ECB uses 
then
   the function `semantic-fetch-tags' which can decide that the cached 
tags
   are up-to-date so no real reparsing is necessary - but it can also run 
a
   full reparse and this reparse is not being done when Emacs is idle but
   immediatelly and not interruptable (as with the idle-scheduler of
   semantic), which can be quite annoying with big source-files.
 
** ECB is able to work with indirect buffers if the base-buffer is 
filebased
 
   Now you can work with indirect-buffers as well as with normal 
file-buffers,
   i.e. indirect buffers are shown in the history?, their contents are
   displayed in the methods-buffer, the ECB-analyse-buffer works with 
them,
   autom. synchronizing the ECB-tree-buffers works for them etc...
 
** Complete reworked history-buffer
 
*** The history is able to deal with indirect-buffer entries.
    See new option `ecb-history-stick-indirect-buffers-to-basebuffer'.
 
*** The history can now be bucketized, see new `ecb-history-make-buckets'.
    This option allows to define several criterias for building buckets in 
the
    history-buffer all the history entries are sorted in (e.g. by 
major-mode,
    directory, file-extension or regular expressions).
 
    You can change the bucketizing type on the fly via the popup-menu of 
the
    history-window.
 
    The regular expressions bucketizing allows in combination with the
    indirect-buffer ability to work with something like "virtual folders"
    (well, "virtual folders" light).
 
    For example, there is a large project with a huge number of files, and
    there are various tasks in this project. So it could be convenient to
    group buffers according to various tasks. It could be fulfiled through
    using indirect buffers, for example like this
 
       task_1-aaa.pl
       task_1-bbb.c
       task_1-ccc.sh
       ...
       task_N-xxx.java
       task_N-ccc.sh
 
    This means create indirect buffers with a name-part which can be used 
for
    grouping together buffers with same name-part (here e.g. task_1- ...
    task_N-). In the example above you would create two indirect buffers 
for
    the filebuffer ccc.sh, one named task_1-ccc.sh, the other named
    task_N-ccc.sh).
 
    Then use the new option `ecb-history-make-buckets' to define regexps 
for
    bucketizing all (indirect) buffers according their task-part in the
    buffer-name.
 
*** There are now new faces for the history entries.
    See new options `ecb-history-bucket-node-face',
    `ecb-history-dead-buffer-face' and `ecb-history-indirect-buffer-face' 
and
    equaly named new faces.
 
** Sticky parent-node for all ECB-windows of type tree-buffer
 
   In the header-line (only for GNU Emacs) of a tree-buffer always the
   current-parent node of the first visible node is displayed (if there is 
a
   parent node). This sticky node is exactly in the same manner clickable 
as
   all other nodes. There is a new option 
`ecb-tree-make-parent-node-sticky'
   which enabales/disables this new feature (default is enabled).
 
** Much saver advice-backbone for all advices needed by ECB
 
   This is not a user-visible change but enhances the stability of ECB by
   using now a new advice-backbone which guarantes that all ecb-advices 
are
   enabled rsp. disabled correctly depending on the surrounding context.
   Introducing three new macros `defecb-advice-set', `defecb-advice' and
   `ecb-with-original-adviced-function-set'.
 
** New support for Git and Monotone as version-control systems
 
   If Git rsp. Monotone are supported by VC (means vc-git.el rsp. 
vc-mtn.el
   are distributed with Emacs) then ECB supports now both of them out of 
the
   box.
 
** New features rsp. commands
 
*** New command `ecb-goto-window-edit-by-smart-selection'
 
*** New command `ecb-goto-window-ecb-by-smart-selection'
 
*** New option `ecb-ignore-pop-up-frames'
    The new option is for customizing the behavior of ECB concerning
    `pop-up-frames'. It allows three value: Always, only when a permanent
    compile-window is used and never. This makes ECB fully compatible with 
the
    option `pop-up-frames'.
 
** Full compatibility with Emacs 22
 
*** `balance-windows' now works with Emacs 22 too
    Cause of the completely new implemantation based on `window-tree' ECB
    uses a new machanism for enabling balance-windows to work properly 
with
    active ECB, so only the edit-windows are balanced but all ecb-windows
    remain on their sizes.
 
*** view-mode works also when a permanent compile-window is active
    This is especially important for displaying help and completions.
 
*** `master-mode' now works with Emacs 22
 
*** Grepping from ECB now uses per default `lgrep' rsp. `rgrep'.
 
**** The option `ecb-grep-function' defaults to `lgrep' if available
     If not it tries `igrep' or 'grep'.
 
**** `ecb-grep-find-function' has been renamed to 
`ecb-grep-recursive-function'
     It defaults to `rgrep' if available. If not it tries `igrep-find' or
     `grep-find'. The old value is automatically upgraded to the new 
option
     name.
 
*** Fixed problems with `ecb-fix-window-size' and active compile-windows
    With Emacs >= 22 the bugs of Emacs 21.3.X concerning 
`window-size-fixed'
    are fixed by the Emacs-team so now ECB supports this feature also with
    active compile-window.
 
*** Fixed small lack in the `switch-to-buffer-other-window'-advice.
    In Emacs 22 this command ignores the settings in `same-window-*'. Now 
ECB
    adopts this behavior also for its adviced version so the command works
    in a smart manner optimized for ECB.
 
** Better compatibility with Emacs 23
 
*** Removed an annoying behavior which has set the mark hundred of times 
even
    when the user just moves the cursor.
 
    This comes from a change within Emacs 23 and the function `goto-line'
    which sets the mark in Emacs 23. This is not necessary when not used 
as
    command but as internal utility. Now ECB uses its own 
goto-line-function
    which does not set the mark --> No unnecessary mark settings with 
Emacs
    23.
 
*** The adviced `display-buffer' is now fully compatible with Emacs 23
    This means simply that you can work with ECB and Emacs 23 as you 
expect.
 
** The commands `ecb-download-ecb' and `ecb-download-semantic' are 
deactivated
   These features are not supported anymore. It costs two much effort to 
keep
   the needed links and mechanism to the sourceforge-download-area up to 
date.
   Please download the needed release-archives and extract and install as
   described in the shipped README rsp. INSTALL-files.
 
** Fixed Bugs
 
*** Fixed a bug which prevented `ecb-rebuild-methods-buffer' from working
    correctly
 
*** Fixed a bug in the internals of the methods-filter which prevented
    all commands `ecb-methods-filter-*' from working correctly.
 
*** Fixed context-menu for VC-operations in the sources- and 
history-window
    Now all vc-commands are called interactively by ECB.
 
*** Fixed a bug with the ECB-navigation feature (C-c . p and C-c . n)
    Now the commands `ecb-nav-goto-next' and `ecb-nav-goto-previous' work
    saver and also for indirect buffers.
 
*** Fixed small bugs with synchronizing current tag with highlighted tag
    in the methods buffer. This was when the buffer was reparsed with
    `semantic-idle-scheduler-mode' or after saving the buffer.
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK 
i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

------------------------------

_______________________________________________
Ecb-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecb-list


End of Ecb-list Digest, Vol 30, Issue 2
***************************************

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

_______________________________________________
Ecb-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecb-list