Hello everybody,
I tried to update my xemacs-21.5.11 tree to 21.5.12 with the diff file
found in ftp mirrors, but all attempts failed (patch said "patch: ****
malformed patch at line 315").
I tried to skip several parts of the diff file without success (the main
problem ends in the part of "configure", which could not be skipped).
Did anyone encoutered the same problem? Could it be possible to re-generate
the patch file?
\bye
S.
--
MAKING MILHOUSE CRY IS NOT A SCIENCE PROJECT.
MAKING MILHOUSE CRY IS NOT A SCIENCE PROJECT.
MAKING MILHOUSE CRY IS NOT A SCIENCE PROJECT.
-+- Bart Simpson on chalkboard, episode #213

Hi,
Here comes yet another status report from the project of converting to
GPLv3 or later.
There are two lists of files below. The first list contains all files
that are in an undecided state. Please inspect: Do we need to do anything
with them. If so what?
The second list contains all files that we can leave untouched and the
reason for that. Please inspect: Are all reasons OK and correct?
Are we getting close to the were an inspection of the xemacs-gplv3
repository could be performed? With the intent that it that is OK we
could merge back to trunk and go GPLv3 or later?
----------------------------------------------------------------------
"CHANGES-beta"
"ChangeLog"
"PROBLEMS"
"README"
"README.GPLv3"
"etc/ChangeLog"
"etc/Emacs.ad"
"etc/InstallGuide"
"etc/NEWS"
"etc/ONEWS"
"etc/OONEWS"
"etc/README"
"etc/editclient.sh"
"etc/emacskeys.sco"
"etc/emacsstrs.sco"
"etc/gtkrc"
"etc/package-index.LATEST.gpg"
"etc/sample.Xresources"
"etc/xemacs.1"
"lib-src/ChangeLog"
"lib-src/README"
"lisp/ChangeLog"
"lisp/README"
"lisp/mule/mule-locale.txt"
"man/ChangeLog"
"man/README"
"modules/ChangeLog"
"modules/base64/Makefile"
"modules/common/configure-post.ac"
"modules/common/configure-pre.ac"
"modules/zlib/Makefile"
"nt/ChangeLog"
"nt/Emacs.ad.h"
"nt/Installation.el"
"nt/README"
"nt/Win32.cf"
"nt/lisp.ico"
"nt/site.def"
"nt/xemacs.dsp"
"nt/xemacs.dsw"
"src/ChangeLog"
"src/README"
"src/README.kkcc"
"src/m/README"
"src/s/README"
"src/s/freebsd.h"
"src/s/irix6-0.h"
"src/s/netbsd.h"
"src/s/sol2.h"
"tests/ChangeLog"
"tests/Dnd/README"
"tests/automated/README"
"version.sh.in"
----------------------------------------------------------------------
These files below are the files that we might be able to leave as
they are. The reason for why they need not to be changed is listed
after each file: (Some reasons are taken verbatim from private
communication or the "GPL version 3 source survey")
----------------------------------------------------------------------
"INSTALL" -> old FSF Documentation license
"config.guess" -> Part of config which is still GPLv2 or later. See "http://savannah.gnu.org/projects/config"
"config.sub" -> Part of config which is still GPLv2 or later. See "http://savannah.gnu.org/projects/config"
"etc/ETAGS.ChangeLog" -> BSD and GPL v2 or later
"etc/VEGETABLES" -> Not copyrightable.
"etc/XKeysymDB" -> MIT
"etc/ctags.1" -> Part of the etags distribution, which is not part of XEmacs.
"etc/custom/example-themes/ex-custom-file" -> Generated(!?) or GPL V2 or later?
"etc/etags.1" -> Part of the etags distribution, which is not part of XEmacs.
"etc/gnuattach.1" -> simple man link to gnuserv.1
"etc/gnuclient.1" -> simple man link to gnuserv.1
"etc/gnudoit.1" -> simple man link to gnuserv.1
"etc/refcard.ps.gz" -> Generated from refcard..tex
"etc/sample.Xdefaults" -> It is deprecated, so it can be removed but is only a three line reference to .Xresources
"etc/xemacs-X.ico" -> GPLv2 or later but there is not meta data for the file where this can be documented.
"info/dir" -> Generated(?)
"install-sh" -> MIT-style "no advertising" license
"lib-src/b2m.c" -> This is the version from GNU Emacs, so should be OK.
"lib-src/config.values.in" -> Generated.
"lib-src/emacs.csh" -> I don't think this even works with XEmacs ("emacsclient"), so I believe we can just delete it.
"lib-src/insert-data-in-exec.c" -> Compatible license.
"lib-src/mmencode.c" -> Compatible license.
"lisp/dump-paths.el" -> Empty file. Not copyrightable.
"lisp/term/bobcat.el" -> Emacs version has no explicit license declaration
"lisp/term/vt102.el" -> Emacs version has no explicit license declaration
"lisp/term/vt125.el" -> Emacs version has no explicit license declaration
"lisp/term/vt200.el" -> Emacs version has no explicit license declaration
"lisp/term/vt201.el" -> Emacs version has no explicit license declaration
"lisp/term/vt220.el" -> Emacs version has no explicit license declaration
"lisp/term/vt240.el" -> Emacs version has no explicit license declaration
"lisp/term/vt300.el" -> Emacs version has no explicit license declaration
"lisp/term/vt320.el" -> Emacs version has no explicit license declaration
"lisp/term/vt400.el" -> Emacs version has no explicit license declaration
"lisp/term/vt420.el" -> Emacs version has no explicit license declaration
"lock/.precious" -> Not copyrightable.
"modules/canna/install-sh" -> MIT
"modules/ldap/install-sh" -> MIT
"modules/postgresql/install-sh" -> MIT
"modules/sample/external/install-sh" -> MIT
"modules/sample/internal/install-sh" -> MIT
"move-if-change" -> Identical to GPLv3 or later Emacs version
"nt/Xmd.patch" -> GPLv2 or later but only a few lines
"nt/file.ico" -> MIT
"nt/minitar.c" -> Public domain
"nt/paths.h" -> Generated
"nt/xemacs.ico" -> GPLv2 or later but there is not meta data for the file where this can be documented.
"src/alloca.c" -> Public domain.
"src/depend" -> Generated
"src/emacs-marshals.c" -> Generated.
"src/emacs-widget-accessors.c" -> Generated.
"src/intl-auto-encap-win32.c" -> Generated.
"src/intl-auto-encap-win32.h" -> Generated.
"src/libsst.c" -> Compatible license.
"src/libsst.h" -> Compatible license.
"src/libst.h" -> Compatible copyright.
"src/linuxplay.c" -> Compatible license. (MIT-like)
"src/miscplay.c" -> Compatible license. (MIT-like)
"src/miscplay.h" -> Compatible license. (MIT-like)
"src/nas.c" -> Compatible license. (MIT-like)
"src/paths.h.in" -> Generated.
"src/s/openbsd.h" -> Too short. (< 10 lines)
"src/s/usg5-4-2.h" -> Too short. (< 10 lines)
"src/sunplay.c" -> Compatible copyright.
"tests/gtk/UNIMPLEMENTED" -> Does notes need a license?
"tests/tooltalk/beeps.el" -> Too short. (< 10 lines)
----------------------------------------------------------------------
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

>>>>> "Paul" == Paul Krause <paulkrause1(a)mediaone.net> writes:
Paul> Adrian Aichner <adrian(a)xemacs.org> writes:
>> >> Do we want to make C-u M-x comment-region smarter?
>>
Paul> No! Make indentation smarter. If a comment begins in column
Paul> 1, don't
Paul> indent it when reindenting a region. This solves the
Paul> problem without
Paul> style-changes or hacks to comment-region.
>>
Paul> Have I overlooked anything?
>>
>> This, maybe?
>>
>> (Info-goto-node "(xemacs)Comments")
>>
>> Adrian
Paul> Could you be a little more specific? I don't what you're
Paul> referring to. Maybe this?
Paul> You can also use `Meta-;' to align an existing comment. If a line
Paul> already contains the string that starts comments, `M-;' just moves
Paul> point after it and re-indents it to the conventional place.
Paul> Exception:
Paul> comments starting in column 0 are not moved.
Yes, that, and also the following paragraph.
Some major modes have special rules for indenting certain kinds of
comments in certain contexts. For example, in Lisp code, comments which
start with two semicolons are indented as if they were lines of code,
instead of at the comment column. Comments which start with three
semicolons are supposed to start at the left margin. Emacs understands
these conventions by indenting a double-semicolon comment using TAB and
by not changing the indentation of a triple-semicolon comment at all.
You have a valid point, though.
single-; comments srarting in column 0 should not be moved and
comment-region would work as advertised!
You opened my eyes!
To All:
Isn't this what we should do?
Martin?
Stephen?
Best regards,
Adrian
Paul> The trouble is, it doesn't work as documented. Here's a sample.
Paul> ;;; header comment
Paul> ;; This function is just an example.
Paul> ;;; Here either two or three semicolons are appropriate.
Paul> (defun foo (x)
Paul> ;;; And now, the first part of the function:
Paul> (lambda (foo bar)
Paul> (if (foo bar)
Paul> 'bif
Paul> 'baz))
Paul> ;; The following line adds one.
Paul> (1+ x)) ; This line adds one.
Paul> ;; This function is just an example.
Paul> ;;; Here either two or three semicolons are appropriate.
Paul> (defun foo (x)
Paul> ;;; And now, the first part of the function:
Paul> ;; The following sexp is commented out using comment-region.
Paul> ; (lambda (foo bar)
Paul> ; (if (foo bar)
Paul> ; 'bif
Paul> ; 'baz))
Paul> ;; The following line adds one.
Paul> (1+ x)) ; This line adds one.
Paul> I get the same indentation using either M-; or C-M-q.
Paul> Testing using xemacs -vanilla on
Paul> XEmacs 21.2 (beta37) "Pan" (win32) of Sun Dec 03 2000 on PAULKRAUSE
Paul> as well as
Paul> XEmacs 21.0 "20 minutes to Nikko" (win32) of Fri Mar 26 1999 on
Paul> BLACKBIRD
Paul> (which I just happen to have lying around)
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/

Dear XEmacs Developers,
I recently got a large roundtuit dropped in my lap (my startup company
imploded), so I've spent a few days working on XEmacs native Windows
setup kits.
On Fri, Oct 31, 2014 at 8:45 PM, Biswajit Khandai <b_khandai(a)yahoo.com> wrote:
> I was assuming that the stable channel native windows binary will be built
> by "someone".... If that assumption is right, then the same "someone" could
> build the beta channel native windows binary. It may not be you,
> necessarily.
Your assumption is correct, but I am the only someone who builds these
kits. I will try to make a setup kit for every release, but it is
difficult for me to know how much time I will have for making setup
kits in between releases.
> However, if that assumption is wrong, I would like you to know that a heck
> of a lot of people use xemacs on Windows - maybe you underestimate the
> number of such people.
Dear Biswajit - thank you for your kind words. They certainly made me
feel like my efforts in this area have been well worthwhile.
I have re-made setup kits for 21.4.22, 21.5.34 and 21.4 latest and
21.5 latest. I will upload them this afternoon to ftp.xemacs.org.
I will be sending a small patch to XEmacs-patches to work around a
couple of difficulties building without TLS on native Windows. I have
not attempted to build with TLS as of yet.
- Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta

A couple weeks ago I used the Bitbucket web page to add a note to the
xemacs-beta README. I now see that I introduced a couple problems. :-(
1. The README file is actually stored in the repo, which means I
introduced a divergence between xemacs and xemacs-beta.
2. The Bitbucket editor added a carriage return at the end of all the
lines.
I guess the best way to fix this is to push a fixed README to xemacs,
and then whoever next promotes changesets to xemacs-beta can handle the
merge (just take the xemacs version)...?
Sorry 'bout this.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta