New speedbar version

New speedbar version

[Chong Yidong]

A new version of speedbar.el has been checked in.  It depends on three new
files: dframe.el, ezimage.el, and sb-image.el, which have been added to
the CVS repository.  The lisp/sb-*.xpm images have been removed, and a new
set of image files has been added in the directory etc/images/ezimage.

Please use `cvs -Rd up' to get the new files, and make bootstrap.  It
would be good if people could test the new speedbar version and see if
there are any compatibility problems.

Thanks.

Re: New speedbar version

[Bill Wohler]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> A new version of speedbar.el has been checked in.  It depends on three new
> files: dframe.el, ezimage.el, and sb-image.el, which have been added to
> the CVS repository.  The lisp/sb-*.xpm images have been removed, and a new
> set of image files has been added in the directory etc/images/ezimage.
>
> Please use `cvs -Rd up' to get the new files, and make bootstrap.  It
> would be good if people could test the new speedbar version and see if
> there are any compatibility problems.

Chong,

The new version of the speedbar seems to be working for MH-E. I like
the output in tooltips better than in the minibuffer. Otherwise, it
seems similar.

Your instructions for "make bootstrap" are important. If you simply
follow the rebuild instructions in INSTALL.CVS, the speedbar blanks
after half a second and you get the following message in the
minibuffer every half a second or so:

  DFRAME TIMER ERROR: (void-variable speedbar-attached-frame)

Thanks for moving the sb-* image files to etc/images.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: New speedbar version

[Romain Francoise]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> It would be good if people could test the new speedbar version and see
> if there are any compatibility problems.

It appears to be working great.  It's much nicer than the old version.

I notice that it doesn't respond to mouse-1 clicks, we should probably
fix this before the release.  (The old version didn't either.)

-- 
Romain Francoise <romain@orebokech.com> | I used to think there is no
it's a miracle -- http://orebokech.com/ | future left at all.

New speedbar version

[Nick Roberts]

 > A new version of speedbar.el has been checked in.

The file gdb-ui.el has used speedbar.el over the last two years to display
watch expressions.  Now, with supposedly a month or so to go before the
release, it doesn't.  There are 290 differences between this version and the
previous one.  The ChangeLog entry is:

	* speedbar.el: New version 1.0pre3.

If this is deemed reasonable behaviour then its probably not worth debating
the issue.

Nick

Re: New speedbar version

[Chong Yidong]

Nick Roberts <nickrob@snap.net.nz> writes:

> The file gdb-ui.el has used speedbar.el over the last two years to display
> watch expressions.  Now, with supposedly a month or so to go before the
> release, it doesn't.  There are 290 differences between this version and the
> previous one.  The ChangeLog entry is:
> 
> 	* speedbar.el: New version 1.0pre3.
> 
> If this is deemed reasonable behaviour then its probably not worth debating
> the issue.

Unfortunately, checking in the new version of Speedbar (which has been
undergoing development in its own tree for two years) was itself one
of the items needed for the release.  See, for example,

http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00202.html

Re: New speedbar version

[Richard M. Stallman]

      The ChangeLog entry is:

	    * speedbar.el: New version 1.0pre3.

    If this is deemed reasonable behaviour then its probably not worth debating
    the issue.

We have been waiting for a long time to be able to update Speedbar,
and I am glad it has finally been done.  However, that change log entry
is not adequate.  The change log entry has to describe the changes,
and stating a version number conveys no information about them.
I asked people to put in a clear itemized change log for this change.

I asked the people who worked on this to provide an itemized change
log.

Re: New speedbar version

[Nick Roberts]

 > Unfortunately, checking in the new version of Speedbar (which has been
 > undergoing development in its own tree for two years) was itself one
 > of the items needed for the release.

At first glance, I see the following problems:

* I don't understand the changes because there is no ChangeLog history.

* I don't know what the new features are because there is no documentation.

* It appears that the new FSF address has been replaced with the old one.

* RCS keywords have been introduced.

* I've done cvs -Rd update and make bootstrap but with info the speedbar
  doesn't show any nodes (I get the error message
  DFRAME TIMER ERROR: (void-variable speedbar-attached-frame))

* With gdb-ui.el I get (wrong-type-argument stringp nil) because 
  speedbar-check-read-only in speedbar-stealthy-function-list calls
  speedbar-line-file but there are no associated files, only variable
  values in the speedbar.

Nick

Re: New speedbar version

[Stefan Monnier]

> Unfortunately, checking in the new version of Speedbar (which has been
> undergoing development in its own tree for two years) was itself one
> of the items needed for the release.  See, for example,

> http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00202.html

