ediff in RCS

ediff in RCS

[Hadron]

I have downloaded to my lisp path the following

vc+.el  vc-.el  vc-ediff.el  vc-hooks+.el

(I can find no documentation on them or installation guides but ran
across them from the emacs wiki)

I have added

(require 'vc-hooks+)

to my init files.

Now ediff (as opposed to diff) comes up from "C-x v =" (C-x v = runs the
command vc-ediff) but other keys now dont work e.g

,----
| vc-register: Symbol's function definition is void: vc-admin
| Symbol's function definition is void: vc-admin
`----

Has anyone used this stuff? Is there a full "package" of all related
files somewhere? It's like some giant jigsaw at the moment :-;

Any help appreciated.

RE: ediff in RCS

[Drew Adams]

> I have downloaded to my lisp path the following
>
> vc+.el  vc-.el  vc-ediff.el  vc-hooks+.el
>
> (I can find no documentation on them or installation guides but ran
> across them from the emacs wiki)
>
> I have added
>
> (require 'vc-hooks+)
>
> to my init files.
>
> Now ediff (as opposed to diff) comes up from "C-x v =" (C-x v = runs the
> command vc-ediff) but other keys now dont work e.g
>
> ,----
> | vc-register: Symbol's function definition is void: vc-admin
> | Symbol's function definition is void: vc-admin
> `----
>
> Has anyone used this stuff? Is there a full "package" of all related
> files somewhere? It's like some giant jigsaw at the moment :-;

This is my fault ;-).

I wrote vc-.el, vc+.el, and vc-hooks+.el long, long ago. I doubt that they
work well or even work at all with recent Emacs versions. I leave the code
on the wiki in case it helps someone, but there are no guarantees associated
with it.

If I were you, I would try doing whatever you need to do without using those
libraries. If you cannot do what you need, and if you see something in those
libraries that looks like it might help, then you can try to adapt it for
use with recent Emacs versions. Again, no guarantees of anything.

Re: ediff in RCS

[Hadron]

"Drew Adams" <drew.adams@oracle.com> writes:

