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've been working on TLS support for a little while, and now have what
seems to be working nss, openssl, and gnutls lstream implementations.
The next challenge is making those available via the Emacs interface,
since that is what consuming packages expect. I thought I'd give you
a snapshot of what I've done so far (attached), just in case I get
abducted by aliens who need some operating system work done.
If you see anything that seems wrong or wrong-headed, let me know.
It's still early enough to change direction if I'm doing something
gratuitously stupid.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
New machine, trying 64-bit cygwin, but no joy so far in compiling from
latest sources.
Too soon to say if I've just not got my environment right yet - so at
this point just checking -- has anyone made this work yet?
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I use cc-mode's electric behavior, which is great, except that whenever I
type a '}' as the last character in a buffer, I get something like this:
(1) (change/warning) Error in `after-change-functions': (args-out-of-range
(foo.c 99 100))
Backtrace follows:
# bind (inhibit-quit)
put-text-property(99 100 font-lock-pending t)
# bind (old-len end beg)
ad-Orig-font-lock-after-change-function(99 100 1)
(setq ad-return-value (ad-Orig-font-lock-after-change-function beg end
old-len))
# bind (ad-return-value)
(let (ad-return-value) (when c-buffer-is-cc-mode (save-excursion (setq
end c-new-END) (setq beg c-new-BEG))) (setq ad-return-value
(ad-Orig-font-lock-after-change-function beg end old-len)) ad-return-value)
# bind (old-len end beg)
font-lock-after-change-function(99 99 1)
# (unwind-protect ...)
# bind (old-len end beg)
lazy-lock-after-change(99 99 1)
# (unwind-protect ...)
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0x0> ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
delete-char(-1)
byte-code("..." [start delete-char -1] 2)
# bind (c-syntactic-context c-macro-start c-fix-backslashes has-backslash
insert-backslash start col newline-arg)
c-newline-and-indent()
# bind (c-echo-syntactic-information-p newlines ln-syntax br-syntax
syntax old-blink-paren safepos literal blink-paren-function
case-fold-search arg)
c-electric-brace(nil)
# bind (command-debug-status)
call-interactively(c-electric-brace)
# (condition-case ... . error)
# (catch top-level ...)
The immediate problem is that the original font-lock-after-change-function
is called with begin and end arguments equal to 99 and 100, even though 99
is the last valid position in the buffer. We can see that the adviced
font-lock-after-change-function got called with 99 and 99, which is
correct, so the problem is that the adviced function is screwing up the end
argument somehow. The adviced function looks like this:
(defadvice font-lock-after-change-function (before get-awk-region activate)
;; Make sure that any string/regexp is completely font-locked.
(when c-buffer-is-cc-mode
(save-excursion
(ad-set-arg 1 c-new-END) ; end
(ad-set-arg 0 c-new-BEG))))) ; beg
Therefore, c-new-END is wrong. Why? The value of after-change-functions
is (lazy-lock-after-change c-after-change t) in the C buffer. There's the
problem. We need c-after-change to run first, to update the caches, then
lazy-lock-after-change can run on the updated region.
So the bug is in, I think, xemacs-packages/edit-utils/lazy-lock.el, which
does this:
(add-hook 'after-change-functions 'lazy-lock-after-change nil t)
when I think it should be doing this:
(add-hook 'after-change-functions 'lazy-lock-after-change t t)
Opinions?
--
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 had minor redisplay issues for a very long time where sometimes
when I C-v parts of the old line are displayed instead of the
new. This was fairly rare.
However, in the last couple of months, this has become much
worse. C-v around a large file ends up with incorrect lines being
displayed. I haven't really changed anything on my end, but I have
updated xemacs to the most recent code along with various updates to
the packages.
Haven't come up with a repeatable test case and perhaps it's related
to my fonts[1] or syntax highlighting[2]. But whatever, it's much worse
than before and is now causing me to mis-edit somethings because what
I see isn't what is actually there. Pressing C-l usually fixes this,
fortunately.
--
Ray
Footnotes:
[1] I reported this before, but on startup the window is big and I
change my font in my xemacs to BitStream Vera Sans. The window
shrinks in size. I click on the window and it suddenly gets wider
but not everything is wider. XEmacs still thinks the window is
not that wide. When I manually drag the right window edge,
everything is resized correctly and things are working with the
correct window size now.
[2] Sometimes if I wait a bit, xemacs will redraw parts of the screen
with the correct lines.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2014-08-19 - 2014-08-26)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
558 open ( +0) / 311 closed ( +0) / 869 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1863 days.
Median duration of open issues: 1999 days.
Open Issues Breakdown
new 247 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 147 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 16 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
See https://bugzilla.redhat.com/show_bug.cgi?id=1122157.
In byte-compile-insert-header, we add a comment like this to .elc files:
;;; compiled by alfred.e.neumann(a)notentirelysane.com on Fri Mar 28 13:09:15
2014
;;; from file /home/alfred/Projects/xemacs/xemacs-21.5/lisp/font-mgr.el
;;; emacs version 21.5 (beta34) "kale" 8ef8d5e7c920+ XEmacs Lucid.
;;; bytecomp version 2.28 XEmacs; 2009-08-09.
;;; optimization is on
The issue is that first line, which identifies who did the building and
when. If that one line is eliminated, then multiple distribution builds
can produce identical .elc files, which is desirable for several reasons
(e.g., checking that builds on different architectures produce the same
results).
Would anyone object to removing that first line? The second line would be
altered to add the word "compiled" to the front; i.e., the example above
would become:
;;; compiled from file
/home/alfred/Projects/xemacs/xemacs-21.5/lisp/font-mgr.el
;;; emacs version 21.5 (beta34) "kale" 8ef8d5e7c920+ XEmacs Lucid.
;;; bytecomp version 2.28 XEmacs; 2009-08-09.
;;; optimization is on
Regards,
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2014-08-12 - 2014-08-19)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
558 open ( +0) / 311 closed ( +0) / 869 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1856 days.
Median duration of open issues: 1992 days.
Open Issues Breakdown
new 247 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 147 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 16 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
> Hi Uwe,
> 2014-08-13 11:11 GMT+02:00 Uwe Brauer <oub(a)mat.ucm.es>:
> If there is "\usepackage[german]{babel}" in the preamble, pressing the
> " key twice gives me "`foo"', which in the output becomes „foo“, is
> this what you want? You can customize `TeX-quote-language-alist' to
> get the same result by pressing " only once.
It did not work for me but I found the culprit.
I had iso-accents-mode on but not used (iso-accents-customize "german")
in this configuration
Typing "" gives ¨
So either turn it off and only use quail, german-pre or
use (iso-accents-customize "german")
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta