[issue488] Re: VC submenu under Tools

[Ville Skyttä]

On Monday 02 March 2009, you wrote:
> Rodney Sparapani wrote:
> > Ville Skyttä wrote:

> >>> I think this says that (process-mark p) does not return a valid marker.
> >>> The definition of vc-exec-after is on line 943 of vc.el
> >>> and (process-mark p) is on line 962 inside that function.
> >>> Oh... and by the way, commenting out that line fixes the bug!!!
> >>
> >> Hm, I can't reproduce with XEmacs 21.5.28.  Which version of XEmacs do
> >> you have?  Replacing the line with
> >>
> >>    (ignore-errors (goto-char (process-mark p)))
> >>
> >> rather than commenting it out could be somewhat better, but that
> >> probably isn't a very good thing to do either - I suppose there's a real
> >> issue somewhere needing a proper fix.  Could you try the above out
> >> anyway?  And of course, help from anyone with finding/fixing the real
> >> problem is much appreciated.
> >
> > Although I contribute to the xemacs-beta mailing list, I almost always
> > use the latest stable release.  In all the "excitement", I lost my head!

Hmm, do I understand correctly that this means that you're using XEmacs 
21.4.x?

> >   Anyways, that works.  And now I'm getting these lines which I don't
> > remember seeing before.  Could it be these are the real culprits (the
> > last 2 especially)?
> >
> > While compiling vc-buffer-context:
> >    ** variable mark-active bound but not referenced
> > While compiling vc-next-action-on-file:
> >    ** reference to free variable find-file-literally
> > While compiling vc-next-action-dired:
> >    ** evaluating (< nil 0): (wrong-type-argument number-char-or-marker-p
> > nil)
> >    ** evaluating (= nil 0): (wrong-type-argument number-char-or-marker-p
> > nil)
>
> Oops.  The issue tag got dropped.  This is issue 488, so we need to keep
> that in the thread or as Stephen pointed out, this will create a new
> issue for each email.  Finally, I do believe those last 2 warnings are
> saying that the marker is nil which is not a good
> thing.

These come from compiling vc-next-action-dired so I suppose they have nothing 
to do with the issue at hand.  And besides I believe they are in a code path 
that will not be executed as the 2nd arg to dired-map-over-marks is nil and 
that's AFAICT checked in dired before the < or = comparisons occur.

BTW, I just tried using vc+dired integration for the first time and either I 
don't understand how it works (which is quite likely as I've never really 
used dired either) or it's quite broken; I get "dired-subdir-alist seems to 
be mangled" when I try to do something in a vc-dired-mode buffer.