>> I have downloaded to my lisp path the following
>>
>> vc+.el  vc-.el  vc-ediff.el  vc-hooks+.el
>>
>> (I can find no documentation on them or installation guides but ran
>> across them from the emacs wiki)
>>
>> I have added
>>
>> (require 'vc-hooks+)
>>
>> to my init files.
>>
>> Now ediff (as opposed to diff) comes up from "C-x v =" (C-x v = runs the
>> command vc-ediff) but other keys now dont work e.g
>>
>> ,----
>> | vc-register: Symbol's function definition is void: vc-admin
>> | Symbol's function definition is void: vc-admin
>> `----
>>
>> Has anyone used this stuff? Is there a full "package" of all related
>> files somewhere? It's like some giant jigsaw at the moment :-;
>
> This is my fault ;-).
>
> I wrote vc-.el, vc+.el, and vc-hooks+.el long, long ago. I doubt that they
> work well or even work at all with recent Emacs versions. I leave the code
> on the wiki in case it helps someone, but there are no guarantees associated
> with it.

Thanks for the prompt reply.

Possibly a good idea to comment them as such? The copyright indicates
2007 so I assumed the code was maintained and working :(

>
> If I were you, I would try doing whatever you need to do without using those
> libraries. If you cannot do what you need, and if you see something in those
> libraries that looks like it might help, then you can try to adapt it for
> use with recent Emacs versions. Again, no guarantees of anything.

I'm not a lisp programmer.

I did find this:

http://xemacs.seanm.ca/lisp/vc-ediff.el

RE: ediff in RCS

[Drew Adams]

> Possibly a good idea to comment them as such?

Yes, perhaps. But I have no idea that there are any problems (though your
report might be related). I haven't used change control much since I started
using Windows ;-). I just haven't felt like installing it.

> The copyright indicates
> 2007 so I assumed the code was maintained and working :(

Bad assumption.

Even a recent change-log entry (though there are none in these files)
wouldn't necessarily mean that the library was working on that log date. The
change could just be something as simple as updating the address of the FSF
in the free-software declaration. Checking for a recent change-log entry and
reading what it says can help, but again, there are no guarantees.

Sorry for any inconvenience.

Re: ediff in RCS

[Hadron]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Possibly a good idea to comment them as such?
>
> Yes, perhaps. But I have no idea that there are any problems (though your
> report might be related). I haven't used change control much since I started
> using Windows ;-). I just haven't felt like installing it.
>
>> The copyright indicates
>> 2007 so I assumed the code was maintained and working :(
>
> Bad assumption.

Yup - I wasted a lot of time.

Easy way to address it of course and take "assumption" out of the
equation is to just add a "old and not maintained and unlikely to work"
comment :-;

>
> Even a recent change-log entry (though there are none in these files)
> wouldn't necessarily mean that the library was working on that log date. The
> change could just be something as simple as updating the address of the FSF
> in the free-software declaration. Checking for a recent change-log entry and
> reading what it says can help, but again, there are no guarantees.
>
> Sorry for any inconvenience.
>

No worries - it was educational.

-- 

Re: ediff in RCS

[don provan]

"Drew Adams" <drew.adams@oracle.com> writes:

>> The copyright indicates
>> 2007 so I assumed the code was maintained and working :(
>
> Bad assumption.

Are you suggesting it's reasonable for the year to be updated in the
copyright notice of code that has not been changed in years?
-don

Re: ediff in RCS

[Andreas Röhler]

Am Montag, 18. Juni 2007 11:00 schrieb Hadron:
> "Drew Adams" <drew.adams@oracle.com> writes:
> >> Possibly a good idea to comment them as such?
> >
> > Yes, perhaps. But I have no idea that there are any problems (though your
> > report might be related). I haven't used change control much since I
> > started using Windows ;-). I just haven't felt like installing it.
> >
> >> The copyright indicates
> >> 2007 so I assumed the code was maintained and working :(
> >
> > Bad assumption.
>
> Yup - I wasted a lot of time.
>

Hi Drew and all,

as that kind of bugs happens with
third-party-programs, not just with yours, much more often than with
core-emacs-files:

What about to have a joined repository for
third-party-stuff in a VC-system. Maybe Git, SVN,
whatever. Together with a joined discussion of bugs as
it takes place with the core-files?

The wiki is not bad, but not as suitable for developing
as a VC-System - no checkout of versions etc.

This pertains too for repositories as emacs-lisp-list,
Tom Tromeys ELPA and probably other collections I
ignore.

The problem seems in so far serious, as core-emacs can't
grow eternal bigger and bigger. Rather I conceive a
future, were independent packages are loaded as needed
into a quick and stable core.

Today already you may run into serious trouble, if your
work depends on third-party-stuff, which for some
reasons is no longer or not properly maintained (the
latter is more or less inevitable with one-person-acts,
as we all are making errors every day).

At the other side the vast amount of third-party-stuff
is very important and part of the strength
of Emacs itself.

So far 

Andreas Roehler

Re: ediff in RCS

[Tom Tromey]

>>>>> "Andreas" == Andreas Röhler <andreas.roehler@online.de> writes:

Andreas> What about to have a joined repository for
Andreas> third-party-stuff in a VC-system. Maybe Git, SVN,
Andreas> whatever. Together with a joined discussion of bugs as
Andreas> it takes place with the core-files?

Andreas> This pertains too for repositories as emacs-lisp-list,
Andreas> Tom Tromeys ELPA and probably other collections I
Andreas> ignore.

FWIW I wasn't planning to set up any sort of version control system
for ELPA.  I do want to move it to a hosting service like savannah
eventually, so that other people can help maintain it.  I don't have a
firm plan for when this will happen, I suppose whenever ELPA seems
"popular enough".  Anyway, source control seems like a bit too much
process for this, at least right now.

Andreas> The problem seems in so far serious, as core-emacs can't
Andreas> grow eternal bigger and bigger. Rather I conceive a
Andreas> future, were independent packages are loaded as needed
Andreas> into a quick and stable core.

Andreas> Today already you may run into serious trouble, if your
Andreas> work depends on third-party-stuff, which for some
Andreas> reasons is no longer or not properly maintained (the
Andreas> latter is more or less inevitable with one-person-acts,
Andreas> as we all are making errors every day).

Andreas> At the other side the vast amount of third-party-stuff
Andreas> is very important and part of the strength
Andreas> of Emacs itself.

FWIW I don't mind having a maximal Emacs including everything -- I
rather like it, actually.  But at the same time Emacs has a very long
and irregular release cycle, and some sub-packages may benefit from
decoupling a bit.

As for maintaining dependencies -- ELPA can only help with the
mechanics of this.  If a package becomes unmaintained, or forks into
incompatible versions, that is not really something ELPA is intended
to solve.  There are other ways to solve this though: get code into
Emacs, or have a way to hand off maintainership from one person to the
next to ensure package integrity.

Tom