April 2011 - XEmacs-Beta - XEmacs Mailing List Archives

Jim Minton

Hi, Can someone please tell me where I can get a copy of xemacs for RH 6? Thanks. Jim Minton _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

4 participants
6 comments

Summary of XEmacs Issue Tracking System Issues 13 years, 7 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2011-03-29 - 2011-04-05) 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. 517 open ( +3) / 242 closed ( +0) / 759 total ( +3) Open issues with patches: 11 Average duration of open issues: 821 days. Median duration of open issues: 857 days. Open Issues Breakdown new 184 ( +2) deferred 6 ( +0) napping 4 ( +0) verified 52 ( +1) assigned 155 ( +0) committed 26 ( +0) documented 2 ( +0) done/needs work 24 ( +0) Issues Created Or Reopened (3) ______________________________ Mirror in Hamburg,Germany 2011-03-29 http://tracker.xemacs.org/XEmacs/its/issue759 created af_mirror XEmacs reports duplicate auto-autoloads at startup 2011-04-02 http://tracker.xemacs.org/XEmacs/its/issue760 created stephen xemacs 21.4.22 not starting correctly--half the window is blan 2011-04-05 http://tracker.xemacs.org/XEmacs/its/issue761 created stephen Issues Now Closed (2) _____________________ xemacs.org mirror in Hamburg,Germany 101 days http://tracker.xemacs.org/XEmacs/its/issue746 stephen Tracker search fails with indexing error 33 days http://tracker.xemacs.org/XEmacs/its/issue754 stephen Top Issues Most Discussed (1) _____________________________ 3 XEmacs reports duplicate auto-autoloads at startup 3 days verified http://tracker.xemacs.org/XEmacs/its/issue760 _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

redisplay crash problem 13 years, 7 months

Julian Bradfield

Once in a blue moon (really meaning once or twice a year), I get a crash in redisplay. This happens when redisplay_window is calling marker_position, and passing it a marker with a null buffer field. Unfortunately, more detailed information, such as which line in redisplay_window(), doesn't seem to survive the optimizing compiler (and I don't really want to run my everyday emacs unoptimized, even these days). I'm not aware of having touched anything in this area of code (my fork is off 21.4.22). It seems to happen only when I shut down a client window (I use an emacs-server based setup), but I have no idea what the key feature is, and I certainly can't reproduce it on demand. Has anybody ever seen anything like this in 21.4? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

xemacs not starting correctly--half the window is blank. 13 years, 7 months

steven Mitchell