BTW, could whoever worked on this speedbar.el thingy install on a branch the
"original" upstream version, so that in the future we will be able to
trivially extract the local changes we've made (or, equivalently, to easily
install a newer upstream release o n that branch and then ask CVS to do
(most of) the merge for us)?


        Stefan

Re: New speedbar version

[Miles Bader]

2005/10/2, Stefan Monnier <monnier@iro.umontreal.ca>:
> > Unfortunately, checking in the new version of Speedbar (which has been
> > undergoing development in its own tree for two years) was itself one
> > of the items needed for the release.  See, for example,
>
> > http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00202.html
>
> BTW, could whoever worked on this speedbar.el thingy install on a branch the
> "original" upstream version, so that in the future we will be able to
> trivially extract the local changes we've made (or, equivalently, to easily
> install a newer upstream release o n that branch and then ask CVS to do
> (most of) the merge for us)?

Anyway, as a general rule:  _never_ just "check in" new versions of
upstream files.  _Always_ merge them.  If that seems annoying then the
first step is to track down the history you need to do such a merge
(and hopefully, as Stefan suggests, do some preparation so that the
next merge is easier).

-Miles

--
Do not taunt Happy Fun Ball.

Re: New speedbar version

[Richard M. Stallman]

    Anyway, as a general rule:  _never_ just "check in" new versions of
    upstream files.  _Always_ merge them.

Yes, that's right.

Re: New speedbar version

[Chong Yidong]

> * I don't understand the changes because there is no ChangeLog history.
> * It appears that the new FSF address has been replaced with the old one.
> * RCS keywords have been introduced.
> * with info the speedbar doesn't show any nodes
> * With gdb-ui.el I get (wrong-type-argument stringp nil)

These should be fixed now.  I've added a ChangeLog entry for the
speedbar update into lisp/ChangeLog.

> * I don't know what the new features are because there is no documentation.

etc/NEWS and maybe the manual will have to be updated, but I'm still
working on this.

Following Romain Francoise's suggestion, I have changed dframe.el to
use the `mouse-1-click-follows-link' mechanism, for consistency with
the rest of Emacs 22.  The results seem to be strange -- sometimes
clicking mouse-1 works, but sometimes it just sets the point even
though I thought I clicked fast enough.  But I'm not sure it's a
problem with dframe, or with the mouse-1-click mechanism.  I often
fail at clicking other links too -- the timeout for the mouse-1-click
is too short for me.

IMO, the timeout for the mouse-1-click mechanism should be increased
to at least 2 seconds!

(The argument that it would take too long to set point is bogus --
wanting to set point inside a link is not a frequent event, and if it
often happens to you, you can always set mouse-1-click-follows-link to
nil.)

Re: New speedbar version

[Nick Roberts]

Chong Yidong writes:
 > > * I don't understand the changes because there is no ChangeLog history.
 > > * It appears that the new FSF address has been replaced with the old one.
 > > * RCS keywords have been introduced.
 > > * with info the speedbar doesn't show any nodes
 > > * With gdb-ui.el I get (wrong-type-argument stringp nil)
 > 
 > These should be fixed now.  I've added a ChangeLog entry for the
 > speedbar update into lisp/ChangeLog.

Thanks.

 > > * I don't know what the new features are because there is no documentation.
 > 
 > etc/NEWS and maybe the manual will have to be updated, but I'm still
 > working on this.
 
The new features aren't much use without documentation.  Does the new version
of speedbar (for Emacs and XEmacs) have generic documentation that can be
merged into our documentation?

Nick

Re: New speedbar version

[Romain Francoise]

Chong Yidong <cyd@stupidchicken.com> writes:

> I have changed dframe.el to use the `mouse-1-click-follows-link'
> mechanism, for consistency with the rest of Emacs 22.

Works fine, thanks.

-- 
Romain Francoise <romain@orebokech.com> | All you've been is a piece of
it's a miracle -- http://orebokech.com/ | blood wrapped in skin.

Re: New speedbar version

[Ralf Angeli]

* Chong Yidong (2005-10-04) writes:

> The results seem to be strange -- sometimes
> clicking mouse-1 works, but sometimes it just sets the point even
> though I thought I clicked fast enough.

Maybe you moved the mouse pointer away from the active area before the
time-out occured.

> But I'm not sure it's a
> problem with dframe, or with the mouse-1-click mechanism.  I often
> fail at clicking other links too -- the timeout for the mouse-1-click
> is too short for me.
>
> IMO, the timeout for the mouse-1-click mechanism should be increased
> to at least 2 seconds!

If my suspicion above is correct, this will make matters worse.

-- 
Ralf