May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Request: Release binaries of xemacs for OpenNT 23 years, 4 months

Mark Hammond

OpenNT (www.opennt.com) is a full replacement for the posix subsystem of Windows NT. It turns a Windows NT machine into a completely posix compliant machine capable of running unix code natively. Thus using any X-server for windows (one is included with OpenNT) xemacs could be run natively on Windows NT machines without code modification. In theory, it should be a simple recompile to generate binaries on an OpenNT machine. (OpenNT includes gcc and all of the necessary development tools.) I would like to request that you release binaries for this platform! Thanks, Mark BTW - I haven't had much luck myself doing the compile, but I haven't really put much of any effort into it. I posted mail to the newsgroup comp.emacs.xemacs to see if anyone had already successfully done this, but haven't had much positive feedback.

2 participants
1 comments

Re: [PATCH] python-mode weirdness in xemacs-21.0b41 on Win98 23 years, 5 months

Charles G Waldman

Barry A. Warsaw writes: > > looks like the xemacsers have a patch. does that do the trick? > The patch posted yesterday fixes the problem starting a Python buffer (thanks Kirill!). Python.exe was being passed as both argv[0] and argv[1], which clearly was making the interpreter unhappy. Getting "Execute buffer" to work requires this little patch of mine - the tempfile name passed to Python has backslashes in it, which again makes the interpreter unhappy. Even if I customize py-temp-dir to be C:/tmp instead of C:\tmp the temp file name created has the backslash instead of the forward slash. Here's a trivial patch to get python-mode working. There's probably a better way to do this, depending on whether we are on a Windows platform, etc, but the string replacement I do should be a no-op on Unix platforms. --- python-mode.el.orig Sat May 30 11:42:58 1998 +++ python-mode.el Sat May 30 11:43:06 1998 ＠＠ -1176,10 +1176,10 ＠＠ (format "python-%d" py-serial-number) (setq py-serial-number (1+ py-serial-number))) (make-temp-name "python"))) - (file (concat (file-name-as-directory py-temp-directory) temp))) + (file (replace-in-string (concat (file-name-as-directory py-temp-directory) temp) "\\\\" "/" ))) (write-region start end file nil 'nomsg) (cond - ;; always run the code in it's own asynchronous subprocess + ;; always run the code in its own asynchronous subprocess (async (let* ((buf (generate-new-buffer-name py-output-buffer))) (start-process "Python" buf py-python-command "-u" file)

2 participants
1 comments

[Patch] exact-minibuffer-completion-p 23 years, 5 months

Jeff Miller

I was having a problem with completing-read. The completion table that I was passing had some nil elements. This caused an error when I would try to hit TAB for completion. I was getting a "not char-or-string" error msg. i tracked it down to exact-minibuffer-completion-p. The error occurs when doing the (upcase tem). Try (upcase nil), you'll get the error. This work the same in XEmacs & Emacs. But, completion-read in Emacs doesn't barf if there are nil elements in the completion table. I tried looking at the "C" version of this minibuffer stuff in Emacs 20.2, and I think it is doing a nil test before doing the upcase. So I added one to our lisp version. Fixes the problem I was having and I don't think it screws anything else up. Jeff --- lisp/minibuf.el.orig Sat May 30 11:58:24 1998 +++ lisp/minibuf.el Sat May 30 11:59:49 1998 ＠＠ -650,7 +650,7 ＠＠ (setq tem (car (car tail))) (if (or (equal tem buffer-string) (equal tem s) - (equal (upcase tem) s)) + (if tem (equal (upcase tem) s))) (setq s 'win tail nil) ;exit (setq tail (cdr tail))))

1 participants
0 comments

Re: [patch]Changing GIF libraries 23 years, 5 months

Oliver Graf

jareth(a)camelot.co.jp (P. E. Jareth Hein) writes: > > Uh, what about us graphics heads? I've been compiling GIMP to > > the modified giflib and it works just fine (my rpm giflib is now old > > giflib). > > My modified giflib will co-exist just fine with gifreader (there is no > overlap of file or library names, I just called it 'giflib-lite' for > clarity purposes, and apparently this backfired upon me). I wasn't > aware that the Gimp was using giflib, so I'll talk to them and see if > they want copies of my changes. There is a package called libungif. It is a support lib of the GNOME project and does the same as your gifreader. Perhaps we can also use this one (just to keep the number of different giflibs low...). ftp://ftp.labs.redhat.com/pub/gnome/support/SRPMS/libungif-3.0-4.src.rpm Regards, Oliver.

