July 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Release candidate for XEmacs 21.4.4 / my vacation 24 years, 1 month

Alexey Mahotkin

>>>>> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: SJT> Finally I've had time to get to the backlog of patches aimed at the SJT> next release of the 21.4 series. SJT> on top of things. So I'd appreciate it if people would scan the list SJT> of changes below for any glaring errors of omission or commission. I vote for http://list-archive.xemacs.org/xemacs-patches/200106/msg00061.html and for --- lisp/mule/cyrillic.el 2001/06/05 20:16:35 1.1 +++ lisp/mule/cyrillic.el 2001/06/05 20:16:44 ＠＠ -137,11 +137,11 ＠＠ ;; `iso-8-1' is not correct, but XEmacs doesn't have a `ccl' category (coding-system-put 'koi8-r 'category 'iso-8-1) -;; (define-ccl-program ccl-encode-koi8-font -;; `(0 -;; ((r1 |= 128) -;; (r1 = r1 ,cyrillic-koi8-r-encode-table))) -;; "CCL program to encode Cyrillic chars to KOI font.") +(define-ccl-program ccl-encode-koi8-r-font + `(0 + ((r1 |= 128) + (r1 = r1 ,cyrillic-koi8-r-encode-table))) + "CCL program to encode Cyrillic chars to koi8-r font.") ;; (setq font-ccl-encoder-alist ;; (cons (cons "koi8" ccl-encode-koi8-font) font-ccl-encoder-alist)) Those two patches relieve all the pain for Cyrillic users under Mule. --alexm

3 participants
11 comments

xemacs/vm freeze 24 years, 1 month

Daniel Wolk

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.4 (patch 2) "Developer-Friendly Unix APIs" [Lucid] (i686-pc-linux, Mule) of Tue May 22 2001 on iqara configured using `configure --with-mule --with-pop' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Sorry I cannot give much technical detail, but I have an annoying problem. If I leave xemacs and vm (6.92) running unattended, the programs consistently freeze. Sometimes it happens within minutes, sometimes it takes hours. I also notice that sometimes even if I run vm-save-folder as the last thing I do, there is still a more recent autosave file with vm (which is the file as it was before vm-save-folder). I don't know what other information to give you. So please let me know what other information to provide.I did try running "gdb /usr/local/bin/xemacs" and then "run" under gdb. At that point the following was returned: Cannot access memory at address 0x40017e20 I am running xemacs under kde 2.2alpha2, if that is relevant. Daniel Wolk Recent keystrokes: misc-user Recent messages (most recent first): Parsing /home/wolk/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Fontifying .vm... done. Loading emacsbug... Loading blink-cursor...done Loading blink-cursor... Paren mode is sexp Loading paren...done

4 participants
3 comments

DISPLAY not set by "-display" command-line option 24 years, 1 month

Karr, David

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.4 (patch 3) "Academic Rigor" [Lucid] (i686-pc-linux) of Tue Jul 10 2001 on eos.redmond.cacheflow.com configured using `configure --prefix=/home/david.karr/local' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I'm got Win2k on my desktop, and using ReflectionX to connect to a Linux system. I can run both "rxvt" and "XEmacs" through ReflectionX so they show up correctly on my desktop. However, in the rxvt shell, I can echo the value of $DISPLAY, and it shows up correctly with the IP address of my PC. However, if I echo $DISPLAY in a shell buffer in XEmacs, or even through '(getenv "DISPLAY")' in my *scratch* buffer, it just shows blank or "nil". Both "rxvt" and "XEmacs" are being run with a "-display" command-line parameter. As a result of this, it's awkward to run other X applications from the shell buffer. Recent keystrokes: j f TAB s w i TAB BS BS BS S w i TAB S TAB RET l s RET j a v a SPC - v BS j a r SPC S w i n TAB . j a r RET RET button1 button1up C-x 2 C-x b * s c r RET ( g e t e n v SPC " D I S P L A Y " ) C-j C-h a d i s p l a y RET C-v C-v C-v C-v q button1 button1up ESC x r e p o TAB r TAB RET Recent messages (most recent first): Loading emacsbug...done Loading emacsbug... Making completion list... Loading hyper-apropos...done Loading hyper-apropos... Partially completed Completing file name... ~/tools/jdk1.3.1/demo/jfc/SwingSet2/ Completed Completing file name...

2 participants
1 comments

Re: question on make-variable-buffer-local 24 years, 1 month

Charles Waldman