Previously, I wrote: Hello, I am running Slackware64 13.1 and XEmacs 21.4.22. XEmacs was working just fine for months. I installed E17 as the window manager instead of KDE 4.6.0. All Xwindows apps work fine, but not XEmacs. Sigh. A window comes up, has my XEmacs coloring and menus, but the right side of the window is white, say 40% of screen width wide, and %100 high. What is cut off is not the title bar (with minimize, maximize, and close), but everything below it, the menu (no help button on right) all text area, status bar at the bottom, and right end of minibuffer is just white. I can take screenshots or a 10 second video to show this if someone wants me too. It is repeatable every time. Give me an email address and I can send them to you. ----------- My son and I worked with the problem and found out some things. We renamed init.el to prevent it's loading, and the problem remained the same. We renamed custom.el and problem went away. So I commented out lines in custom.el till the problem line showed up. Below is my entire custom.el; the line that was causing the problem is the line starting with '(default... which specifies 4 things: Font foreground color background color point size of font. After experimentation, changing the point size of the font to 18 or 19 or 22 makes the problem go away. Changing back to point size 20 after starting with any other point size and point size 20 works fine for this session. Courier, 20 point IS a valid choice on the menu: [options][font size], though 22 point is not but works anyway. Changing fonts did not change the problem. We tried running just (redisplay-frame) by itself and the screen was still 40% white As a workaround for now, I added the following to the bottom of my init.el the following 3 lines: (custom-set-faces '(default ((t (:foreground "yellow" :background "black" :size "19pt"))) t)) (redisplay-frame) (custom-set-faces '(default ((t (:foreground "yellow" :background "black" :size "20pt"))) t)) And now it starts normally. Which is really odd. Is this a bug? a setting I don't have right? Does anybody know this is not a problem in version 25 beta? A separate problem: I also found that I can grab any of the 4 corners or top and bottom or top edges and resize the XEmacs window in E17, but cannot grab the left or right side to resize the window. Wonder why? Do I need to figure out how to enlarge the borders a few pixels or something? Steve Mitchell contents of my custom.el: --------------------------------------------------------------------------------- (custom-set-variables '(buffers-tab-max-size 10) '(gutter-buffers-tab-visible-p t)) (custom-set-faces '(default ((t (:family "Courier" :foreground "yellow" :background "black":size "20pt"))) t) ;<----comment out this line, and problem goes away. '(about-link-face ((((class color) (background light)) (:foreground "blue":underline t)))) '(buffers-tab ((t (:foreground "Black" :background "red"))) t) '(custom-comment-face ((((class grayscale color) (background light)) (:background "gray20")))) '(custom-comment-tag-face ((((class color) (background light)) (:foreground "blue")))) '(font-lock-comment-face ((((class color) (background light)) (:foreground "light blue")))) '(font-lock-function-name-face ((((class color) (background light)) (:foreground "red2")))) '(font-lock-keyword-face ((((class color) (background light)) (:foreground "red2")))) '(font-lock-string-face ((((class color) (background light)) (:foreground "salmon")))) '(highlight ((t (:background "" :bold t))) t) '(hyper-apropos-hyperlink ((((class color) (background light)) (:foreground "blue")))) '(paren-match ((t (:background "black" :bold t))) t)) (setq minibuffer-max-depth nil) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

All auto-autoloads being loaded on startup after installing dvc. 13 years, 7 months

Raymond Toy

In my recent attempt to get dvc running with xemacs, it seems it messed something up. I built dvc (with some modifications to support xemacs) and tried to install it. The install went ok, but the result was the dvc didn't really work[1]. However, now every time I start xemacs, I get 100+ error messages stating that the auto-autoload for every package has already been loaded. If I start xemacs with -no-site-file and click on the Load Init Files button, I don't get these messages. How can If fix this? Ray [1] I built a newer version of dvc with some modifications. This works better now, but I didn't install it this time. It works fine running out of the build directory. Just want to get rid of the auto-autoloads errors. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

4 participants
23 comments

Re: [COMMIT] Use GC_EXTERNAL_LIST_LOOP_* where appropriate, fns.c 13 years, 7 months

Aidan Kehoe

Ar an ceathrú lá de mí Aibréan, scríobh Raymond Toy: > I can provide a full lisp and C backtrace now if you want it. I'm > going to poke around a bit later to see if there's anything obvious to > the untrained user. Please do, but use the Mercurial tip if you can, there was a problem with the version of the patch I posted. -- “Apart from the nine-banded armadillo, man is the only natural host of Mycobacterium leprae, although it can be grown in the footpads of mice.” -- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

Re: [COMMIT 21.5]: lisp/minibuf.el 13 years, 7 months

Aidan Kehoe

Ar an triú lá de mí Aibréan, scríobh Julian Bradfield: > I've been running with my change in 21.4 since then, and never had a > problem. > > Actually, the whole minibuffer thing is a bit of a festering > mess. There are three different definitions of the top-level > minibuffer: > (1) The buffer named "*Minibuf-0*" (or "*Minibuf-0" as the case may be) > (2) The buffer in Vminibuffer_zero These two are the same object (since #'kill-buffer refuses to kill the buffer stored in Vminibuffer_zero by reinit_complex_vars_of_minibuf(), which has the name " *Minibuf-0*", and since buffer names are unique). Neither is necessarily the top-level minibuffer if enable-recursive-minibuffers is non-nil. > (3) The buffer currently displaying in the active minibuffer window This will be the buffer " *Minibuf-0*" if enable-recursive-minibuffers is non-nil. > One really ought to go through and sort it all out, I guess. I don’t get the impression it’s *that* bad. But if you have a proposed change, shout. -- “Apart from the nine-banded armadillo, man is the only natural host of Mycobacterium leprae, although it can be grown in the footpads of mice.” -- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: [COMMIT 21.5]: lisp/minibuf.el 13 years, 7 months

