January 2012 - XEmacs-Beta - XEmacs Mailing List Archives

GPLv3|L8R -- Status report - ready for inspection? 7 years, 4 months

Mats Lidell

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

4 participants
3 comments

Crash running Cygwin bash shell under XEmacs 12 years, 1 month

Mike Alexander

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

5 participants
5 comments

GNU Emacs function recenter-top-bottom 12 years, 2 months

The XEmacs Package Smoketest

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

3 participants
8 comments

Debug on signal + X menubar == assertion failure 12 years, 4 months

Jerry James

I've got a freshly compiled XEmacs from mercurial head. If I evaluate this in *scratch*, I get the expected result: (truncate-string-to-width "j.\n\n" 40 nil nil t) "j. " If I select Options->Troubleshooting->Debug on Signal, then try to evaluate that again, I get this: Debugger entered--Lisp error: (args-out-of-range "j. " 4) byte-code("..." [last-idx last-column end-column ch idx column char-width str] 3) truncate-string-to-width("j.\n\n" 40 nil nil t) eval((truncate-string-to-width "j.\n\n" 40 nil nil t)) eval-interactive((truncate-string-to-width "j.\n\n" 40 nil nil t)) eval-last-sexp(t) #<compiled-function (from eval-print-last-sexp) nil "...(13)" [standard-output terpri eval-last-sexp t] 2 1409437 nil 0x8b6>() call-interactively(eval-print-last-sexp) (dispatch-event "[internal]") This is causing the following practical problem. With an X11 build and Debug on Signal active, clicking on the menubar causes an immediate crash due to an assertion failure. A little debugger work shows the following sequence. Inside of button_item_to_widget_value (src/gui-x.c), the default-menubar from lisp/menubar-items.el is evaluated, down to one of the calls to: (truncate-string-to-width (abbrev-string-to-be-defined nil) 40 nil nil t) The abbrev-string-to-be-defined call returns "j.\n\n" (which doesn't seem right; where did that come from?). Evaluating truncate-string-to-width triggers the args_out_of_range, thereby unwinding the stack up to the call_trapping_problems call in menu_item_descriptor_to_widget_value (menubar-x.c). Since retval is unbound, this function returns NULL, and therefore compute_menubar_data also returns NULL. This triggers the assert() in set_frame_menubar (menubar-x.c) just after the call to compute_menubar_data and *boom* goes XEmacs. -- Jerry James http://www.jamezone.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
2 comments

packages with binaries 12 years, 8 months

Julian Bradfield

I'm trying to update the VM package, and as this is my first ever interaction with the package system, it's a bit daunting. First question: what am I supposed to do with auxiliary programs (qp-decode, base64-decode etc) that VM likes to have? Since XEmacs has built-in base64 functions, I guess the base64 programs are superfluous anyway; and perhaps qp-*code are superfluous because any qp-encoded message part is likely to be small anyway. But if I did want them, what would I do with them? Secondly, is there a way to check out the package infrastructure without getting the whole of the package sources? (This is also my first interaction with Mercurial, since these days every project uses a different VCS...) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

5 participants
25 comments

Re: Bug: get-face-font: Xemacs21.5.29: org-preview-latex-fragment [7.5] 12 years, 8 months

Julian Bradfield

Uwe: > (if (featurep 'xemacs) >; (font-height (get-face-font 'default)) > (font-height (face-font 'default)) > (face-attribute 'default :height nil)) >and face-attribute is not known to be defined. Of course not. It's the code that's called when it's not XEmacs. If XEmacs had it, the conditional wouldn't be needed. That's not a problem. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

4 participants
14 comments

Re: [O] change call-process also for GNU emacs? (was: Solved) 12 years, 8 months

Nick Dokos

