10:57 p.m.
I have just installed xemacs 21.0-b67, and a sumo tarball dated 1999-03-12
on Solaris 1.5.1 (sparc) and RH GNU/Linux 5.2 (i686). Compilation,
installation, and start-up all went great.
On both platforms, after loading viper, I am told:
Symbol's function definition is void: vc-backend
whenever I try to save a file via:
ESC : [w|x] RET
I am able to save a file via:
C-x C-s
Also, when I `M-x gnus' on the GNU/Linux box (the Solaris box does not have
access to the mail spool), gnus 5.6.45 (included in the sumo tarball
mentioned above) and pgnus 0.83 (latest gnus beta from www.gnus.org), I am
told:
movemail: Permission denied for /var/spool/mail/Ea12407--see source file lib-src/
Ea12407 is not the name of the mail spool. I am unable to load gnus at this
point. I have not defined my own movemail program. gnus and pgnus work fine
in xemacs 20.4.
I don't know lisp, otherwise I would have hoped to included a patch as well.
Thanks,
Tom
--
Tom Vaughan <tvaughan at aventail dot com>
12:05 a.m.
I have just installed xemacs 21.0-b67, and a sumo tarball dated
1999-03-12
on Solaris 1.5.1 (sparc) and RH GNU/Linux 5.2 (i686). Compilation,
installation, and start-up all went great.
On both platforms, after loading viper, I am told:
Symbol's function definition is void: vc-backend
whenever I try to save a file via:
ESC : [w|x] RET
Viper requires some functions defined in vc-hooks.el
It seems that vc.el is not installed at your site.
(Probably a dependency on vc-hooks is missing in the viper package.)
--michael
7:18 p.m.
> Viper requires some functions defined in vc-hooks.el
Can this dependency be removed? It is a rather non-obvious
dependency, much like EFS requiring VM, and it would a be a good
thing if the linkage could be made to go away.
It needs to know whether a file is under version control.
For this, it uses vc-backend. I could never understand why vc-hooks.el is
such a bad thing to depend on.
--michael
3:13 a.m.
Michael Kifer writes:
> > Viper requires some functions defined in vc-hooks.el
>
> Can this dependency be removed? It is a rather non-obvious
> dependency, much like EFS requiring VM, and it would a be a good
> thing if the linkage could be made to go away.
It needs to know whether a file is under version control.
For this, it uses vc-backend. I could never understand why vc-hooks.el is
such a bad thing to depend on.
I think you can assume that if vc-backend is not a valid function
()vc-hooks not loaded), then for your purposes the file is not
under version control.
We don't load vc-hooks by default because VC is not universally
liked and once vc-hooks is loaded, you're pretty much stuck with
VC.
8:12 p.m.
>>>> "KJ" == Kyle Jones <of Mon, 03 May 1999
19:13:59 PDT> writes:
KJ> Michael Kifer writes:
>
>
> > > Viper requires some functions defined in vc-hooks.el
> >
> > Can this dependency be removed? It is a rather non-obvious
> > dependency, much like EFS requiring VM, and it would a be a good
> > thing if the linkage could be made to go away.
>
>
> It needs to know whether a file is under version control.
> For this, it uses vc-backend. I could never understand why vc-hooks.el is
> such a bad thing to depend on.
KJ> I think you can assume that if vc-backend is not a valid function
KJ> (vc-hooks not loaded), then for your purposes the file is not
KJ> under version control.
This assumes that the file being queried has been already visited (so vc
would be loaded). But sometimes viper queries the file even if it is not
loaded.
KJ> We don't load vc-hooks by default because VC is not universally
KJ> liked and once vc-hooks is loaded, you're pretty much stuck with
KJ> VC.
I heard this many times, but personally never experienced any problems. I
use both VC and pcl-cvs, and can't see where the two clash.
Are there any other problems?
--michael
3:17 a.m.
Michael Kifer writes:
>>>>> "KJ" == Kyle Jones <of Mon, 03 May
1999 19:13:59 PDT> writes:
KJ> Michael Kifer writes:
>>
>>
>> > > Viper requires some functions defined in vc-hooks.el
>> >
>> > Can this dependency be removed? It is a rather non-obvious
>> > dependency, much like EFS requiring VM, and it would a be a good
>> > thing if the linkage could be made to go away.
>>
>>
>> It needs to know whether a file is under version control.
>> For this, it uses vc-backend. I could never understand why vc-hooks.el is
>> such a bad thing to depend on.
KJ> I think you can assume that if vc-backend is not a valid function
KJ> (vc-hooks not loaded), then for your purposes the file is not
KJ> under version control.
This assumes that the file being queried has been already visited (so vc
would be loaded). But sometimes viper queries the file even if it is not
loaded.
Hmmm. How about using (featurep 'vc-hooks) before forcing the
load of VC? If (featurep 'vc-hooks) you can assume the user
has chosen to use VC.
KJ> We don't load vc-hooks by default because VC is not
universally
KJ> liked and once vc-hooks is loaded, you're pretty much stuck with
KJ> VC.
I heard this many times, but personally never experienced any problems. I
use both VC and pcl-cvs, and can't see where the two clash.
Are there any other problems?
I don't know (or care really) why some people don't like VC. I
remove package dependencies on general principle. Your package,
your call. If you don't want to change it, then we need to list
VC as a runtime dependency in the viper package spec, if such a
thing is possible.
8:17 p.m.
>>>> "KJ" == Kyle Jones <of Thu, 06 May 1999
19:17:16 PDT> writes:
KJ> I don't know (or care really) why some people don't like VC. I
KJ> remove package dependencies on general principle. Your package,
I think the real problem is that certain basic things that must be in the
X/Emacs API (like whether a file is under version control, which version
control syste is used, whether a file is local or remote, etc.) are
delegated to optional packages. This only leads to bloat and to problems
like the one I have with viper (and with ediff!).
--michael
11:57 p.m.
Michael Kifer writes:
>>>>> "KJ" == Kyle Jones <of Thu, 06 May
1999 19:17:16 PDT> writes:
KJ> I don't know (or care really) why some people don't like VC. I
KJ> remove package dependencies on general principle. Your package,
I think the real problem is that certain basic things that must be in the
X/Emacs API (like whether a file is under version control, which version
control syste is used, whether a file is local or remote, etc.) are
delegated to optional packages. This only leads to bloat and to problems
like the one I have with viper (and with ediff!).
We expected the a la carte distribution system we now use to
cause some problems. We believe the benefits outweigh the effort
involved to undo the package dependencies that were introduced
when XEmacs was shipped as a massive all-or-nothing lump. The feature
specific compile time options cause similar programming headaches.
12:25 a.m.
>>>> "KJ" == Kyle Jones <of Fri, 07 May 1999
15:57:48 PDT> writes:
KJ> Michael Kifer writes:
> >>>>> "KJ" == Kyle Jones <of Thu, 06
May 1999 19:17:16 PDT> writes:
>
KJ> I don't know (or care really) why some people don't like
VC. I
KJ> remove package dependencies on general principle. Your package,
>
>I think the real problem is that certain basic things that must be in the
> X/Emacs API (like whether a file is under version control, which version
> control syste is used, whether a file is local or remote, etc.) are
> delegated to optional packages. This only leads to bloat and to problems
> like the one I have with viper (and with ediff!).
KJ> We expected the a la carte distribution system we now use to
KJ> cause some problems. We believe the benefits outweigh the effort
KJ> involved to undo the package dependencies that were introduced
I agree that packaging is a good thing.
What I was pointing out above is that along with this there is a need to
create APIs for basic things that are general-purpose, but previously were
available only from specialized packages (which are now unbundled).
If such an API were available, removing package dependencies would have
been easier.
--michael
9334
days inactive
9341
days old
10 comments
4 participants
participants (4)
-
Charles G Waldman -
Kyle Jones -
Michael Kifer -
tvaughanï¼ aventail.com