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
I had a need to run something on my Windows machine today which
required a newer version of Cygwin than the ancient one that was
installed there. After I upgraded to the current version (1.7.9) I
can't start a shell in XEmacs (via M-X shell) using Cygwin's version of
bash. When I try to do so I get
Process bash.exe exited abnormally with code 35584
3 [sig] bash 1168 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
1556 [sig] bash 1168 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
The stack dump is uninteresting except that the crash happens at offset
0x169220 in cygwin1.dll. It appears that this crash happens very early
on, before it's read /etc/profile. I see that I also have similar
stack dumps from other programs (find.exe and xargs.exe) in the XEmacs
directory all exactly the same.
I installed the latest Windows version of XEmacs from the installer at
<http://ftp.xemacs.org/pub/xemacs/binaries/win32/InnoSetup/XEmacs_Setup_21...>
and tried starting it with --vanilla. This didn't make any difference.
I also did a clean install of Cygwin 1.7.9 in case there was any crud
left around from the old version. This also didn't help. I'm running
on an old Dell with Windows XP Professional SP3. Perhaps that's the
problem. I probably should install Windows on my Mac under one of the
emulators, but that's more than I want to get into right now.
I've Googled around a bit and although others have seen this problem,
none of the solutions (mostly involving changing ownership of Cygwin
files and running rebaseall) did any good. The bash shell runs fine
when I start it using the .bat file installed by Cygwin, so it's
basically working, but it won't run in an XEmacs shell window.
Has anyone else seen this or know how to fix it? This little episode
reminds me why I avoid using Windows, but sometimes it's necessary.
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I understand the need for updated packages that help people work in
different ways.
There are also things within XEmacs that need updating. I have 2 things
that poke at me when I am working within XEmacs.
First is that some features are in the documentation, but do not
actually exist when you go to program them.
An example is in dialogs, that only 1 of 4 types of dialog boxes that
are in the documentation actually exist in code.
You can call the function name from your lisp code, and it says "not
implemented".
There are other examples of this too.
Second is that features that exist in the manuals and exist in the
program, but you cannot use them in code and submit it for inclusion in
XEmacs because that feature doesn't exist in the previous stable version
(21.4) (and never will).
An example is when I tried to implement a behavior, which is in the
manual, and the code is there--it works. But is not compatible with a
10 year old previous version.
There are other places where behaviors can be implemented to good
effect, in the menu system, that would solve some usability problems
that some users report, but they cannot be used at this time. An
example: it is a way to implement (and turn off) CUA provisions (a "new"
menu item, and similarly a "close" menu item for example), while keeping
the entire rest of the menu intact, so anyone who wants the CUA items
can turn on a behavior, and the rest can leave it off, and no harm done.
The real problem is no body or no thing, except the distribution cycle
has stretched to over 10 years old now, and it forces everybody to write
code (to be submitted to XEmacs) that doesn't use the new features of
21.5. If I recall correctly, behaviors existed 10 years ago, but still
cannot be used.
What obstacles are in the way of incrementing the version number of a
stable release so we can use new features?
Steve Mitchell
Forgive me if I have some terminology of version numbers or the number
of years wrong here, I think it has actually been 11 years since
behaviors were implemented, going by the date on the file.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
While doing an overhaul of the swedish translation of the GNU Emacs
Tutorial for the upcoming 24.1 release I spotted a thing that we don't
have but GNU Emacs has (introduced earlier than 24.1) and that is
recenter-top-bottom which is bound to C-l. It works like recenter
except that successive call place the point according to the cycling
order defined by `recenter-positions' (default being middle top
bottom)
What do you say? Should we get it? And if we do then shall we bind it
to C-l as default?
I tried to sync and the basic functionality is easy to get in
place. However that code revealed further differences. GNU Emacs has
the property "scroll-margin". When cursor gets within scroll-margin
number of lines from the top or bottom of the window will be
recentered. Interesting for us?
GNU Emacs also have the feature header-line. A line similar to
mode-line except at the top of the window. Example Info-mode creates
one for the navigation links Prev, Up etc. Should we introduce that
to?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi all,
Is there interest having XEmacs participate in GSoC next year?
The last time this question came up, there was no real interest in
mentoring from the reviewers. This time I'm willing to serve as a
mentor or co-mentor having some experience as a co-mentor for Mailman.
Of course we need students. If anybody *is* a student, or has an
affiliation with an academic organization where likely candidates
could be recruited, please feel free to let me know.
There is some preparation we need to do at some point, in particular
we need to set up to receive funds from Google. In theory we could
incorporate as an NPO, but it's probably a better idea to affiliate
with an existing umbrella organization, such as Software in the Public
Interest, the Software Freedom Conservancy, or the Apache Software
Foundation.
Apparently this kind of thing can be done in a couple of months, since
there was just an announcement on the GSoC Mentors list for *this*
year's payments. But I figured I might as well mention it since it's
on my mind, and applications for next year's mentoring organizations
will catch us by surprise if we ignore it for the next few months.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe Brauer writes:
> However as far as know org-mode < vs 7 works well with
> Xemacs 21.4.X but only 21.5.X works with org-mode >vs
> 7.
This is the kind of issue that is indeed a problem for *upgrades*.
For a new package it shouldn't be a show-stopper as long as the
package is properly protected (eg, it errors when you try to load it
in 21.4 -- but this is not necessarily trivial if some other package
which requires it would break).
It would, however, be nice to provide some org-mode support for 21.4.
There are several plausible strategies.
If org-mode 8 actually works in XEmacs 21.4, but a few new commands
don't, we could simply add an org-old-xemacs.el file that is
conditionally required by loading org-mode, if XEmacs is too old.
This file would then advise those commands to throw an unimplemented
error.
If org-mode 8 generally depends on internal functions that don't work in
XEmacs 21.4, there are several options. Reimplement them compatibly
with XEmacs 21.4, implement the necessary APIs in Lisp in a separate
library, or provide a separate org-mode-7 package for use with XEmacs
21.4.
> That is why I don't know whether it makes really sense to
> provide orgmode as a xemacs pkg.
Please don't misunderstand. The "must work in stable" rule is not
intended to keep us from making progress. It's intended to prevent
regressions where a package that used to work in the stable XEmacs
breaks even though the user is using the same XEmacs they did before.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I hope you don't mind me redirecting this to the list.
Mats Lidell writes:
> Hi Stephen,
>
> >>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
>
> > I disagree, but ... revisit us around Christmas. We'll see.
>
> Are you just considering what half a year with GPLv3 or later
> possibility will bring or are you sitting on some information you are
> not sharing publicly?
I know that I want to get some work done on XEmacs this summer. More
on precisely what that means shortly, once I actually start committing
some time. I suppose some others will too. For example, I know
Aidan's busy with his professional work, but obviously he has enough
time to read the list and enough interest to thank Hans. I imagine he
still has a few Common Lisp itches to scratch.
Also, I don't expect to, say, "catch up to GNU" by then, I'm just
saying I hope the project will show visible progress and activity by
then.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hello,
All the talk of updating various packages: I'm trying to understand the
size of the tasks involved.
Does anybody have a list of packages that are current and which are
needing updated?
Also, what does updating a package mean?
Or maybe I should ask what is involved in updating a package?
Are we updating them to be the same as a similar emacs package or are we
updating them
by fixing known problems? or what?
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta