Re: ECB-users willing to pretest the next ECB-release

Hi,
 
i saw some similar posting on the cedet-mailing list about problems compiling cedet with XEmacs (i assume you have followed the instructions in the INSTALL-file of CEDET?? cedet must be byte-compiled otherwise it would not work....
 
I don't think this is a ecb-problem but a cedet one..so please forward it to the cedet-mailinglist....
 
Ciao,
Klaus
 
BTW: why still using XEmacs; nowadays GNU Emacs 22 or 23 is more powerful and also much more supported than XEmacs, but this is of course only my humble opinion......

________________________________

Von: [email protected] [mailto:[email protected]] 
Gesendet: Donnerstag, 7. Mai 2009 20:34
An: [email protected]
Betreff: [ECB-list] 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