Uwe Brauer <oub(a)mat.ucm.es> wrote: > >> On Sat, 28 Jan 2012 19:13:57 -0500, Nick Dokos > >> <nicholas.dokos(a)hp.com> wrote: > > >> > > > ... and bonus points if you also fix the problems described in > > Now I am confused, from the link, you provided, I conclude > you are talking about GNU Emacs, however I only wanted my changes to > work with Xemacs and therefore wrap a > > (if (featurep 'xemacs) > > Around my changes. If you want to have the changes I have in > mind for call-process also for GNU Emacs, I think the > maintainers should have a say. > Actually, it might very well be that they are Xemacs problems as well, but you are right: I meant that since you'd be visiting the area, I might convince you to do some additional work and fix those bugs as well. Nick _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: [O] Solved 12 years, 8 months

Nick Dokos

Bastien <bzg(a)altern.org> wrote: > Hi Uwe, > > Uwe Brauer <oub(a)mat.ucm.es> writes: > > > So there are two small changes necessary to make > > org-preview-latex-fragment work in Xemacs. One is the above > > change, the other > > > > > > (font-height (face-font 'default)) > > instead of > > (font-height (get-face-font 'default)) > > > > I can send a patch against 7.8.03 > > Please do so -- but please make sure the patch adapts current code > to XEmacs without suppressing any feature for GNU Emacs. > > Thanks in advance! > ... and bonus points if you also fix the problems described in http://thread.gmane.org/gmane.emacs.orgmode/50584 :-) Nick _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Solved (was: Xemacs: org-preview-latex-fragment, png not readable.) 12 years, 8 months

Uwe Brauer

The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. >> On Sat, 28 Jan 2012 21:20:48 +0100, Uwe Brauer <oub(a)mat.ucm.es> wrote: > Which does not work for Xemacs. Thanks to Julian Bradfield, > the solution seems to be: > (defun org-dvipng-color (attr) > "Return an rgb color specification for dvipng." > (apply 'format "rgb %s %s %s" > (mapcar 'org-normalize-color > (color-rgb-components > (face-property 'default (intern (substring (symbol-name attr) 1))))))) > However the png which were generated where to small to be > readable. I attach one at the end of the message. The issue are the options in call-process "dvipng" nil nil nil After trying out different configurations, I found out that the option "-D" dpi Does not work well with Xemacs. So (call-process "dvipng" nil nil nil "-fg" fg "-bg" bg ;; "-D" dpi ;; "-x" scale "-y" scale "-T" "tight" "-o" pngfile dvifile) is ok, however the back and foreground setting as generated by org-dvipng-color, even with Julian Bradfield's patch do not produce very nice results. In my Xemacs setting it is better to comment them out. So there are two small changes necessary to make org-preview-latex-fragment work in Xemacs. One is the above change, the other (font-height (face-font 'default)) instead of (font-height (get-face-font 'default)) I can send a patch against 7.8.03 Uwe Brauer _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

Bug in recent Win32 snapshots 12 years, 8 months

Marcus Harnisch

Dear all, With the two recent XEmacs Win32 binaries, I experience strange behavior when exiting Gnus (a snapshot that claims to be "No Gnus v0.18"): At the end of #'gnus-clear-system, all Gnus buffers will be killed with #'gnus-kill-buffer. When it comes to killing my IMAP buffer (#<buffer "*nnimap imap.example.com nil *nntpd**">), XEmacs remains completely unresponsive and must be killed. The error could be traced down to #'kill-buffer but not further since I can't debug on my Win32 machine. I don't seem to be able to reproduce the issue on Linux. With the exact same start-up and package environment, an older Win32 binary works absolutely fine. These break: XEmacs-21.5-2012-01-17 "21.5 (beta31) \"ginger\" XEmacs Lucid" XEmacs-21.5-2011-11-28 "21.5 (beta31) \"ginger\" XEmacs Lucid" This one is OK: XEmacs-21.5-test-2010-09-21 "21.5 (beta29) \"garbanzo\" XEmacs Lucid" Thanks Marcus _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
2 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta January 2012