> charles> I noticed that in edebug.el, the variable > charles> `edebug-form-data' is defconst'ed *before* it is set > charles> buffer-local. Oops, I meant to say the exact opposite! In the current version of edebug.el, the variable is made to be buffer-local before it is defconst'ed. I also noticed, checking an older version of this file, that the order of initialization was what makes more sense to me: ;; XEmacs change? (defconst edebug-form-data nil) (make-variable-buffer-local 'edebug-form-data) Is it legitimate to make a variable buffer-local before it is defined?

2 participants
1 comments

Suicidal XEmacs 24 years, 1 month

Scott Jaderholm

Well, kind of. I run ./configure on the cvs version and it says this stuff (let ((gc-cons-threshold ...)) (call-with-condition-handler (quote really-early-error-handler) (function ...)) (setq preloaded-file-list (mapcar ... preloaded-file-list)) (setq load-warn-when-source-newer t load-warn-when-source-only nil) (setq debugger (quote debug)) (when (member "no-site-file" command-line-args) (setq site-start-file nil)) (when (load "site-load" t) (garbage-collect)) (when purify-flag (message "Finding pointers to doc strings...") (Snarf-documentation "DOC") (message "Finding pointers to doc strings...done") (Verify-documentation)) (when (stringp site-start-file) (load "site-init" t)) (setq current-load-list nil) (garbage-collect) (buffer-enable-undo "*scratch*")) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load("/home/scott/src/xemacs-21.5/src/../lisp/loadup.el") # (condition-case ... . error) # (catch top-level ...) *** Killing XEmacs make[1]: *** [xemacs] Error 255 make[1]: Leaving directory `/home/scott/src/xemacs-21.5/src' make: *** [src] Error 2 I also seem to remember getting this error with the gamma release. I'm not subscribed to the list so please CC me. Sincerely, jsj -- the sky is tired of being blue

2 participants
1 comments

21.4.3 unusable: doesn't recognize keystrokes 24 years, 1 month

Daniel Wolk