Aidan Kehoe

Ar an dara lá de mí Aibréan, scríobh Vin Shelton: > This looks right to me and it's been applied to 21.5 - is there any > reason I shouldn't apply it to 21.4? There’s no reason not to apply it to 21.4, and thanks for applying the other patches just now! -- “Apart from the nine-banded armadillo, man is the only natural host of Mycobacterium leprae, although it can be grown in the footpads of mice.” -- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

New buildslave added to the buildbot - cygwin on Windows XP 13 years, 7 months

The XEmacs Package Smoketest

Hi, FYI, I have just added a buildslave building on cygwin on Windows XP. The cygwin setup is not complete so some of the builds fail but I will try to fix that next week. Here is the link to the buildslave: "http://www.lidell.nu/xemacs-buildbot/buildslaves/matsl-x86-cygwin" Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

A major change in direction 13 years, 7 months

Stephen J. Turnbull

To all XEmacs contributors, I've been discussing future improvements to python-mode with Barry Warsaw and Glyph Lefkowitz over the last few days. They decided that since Guido van Rossum also uses Emacs, we should pull him into the discussion. His reaction was very positive; he said he's sick of hearing complaints about Emacs support for Python development, and would very much like to see the Python community settle on one Emacs and one python-mode for the future. As usual, he came up with some radical ideas, but I think there's a touch of genius to them. Also, he has promised on the order of a half-dozen GSoC students to implement them. Therefore, effective immediately, the position of "Mr. XEmacs" is being furloughed, to be replaced by a "Benevolent Dictator for Two Years" (GvR himself), with the assistance of a "Friendly Language Uncle for Life" (Barry). All agreed that Dunnet, not to mention the eistring code, is sufficiently twisty that we don't need help from Glyph. GvR took a look at the allocator, and he strongly recommends replacing the current GCPRO scheme, which is tedious and error prone, with a reference counting collector. At the same time, it should be fairly easy to introduce threading on the Python model, by implementing a *nonlocal* interpreter lock, ie, NIL, which should avoid the problems of Python's GIL, the *global* interpreter lock. GvR is a little disappointed that our current implementation of NIL is a mere stub that always produces a false value, though. "After 60 years, *somebody* should have a proof-of-concept implementation!" he said. Once this is done, we can turn to the next important task, which is to replace our current non-standard Lisp language with something more readable (if even less standard), namely, a parenthesis-less interpreted stack-oriented parser, or P-Lisp. This approach was chosen because he expects it to be easy for us to pronounce, based on the historical usage, E-Lisp. Of course this will require introduction of syntactic whitespace, but this shouldn't be too hard, since we already have several whitespace modes. Of course, there remains one important problem, which is the existing base of Lisp code. The various modes cannot be ignored, so some kind of emulation of Lisp will be needed. However, attempting to emulate Lisp on top of P-Lisp running on the current byte-code engine is clearly inefficient. Again, a radical suggestion: replace it with Dalvik, which is a modern and very efficient VM. Hopefully, efficient enough to support "E-Lisp in P-Lisp" to run .els. Since XEmacs is already an OS, this will make it possible to use XEmacs as a drop-in replacement for Android. Although we don't expect rapid penetration into the non-developer market, it seems certain that "XEmacs phones" and tablet PCs will occupy a strategic niche among software developers, especially the burgeoning Python community. Experienced developers will realize that all code we have inherited from the FSF will be gone at this point, leaving only code by Zawinski and Wing. Guido suggests that we can probably get more contributions with an appropriate Pythonic license; no need to hassle with the GPL any more! And with a near 100% replacement of the code base, it's possible. I've channeled Steve Baur, with the result that "if we can't have GPLv2, it's better to have no GPL at all!" So that's settled, I think. I think you can see that we all have our work cut out for us. But I hope that you will appreciate this plan, as I do. Once implemented, Emacsen will never be the same! Comments and patches welcome! Steve aka "Mr. XEmacs" (on vacation) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 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 April 2011