1 participants
0 comments

python-mode weirdness in xemacs-21.0b41 on Win98 23 years, 5 months

Charles G Waldman

The subject says it all - I may be half-crazy to be running Win98 I know, but I wanted to test it out - I have the latest xemacs beta and it runs pretty well for most of what I do, until I try to open an interactive Python session - when I do: M-x python-mode C-c ! I get: File "c:\PROGRA~1\PYTHON\python.exe", line 1 MZ$L$PQè>＠ª330ª3::0ª3ª3 ^ SyntaxError: invalid syntax Process Python exited abnormally with code 1 Python 1.5 is installed at C:\Program Files\Python which is name-mangled to C:\PROGRA~1\PYTHON in my PATH setting. Typing "python" from a DOS prompt works fine.

3 participants
4 comments

itimer.el calls concat with integer arg 23 years, 5 months

Sudish Joseph

In XEmacs 21.0 "Saanen" [Lucid] (sparc-sun-solaris2.6, Mule) of Fri May 22 1998 on ra `activate-itimer' calls concat with an integer argument in 21.0-b40. The `concat' docs say this is no longer permitted. This caused an error in Gnus which uses timers for it's asynch article readahead. --- xemacs-21.0-b40/lisp/itimer.el~ Fri May 29 14:09:57 1998 +++ xemacs-21.0-b40/lisp/itimer.el Fri May 29 14:09:57 1998 ＠＠ -395,7 +395,7 ＠＠ (oname "itimer-") (num 1)) (while (get-itimer name) - (setq name (concat oname "<" num ">")) + (setq name (concat oname "<" (format "%d" num) ">")) (itimer-increment num)) (setcar itimer name)) ;; signal an error if the timer's name matches an already -Sudish

2 participants
1 comments

Re: Dumped-lisp.el in vm 23 years, 5 months

SL Baur

Kirill M Katsnelson <kkm(a)kis.ru> writes: > Is not this file a leftover? Yes.

1 participants
0 comments

Re: Startup speed: Still too many stats? 23 years, 5 months

Michael Sperber

>>>>> "Darryl" == Darryl Okahata <darrylo(a)sr.hp.com> writes: Darryl> I don't know about NT, but stat() is VERY expensive under Win95. Darryl> If I recall correctly, a call to stat() takes on the order of Darryl> milliseconds on a non-MMX P166 (and I think over 10ms), under Win95 Darryl> OSR2. Why, I don't know (this is real/elapsed, and not CPU, time). By Darryl> bypassing stat(), and using the native Win32 system calls, my dired-in-C Darryl> changes were able to get a significant performance improvement. That's why I asked if there isn't a way to compute file-directory-p without doing a full stat under Win32. Don't DOS directories store that information in the directory entry? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

5 participants
7 comments

Re: itimer.el calls concat with integer arg 23 years, 5 months

William M. Perry

Sudish Joseph <sj(a)eng.mindspring.net> writes: > In XEmacs 21.0 "Saanen" [Lucid] (sparc-sun-solaris2.6, Mule) of Fri May 22 1998 on ra > > `activate-itimer' calls concat with an integer argument in 21.0-b40. The > `concat' docs say this is no longer permitted. This caused an error in > Gnus which uses timers for it's asynch article readahead. You could save some string creation by doing something like this instead, right? String creation bad bad bad. (setq name (format "<%d>" num)) -Bill P. > --- xemacs-21.0-b40/lisp/itimer.el~ Fri May 29 14:09:57 1998 > +++ xemacs-21.0-b40/lisp/itimer.el Fri May 29 14:09:57 1998 > ＠＠ -395,7 +395,7 ＠＠ > (oname "itimer-") > (num 1)) > (while (get-itimer name) > - (setq name (concat oname "<" num ">")) > + (setq name (concat oname "<" (format "%d" num) ">")) > (itimer-increment num)) > (setcar itimer name)) > ;; signal an error if the timer's name matches an already > > -Sudish

1 participants
0 comments

Re: Crash in event code 23 years, 5 months

Hrvoje Niksic

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > the problem is that the event returned contains a window in the > channel field. AFAICT this should be a frame (or console)! No, window is legal channel for scrollbar events. channel Where this event occurred on. (...) Specifically: [...] -- for scrollbar misc-user events, channel will be a window. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymour Cray, on virtual memory

2 participants
1 comments

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 May 1998