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
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>>> Michael Sperber <sperber(a)deinprogramm.de> writes:
>
>> It is intentional, to some degree: A long time ago, people screamed
>> bloody murder at me when the startup paths didn't give configure'd
>> paths precedence over those determined at run time. startup.el is just
>> the first file that knows about those paths. So there's no good
>> solution here that will make everybody happy, I'm afraid.
>
> But this happens while building the dump. What ever happens when you
> start your xemacs is another thing I think. Couldn't this behavior be
> controlled some how so that when building the dump we don't do this?
It could be done. My point is that, at least once upon a time, there
were people who didn't do it to be the way you want it to be. They do
have a point in that the already complicated behavior gets more
complicated when it's different at dump time.
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
I have had a look at the *Help:-buffer and have spotted some
inconsistencies. It seems like left-click, middle-click, right-click
and return is used differently. How should we have it?
As it is now a referens to a variable sets an extent so that
left-click and middle-click goes to the Documentation. Hitting return
with the point in the extent does nothing. Finally, right-click will
bring up a context menu with alternatives to go to Documentation, the
source or Find tag.
On the other hand, the source code link after "-- loaded from", does
not set up a link for left-click. Here middle click and return
works. Right click does nothing special, but could have had a menu for
goto source.
Wouldn't it be more consistent to let left-, middle-click and return
do the same thing. Not that important but the context menu could
include something useful for all links as well.
Comments?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hello,
I've been using this for years, but never got to make it public until
recently. It's a very small and simple library for providing Unix-like
rc files to Emacs Lisp libraries.
All the details are here:
http://www.lrde.epita.fr/~didier/software/elisp/#el-rcfiles
and this is the commentary section, for quick reference:
;;; Commentary:
;; The purpose of el-rcfiles is to provide the equivalent of traditional
;; Unix rc files (i.e. configuration files) for Emacs Lisp
;; libraries. The advantages of using configuration files are the
;; following:
;; - your initialization file is less bloated,
;; - since configuration files are lazily loaded, your Emacs session
;; is (or begins) lighter. That is unless you already use lots of
;; EVAL-AFTER-LOAD forms...
;; Usage:
;; 1. Load the library, go to the rcfiles Custom group and tweak (or not).
;; 2. Put a call to (rcfiles-register-rc-files) in your initialization
;; file. This function can also be called interactively anytime you
;; add, remove or modify a configuration file.
;; 3. Put your configuration code for a library `foo' in a file called
;; `<rcfiles-directory>/foo<rcfiles-pseudo-extension>.el'.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Dear List,
Since GNU Emacs for w32 was compiled by Mingw, I just wondering if it is
possible for XEmacs for w32 also compiled with Mingw.
>From the source code and configure scripts I feel there's no support for
Mingw for XEmacs at this time.
Is it worth to try to compile a XE for window via Mingw?
Thanks,
FKtPp
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
A long time I asked about smtpmail, starttls and gmail
(http://lists.xemacs.org/pipermail/xemacs-beta/2011-March/020997.html).
I couldn't get to work and gave up.
So, I finally tried again, and it still failed to work for me, with
starttls-use-gnutls set to T. When I changed that to nil, it started
working for me, suddenly. Hurray! Of course, it's now on a different
system from before, but I don't care.
I wouldn't be writing this if there wasn't, of course, an issue.
What's happening is that the messag is sent, but the delete-process
near the very end of smtpmail-via-smtp generates an error about not
being able to delete the process. When I C-x e smtpmail-via-smtp,
everything works. Is there something special about delete-process in
byte-compiled code?
It's a bit annoying, but I can live without a byte-compiled smtpmail.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Fedora updated its texinfo to version 5.0, and then version 5.1, in
the not-so-distant past. The XEmacs package and the XEmacs packages
packages [1] promptly stopped building, due to errors thrown by
texinfo while processing our texinfo sources. The attached patch is
an emergency patch that I threw together for our packages, just to get
things building for Fedora again. I don't think it is entirely
correct. Package maintainers, if there is a part in here for one of
your packages, and it looks correct to you, please pull that part out
and commit it. If it doesn't look correct, please suggest how to fix
it. Thanks,
Footnotes:
[1] Don't you just love overloaded terms?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I've been dreading the autoconf work to select between two different
versions of GTK. I wonder how people would feel about dropping support for
GTK 2 and supporting GTK 3 only.
It's not like it's completely working anyway. I will ifdef the changes
making it possible to port back to GTK 2 if somebody really wanted to.
--
Jeff Sparkes
jsparkes(a)gmail.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi
I sometimes run into performance issues with large (LaTeX) buffers,
having font-lock mode[1] and x-symbol running[2]
I found narrowing always messy but I am thinking of give it a try.
Does anybody know whether it could (or should) improve performance?
thanks
Uwe Brauer
Footnotes:
[1] actually either lazy-lock or fast-lock
[2] I suspect that the culprit is x-symbol because turning it off
improves the performance.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta