emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VC acting strangely


From: Dan Nicolaescu
Subject: Re: VC acting strangely
Date: Sat, 04 Aug 2007 08:22:10 -0700

David Kastrup <address@hidden> writes:

  > David Kastrup <address@hidden> writes:
  > 
  > > Jason Rumney <address@hidden> writes:
  > >
  > >> Dan Nicolaescu wrote:
  > >>> `vc-revert-buffer' seem to have been renamed to `vc-revert' in vc.el
  > >>> version 1.434
  > >>> ldefs-boot.el needs to be updated...
  > >>>   
  > >>
  > >> As a user command, I'd say it needs renaming back, or at least an alias
  > >> defined for it.
  > >
  > > Agreed.
  > 
  > Actually, I think it needs to get renamed back.  There are vc-*
  > subsystems maintained outside of Emacs, and those will stop working
  > when their hook functions get called under a different name.

The vc backends maintained outside emacs already have problems with vc
in CVS HEAD: a few vc functions have been changed to take a list of
files as the first parameter instead of a single file.

For the external vc backends: the ones for free systems have time to
get in emacs until emacs-23 is released, the other ones, they'll have
to be adjusted anyway...

IMO the change is good, the other vc interactive commands don't have a
-buffer suffix, so this makes vc more consistent. 

So, IMO adding an alias is the best solution here.

  > As an example, there is vc-git.el.  It is also distributed in git's
  > contrib directory for the sake of users of older Emacsen and XEmacs,
  > and keeping it compatible would become more of a nuisance.  Basically,
  > it would necessitate putting an alias into vc-git.el as well as
  > upstream vc.

Alexandre Julliard, the vc-git author, said this (before vc-git was
added to the 22.2 branch): "If vc-git gets merged into the Emacs 22
branch then I'll remove it from git.git, otherwise I'll probably leave
it around for people who don't want to use Emacs from CVS."  
So I wouldn't worry about vc-git.



  > Unless there is a really pressing reason to keep the renamed function,
  > I think we should really revert here.
  > 
  > -- 
  > David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]