Re: [SOLVED for GNU]

Re: [SOLVED for GNU]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]

>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

   > Uwe Brauer writes:

   >> So the issue are there any plans to port a recent GNU vc pkg to
   >> Xemacs?

   > Of course.  I think the last major sync was done in 2005 or so by
   > Ville Skyttä.  The problem is that there are few workers to do it,
   > and most of us seem to give other plans higher priority.


For example, in the GNU version,  vc-annotate is separated from the rest
of vc and has appropriate keybindings.

   > Note that Stefan Monnier thinks that GNU's vc.el needs a thorough
   > overhaul.

   >> >> "Uwe" == Uwe Brauer <oub@mat.ucm.es> writes:

   >> Thien-Thi Nguyen solved my problem with the following hack

   > I don't see anything hacky about using rlog.  It is the obvious way to
   > get the information.

That was Thien's wording not mine, I presume he thinks he did not use
the vc-annotate engine properly. 

   > Your requirements are hacky, in the sense that the previous revision
   > computed here is typically not the parent of the first revision on a
   > branch.  ("Typically" for all users.  I'm not saying this won't work
   > fine for you, but you should be aware of the gotcha.)  This
   > implementation assumes that once you branch, you close the old branch
   > to further development:

   > trunk  1.1 -- 1.2 -- 1.3 -- 1.4
   >                                \
   > branch 1                        2.1 -- 2.2
   >                                           \
   > branch 2                                   3.1 -- 3.2 -- ...

   > But it would fail to pick out parents if development could continue:

   > trunk  1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 -- ...
   >                                \
   > branch 1                        2.1 -- 2.2 -- 2.3 -- ...
   >                                           \
   > branch 2                                   3.1 -- 3.2 -- ...


That is right, once a branch is closed I never go back, I use this
approach for writing publications not for hacking.

   >> (defun vc-minor-part (rev)             ;part of GNU vc
   >> "Return the minor revision number of a revision number REV."
   >> (string-match "[0-9]+\\'" rev)
   >> (substring rev (match-beginning 0) (match-end 0)))
   >> 
   >> (defun vc-trunk-p (rev); part of GNU vc
   >> "Return t if REV is a revision on the trunk."
   >> (not (eq nil (string-match "\\`[0-9]+\\.[0-9]+\\'" rev))))

   > This looks incorrect, if 1.y is your trunk, and x.y for x > 1 are
   > branches.  In that case you should change the regexp to
   > "\\`1\\.[0-9]+\\'".

Well that is not part of the hack but part of GNU Emacs vc.el.
Just in case I put Thien and Emacs-devel in the CC, in case your comment
is relevant for the general case.

   >> (defalias 'vc-rcs-minor-part 'vc-minor-part);23-24 compatibility 
   >> (defalias 'vc-rcs-trunk-p 'vc-trunk-p);23-24 compatibility 
   >> 
   >> (defun vc-rcs-previous-revision (file rev)
   >> "Return the revision number immediately preceding REV for FILE,
   >> or nil if there is no previous revision.  This default
   >> implementation works for MAJOR.MINOR-style revision numbers as
   >> used by RCS and CVS."

   > This is false for CVS.[1]  x.y (almost always 1.y) is a trunk version,
   > branch versions have an even number of components greater than 2.  RCS
   > doesn't encourage such a convention as far as I can tell.

Also CC to Emacs devel.

   >> His solution works with GNU emacs 23 and 24 but, however it does
   >> not work with xemacs

   > There's nothing in the implementation you posted that wouldn't work in
   > XEmacs AFAICS.  I suspect that XEmacs vc just doesn't find the new
   > function.  Try naming the function "vc-rcs-previous-version" instead
   > and see if XEmacs calls it properly.

That is odd, I tried it several times and got an error about number of
arguments, however now it *works*. I keep and eye on that.

Thanks all of you for your help, but I presume this function will not be
included in any official vc version?


Uwe 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: [SOLVED for GNU]

[Stephen J. Turnbull]

Removing Thi from the CC list; he'll see it on emacs-devel.

Uwe Brauer writes:

 >    > This looks incorrect, if 1.y is your trunk, and x.y for x > 1 are
 >    > branches.  In that case you should change the regexp to
 >    > "\\`1\\.[0-9]+\\'".
 > 
 > Well that is not part of the hack but part of GNU Emacs vc.el.
 > Just in case I put Thien and Emacs-devel in the CC, in case your comment
 > is relevant for the general case.

No, it's not.

I'm not sure what the general case looks like for RCS (or even if
there is one, any more -- I'm sure there are a lot of people who still
use RCS for one reason or another but I bet they have a million
different conventions for version numbering).

 >    > There's nothing in the implementation you posted that wouldn't work in
 >    > XEmacs AFAICS.  I suspect that XEmacs vc just doesn't find the new
 >    > function.  Try naming the function "vc-rcs-previous-version" instead
 >    > and see if XEmacs calls it properly.
 > 
 > That is odd, I tried it several times and got an error about number of
 > arguments, however now it *works*. I keep and eye on that.

Good.  It doesn't really surprise me that it took a few tries.
Because of the way that vc.el manages its various engines, you might
have to switch to another one then back to RCS, or kill a buffer and
reread the file, or ..., to get the new function insinuated.

Let us know if it decides to fail again.

 > Thanks all of you for your help, but I presume this function will not be
 > included in any official vc version?

I don't see why not.  Although the difference between "parent" and
"head of previous branch" is important, since RCS doesn't know about
parents as far as I can see, "head of previous branch" seems like a
good approximation.

Emacs may have a different opinion, of course.

problem with create-image (was: [SOLVED for GNU])

[Uwe Brauer]

[-- Attachment #1.1: Type: text/plain, Size: 932 bytes --]

>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

   > Removing Thi from the CC list; he'll see it on emacs-devel.
   > Uwe Brauer writes:

That is only remotely connected to the original problem. When I try to
open Thien message on emacs-devel, using  "Ma Gnus v0.6"
I obtain an error: void-function create-image.
I attach the bug trace, can somebody have a look at this message please?


In fact it seems that xemacs does not have such a function, but on the
other hand, x-symbol has a call 
 (create-image x-symbol-image-convert-colormap
				x-symbol-image-colormap-allocation)


I greped the xemacs-package lisp directory for other create-image calls
and there are some. So I am confused, what do I miss?

Is this supposed to be a built-in function and I forgot to compile it
in?[1]


Thanks 

Uwe Brauer 

Footnotes:
[1]  in Ubuntus 21.4.22 xemacs there is also no such function.


[-- Attachment #1.2: image-bug --]
[-- Type: application/octet-stream, Size: 3031 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]