Dear Xemacs Beta List: On my Linux system (glibc 2.2) Recently I did some upgrades and now my xemacs (21.4.3) has been rendered useless. When I run xemacs, many keystrokes do not work, such as any with the Meta- or Control keys, as well as spacebar. I recompiled with --with-mule --with-pop --debug, but this made no difference. Here is the only error message I can get (using debug-on-error): Signaling: (undefined-keystroke-sequence [#<keypress-event >]) (This happens after I press the spacebar). I tried running xemacs under gdb. I am only a novice doing this. But I do see this warning: XtRemoveGrab asked to remove a widget not on the list Here is what I recently upgraded to: lesstif-0.92.32 xfree86 4.1.0 libiconv 1.7 libxml2 2.3.14 kde 2.2beta1 Please, if anyone can help me, I would really appreciate it. I don't know: perhaps the problem is with one of those packages. But I have seen any other notable problems yet.

2 participants
1 comments

searching archives 24 years, 1 month

Jeff Mincy

I was trying to see if anybody else had similar trouble compiling 21.4 on solaris (see http://list-archive.xemacs.org/xemacs-beta/200106/msg00324.html). So, I went to http://list-archive.xemacs.org/xemacs-beta/ to search the archives. Searching for 'specifier.c' takes a verrrry long time (while searching for solaris comes back immediately). I also tried specifier\.c which also took a reallly long time. Anyway, I didn't anything obvious that helped, except a hint that I shouldn't use the gnu assembler (I'm not) on solaris. -jeff

1 participants
0 comments

Re: Color of wrapped line with pixmap background always "white" 24 years, 1 month

Andy Piper

There are a number of redisplay bugs like this in 21.4. I'm hoping to take a look at them soon. andy At 10:24 AM 7/19/01 +0200, Schäuble Roland wrote: >I use XEmacs 21.4.3 on Windows 2000 and use a background pixmap >as the default background: > >;; Filename of background wallpaper >(setq background-wallpaper "~/old-paper.jpg") > >;; Set background pixmap >(set-face-background-pixmap 'default background-wallpaper) > >Now if a line is too long to be displayed on the screen, this line is >always displayed in white, which makes it almost unreadable in my >environment. This behavior is independant if the line is really "wrapped" or >not. > >The continuation line is displayed correctly. >I found no special face for "wrapped" or "long" lines in "edit faces" so >I tried to set the face of "Truncation and continuation glyphs face" >with no effect for the long line (The glyphs face was set correctly). > >XEmacs 21.1.14 had no problem with this.

2 participants
1 comments

Weird XEmacs crash diagnosis 24 years, 1 month

Nix

Regarding my earlier crash on sparc-sun-solaris2.5.1: XEmacs is crashing because the superclass of the topLevelEmacsShellWidgetClass is not initialized. In fact, the entire thing looks decidedly screwy. Just after entering main() in temacs, it looks like this: $1 = {core_class = {superclass = 0x4ecf60, class_name = 0x1b5b98 "TopLevelEmacsShell", widget_size = 328, class_initialize = 0, class_part_initialize = 0, class_inited = 0 '\000', initialize = 0, initialize_hook = 0, realize = 0x1c87f8 <_XtInherit>, actions = 0x0, num_actions = 0, resources = 0x1d0e10, num_resources = 6, xrm_class = 0, compress_motion = 0 '\000', compress_exposure = 1 '\001', compress_enterleave = 0 '\000', visible_interest = 1 '\001', destroy = 0, resize = 0x1c87f8 <_XtInherit>, expose = 0, set_values = 0, set_values_hook = 0, set_values_almost = 0x1c87f8 <_XtInherit>, get_values_hook = 0, accept_focus = 0, version = 11005, callback_private = 0x0, tm_table = 0x0, query_geometry = 0, display_accelerator = 0, extension = 0x0}, composite_class = {geometry_manager = 0x1c87f8 <_XtInherit>, change_managed = 0x180a58 <ChangeManaged>, insert_child = 0x1c87f8 <_XtInherit>, delete_child = 0x1c87f8 <_XtInherit>, extension = 0x1d0eb8}, shell_class = {extension = 0x1d0ecc}, wm_shell_class = {extension = 0x0}, vendor_shell_class = {extension = 0x0}, top_level_shell_class = {extension = 0x0}, emacs_shell_class = {dummy = 0}} Note that some of the fields (e.g. core_class.class_name) are right, but others (e.g. composite_class.insert_child) are wrong, or even point at inaccessible garbage (e.g. core_class.superclass). `superclass', for instance, has a value very different to that of topLevelShellClassRec (transientShellClassRec points to the same place): (gdb) print (WidgetClass) topLevelShellClassRec $5 = (struct _WidgetClassRec *) 0xef78bc00 So somewhere *before XEmacs starts* that value of 0xef78bc00 is getting mangled to 0x4ecf60, which is crashing libXt and thus XEmacs. Furthermore, this doesn't happen if XEmacs (and probably just src/EmacsShell-sub.c) is assembled with the Solaris assembler, rather than GNU as from binutils-2.11.2. So it looks like this is (another) binutils-on-Solaris bug. Bah. -- `> You never need to use # for anything, either? Not to date, but # would suffice if I did.' -- Stig Brautaset espouses uniquely effective ways of protecting HTML from #-stripping preprocessors

2 participants
1 comments

Re: [lisp/packages.el:locate-data-file] Allow gzipped files in data-directory-list 24 years, 1 month

Stephen J. Turnbull

Moving the discussion to xemacs-beta, per policy. Thus the full-body quote. >>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes: >> --==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes: SJT> VETO SY> You're a bit late, I had already approved and committed this SY> to 21.5 ages ago. I suspected that. Based on the date, I was using a snorkel to breathe through the midterms (and 21.4.3) rather reviewing "feature" patches carefully. Oh, well. It probably won't do any harm, but is that really the way we want to run this railroad? Core lisp should not try to cater to user vagaries (space-saving fanatic or not, uses jka-compr or not) IMHO. >>>>>>> "Karl" == Karl M Hegbloom <karlheg(a)hegbloom.net> writes: SJT> 2001-05-13 Karl M. Hegbloom <karlheg(a)hegbloom.net> SJT> * packages.el (locate-data-file): Use suffixes list to allow SJT> finding compressed copies of the data files. SJT> Karl, SJT> Sorry about the long delay. SJT> I think this is a bad idea. I'm not going to apply to 21.4, SJT> and I recommend that it not be applied to 21.5, either. SJT> (1) In your implementation, you left out the null suffix. SJT> That means an uncompressed file won't be found. SY> I added the null suffix before I committed. SJT> (2) You left out at least two common suffixes (".Z" and SJT> ".zip"), and there may be others (".lha", ".hqx") to worry SJT> about on other platforms. SY> But these can be added at a later time. People who use these SY> types of compressed files will be no worse off than they are SY> now. SJT> (3) It's probably a bad idea to return compressed files, as SJT> not all XEmacsen will know what to do with them, having SJT> potentially bad consequences. SY> But can't the XEmacsen that this patch was applied to handle SY> compressed files? As far as I know 21.1, 21.2, 21.4, and 21.5 SY> can handle it and the patch isn't being applied anywhere else. SY> What I'm saying is that is someone has an XEmacs that pukes on SY> compressed files, they aren't gonna have this patch anyway. No, AFAIK no XEmacs automagically handles compressed files _until jka-compr is enabled_. That means that code that does something like (load (locate-data-file "library.el")) will be badly hosed. (And don't tell me that no one in their right mind would load Lisp code that way; there will be similar examples that make more sense in practice if you put your mind to it.) SJT> (4) This convenience really would be most useful SJT> interactively, but the function in question isn't SJT> interactive. SY> Again, this can be added at a later time. The function not SY> being interactive doesn't make it unusable. Perhaps a little SY> harder to take advantage of the added functionality. The point here is that a _user_ will immediately recognize that something is wrong if a buffer is filled with raw gzip. Code will not, and will happily try to parse it with who knows what results. SY> I have no problem with any of these, although I can't think SY> right now how to go about doing (3). Check for whether jka-compr is loaded. I think featurep will do, although it may be possible to turn off jka-compr which would leave the feature in place. SY> Leave this patch in 21.5, don't commit to 21.4 or 21.1. I think it's risky for the reasons above. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

3 participants
3 comments

2025

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 July 2001