June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Simon Josefsson

Options->Manage Packages->List & Install: Right-clicking on any line and selecting help give me this backtrace: Signaling: (void-function pui-help) call-interactively(pui-help) dispatch-event(#<misc-user-event (call-interactively pui-help)>) pui-popup-context-sensitive(#<buttondown-event button3>) call-interactively(pui-popup-context-sensitive) XEmacs 21.1.2 and both sumo packages.

1 participants
0 comments

Re: mswindows-get-clipboard broken in beta 15? 25 years, 5 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > 2. M-x and C-w should copy and kill to the clipboard as well as the > kill ring. This is the behaviour that *really* bugs me, the old way > you could only get stuff in the clipboard my using the menubar, > toolbar or bogus ^H^H^H^H^H appropriate Windows keystrokes. > > 3. C-y should yank from the clipboard, I don't think these things should be done, at least not by default. C-w and C-y are separate from the window-system clipboards and selections for very good reasons. It would be a shame to break that under Windows.

1 participants
0 comments

Re: [FAILED] XEmacs 21.2.15 25 years, 5 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> I don't think so. This is a dump-time mis-interaction. The rules >> were very carefully laid out to provide maximum flexibility in the >> search order. > Would there be a way to guard better against that. When 21.2 is > released surely there are bound to be users upgrading the packages in > the same way? Actually, 21.1 isn't incompatible in this fashion, Stephen and the others were using pre-21.0-final mule-base packages -- if you live on the bleeding edge and do not keep sufficiently up-to-date expect to get cut once in awhile. There's no reasonable precaution we can make and we cannot avoid changing things in test releases when they need to be changed. We probably ought to pitch everything unnecessary to building right now to avoid this sort of thing in the future. Superfluous undumped stuffs like apropos.el, cus-edit.el etc. shouldn't be in the core. I have hesitated because of past squeals of pain, but I think the time is probably right, now. The XEmacs core should only contain the minimum files necessary for making an xemacs binary *and* to provide for minimal vi-equivalent editing functionality. Everything else should be loadable at run-time, that way it isn't bloat. I am looking at getting rid of the Mule language-specific dump and making language support autoloaded. I believe this is do-able, but I need to do some experimentation to be sure. -- I protest the NATO war in Yugoslavia. I protest the use of depleted uranium weapons against any human being.

4 participants
3 comments

Moving mouse in balloon-help frame crashes XEmacs-21.2-b15 in MSWin 25 years, 5 months

Adrian Aichner

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.1 "20 Minutes to Nikko" [Lucid] (i386-pc-win32) of Fri May 14 1999 on ZJ75T configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Moving mouse in balloon-help crashes XEmacs-21.2-b15. This bug has been around for a long time. Now I decided to look into it. D:\export\home\tmp\21.2\xemacs\src>xemacs Fatal error: assertion failed, file ..\src\redisplay.c, line 6658, abort() To reproduce it, I need to load gnus and display-time. Moving mouse to mail envelope in mode-line brings up another XEmacs frame as a side-effect on MS-Windows. Moving the mouse around in this new frame will crash XEmacs with above assertion. Here's the source with the call to abort(): start_elt = point_in_line_start_cache (w, cur_start, 0); if (start_elt == -1) ==> abort (); /* this had better never happen */ while (1) Here's the VC++ Call Stack: NTDLL! 77f76148() start_end_of_last_line(window * 0x107f6000, int 1, int 1) line 6658 + 20 bytes end_of_last_line(window * 0x107f6000, int 1) line 6732 + 15 bytes pixel_to_glyph_translation(frame * 0x107e1200, int 15, int 53, int * 0x0082e354, int * 0x0082e348, int * 0x0082e338, int * 0x0082e33c, window * * 0x0082e358, int * 0x0082e35c, int * 0x0082e334, int * 0x0082e34c, Lisp_Object * 0x0082e350, Lisp_Object * 0x0082e344) line 7876 + 29 bytes event_pixel_translation(Lisp_Object {...}, int * 0x00000000, int * 0x00000000, int * 0x00000000, int * 0x00000000, window * * 0x0082e3a4, int * 0x00000000, int * 0x00000000, int * 0x00000000, Lisp_Object * 0x00000000, Lisp_Object * 0x00000000) line 1740 + 66 bytes Fevent_window(Lisp_Object {...}) line 1870 + 31 bytes Ffuncall(int 2, Lisp_Object * 0x0082e434) line 3189 + 80 bytes execute_optimized_program(const unsigned char * 0x1079d098, int 2, Lisp_Object * 0x101f0f54) line 748 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 1, Lisp_Object * 0x0082e710) line 524 + 53 bytes Ffuncall(int 2, Lisp_Object * 0x0082e70c) line 3221 + 17 bytes execute_optimized_program(const unsigned char * 0x107e1818, int 9, Lisp_Object * 0x1068c214) line 748 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 1, Lisp_Object * 0x0082eaf8) line 524 + 53 bytes Ffuncall(int 2, Lisp_Object * 0x0082eaf4) line 3221 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x1068ce00, int 2, Lisp_Object * 0x0082eaf4, int 0) line 3671 + 13 bytes run_hook_with_args(int 2, Lisp_Object * 0x0082eaf4, int 0) line 3684 + 23 bytes Frun_hook_with_args(int 2, Lisp_Object * 0x0082eaf4) line 3560 + 15 bytes Ffuncall(int 3, Lisp_Object * 0x0082eaf0) line 3207 + 14 bytes execute_optimized_program(const unsigned char * 0x101077f8, int 3, Lisp_Object * 0x10624a34) line 748 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 1, Lisp_Object * 0x0082eddc) line 524 + 53 bytes Ffuncall(int 2, Lisp_Object * 0x0082edd8) line 3221 + 17 bytes call1(Lisp_Object {...}, Lisp_Object {...}) line 3834 + 11 bytes execute_internal_event(Lisp_Object {...}) line 2952 + 16 bytes Fnext_command_event(Lisp_Object {...}, Lisp_Object {...}) line 2398 + 9 bytes Ffuncall(int 1, Lisp_Object * 0x0082eeb0) line 3189 + 107 bytes execute_optimized_program(const unsigned char * 0x0082f09c, int 4, Lisp_Object * 0x102676d4) line 748 + 16 bytes Fbyte_code(Lisp_Object {...}, Lisp_Object {...}, Lisp_Object {...}) line 2398 + 38 bytes Feval(Lisp_Object {...}) line 2986 + 195 bytes internal_catch(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x01002081 _Feval, Lisp_Object {...}, int * volatile 0x00000000) line 1315 + 7 bytes execute_rare_opcode(Lisp_Object * 0x0082f35c, const unsigned char * 0x107ab83f, int 141) line 1254 + 22 bytes execute_optimized_program(const unsigned char * 0x107ab818, int 8, Lisp_Object * 0x10266b14) line 658 + 17 bytes funcall_compiled_function(Lisp_Object {...}, int 0, Lisp_Object * 0x0082f650) line 524 + 53 bytes Ffuncall(int 1, Lisp_Object * 0x0082f64c) line 3221 + 17 bytes execute_optimized_program(const unsigned char * 0x103dba18, int 4, Lisp_Object * 0x10266c14) line 748 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 0, Lisp_Object * 0x0082f930) line 524 + 53 bytes Ffuncall(int 1, Lisp_Object * 0x0082f92c) line 3221 + 17 bytes execute_optimized_program(const unsigned char * 0x10177f18, int 6, Lisp_Object * 0x10266e14) line 748 + 16 bytes funcall_compiled_function(Lisp_Object {...}, int 0, Lisp_Object * 0x0082fb94) line 524 + 53 bytes Feval(Lisp_Object {...}) line 3045 + 20 bytes condition_case_1(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x01002081 _Feval, Lisp_Object {...}, Lisp_Object (Lisp_Object, Lisp_Object)* 0x0105005b cmd_error(Lisp_Object, Lisp_Object), Lisp_Object {...}) line 1640 + 7 bytes top_level_1(Lisp_Object {...}) line 205 + 35 bytes internal_catch(Lisp_Object {...}, Lisp_Object (Lisp_Object)* 0x0104fff2 top_level_1(Lisp_Object), Lisp_Object {...}, int * volatile 0x00000000) line 1315 + 7 bytes initial_command_loop(Lisp_Object {...}) line 284 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x10108a10, char * * 0x102f2600, int 0) line 1756 + 9 bytes main(int 1, char * * 0x10108a10, char * * 0x102f2600) line 2181 + 21 bytes XEMACS! mainCRTStartup + 180 bytes _start() line 165 Recent keystrokes: C-p RET M-> misc-user RET misc-user n n n n n n n n RET x y C-x C-z C-x C-b button2 button2up p p p p p p p p p SPC C-x 1 SPC SPC DEL q s button1 button1up n SPC q s q y M-x g n u s RET C-x C-z g n n n p SPC SPC DEL n n SPC q p p SPC button1 button1up q SPC n n SPC n n n n n n n n SPC n n n n l s g p C-x C-z button1 button1up misc-user Recent messages (most recent first): Loading emacsbug...done Loading emacsbug... No more unread newsgroups Checking new news...done Checking new news... Reading active file via nnfolder...done Reading active file via nnfolder... Reading active file via nnfolder... Reading active file via nnml...done Reading active file via nnml... -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

3 participants
2 comments

Re: mswindows-get-clipboard broken in beta 15? 25 years, 5 months

Andy Piper

At 03:42 PM 6/6/99 -0400, Dmitry Yaitskov wrote: >Now, about what upsets me. Under X, as far as I remember (I only used >X briefly) pasting meant the current selection, and I do not remember >there being a "clipboard" - although from you and Hrvoje's replies I >gathered that there actually is. Anyway, under Windows, I'd like >cut/copy/paste to work in XEmacs the same way they do in other Windows >programs. That is, selecting does not affect the clipboard until an >explicit cut or copy is done. And, pasting when a selection is active >overwrites that selection with the clipboard contents. In other words, >I'd like the functions from select.el to do what their doc strings >say, really. Ok. I think this is doable, although we will probably have to have an option to select between incompatible behaviour. I would add that: 1. Middle button should paste (the selection or the clipboard), windows people won't care since they don't use the middle button. 2. M-x and C-w should copy and kill to the clipboard as well as the kill ring. This is the behaviour that *really* bugs me, the old way you could only get stuff in the clipboard my using the menubar, toolbar or bogus ^H^H^H^H^H appropriate Windows keystrokes. 3. C-y should yank from the clipboard, in what preference to the kill-ring I don't know - the beauty of the X model is that these decisions are easy. >And, I do not care too much whether the "standard Windows" behavior is >NT XEmacs' default or not (although I do think that it would make >XEmacs NT much more useful "out of the box"), the important thing for >me is to be able to write lisp functions that would do that (which *I* >could not do with the new select code in b15). As Martin and Ben said last night "there should always be an option" :) Doing things the way windows people expect without breaking things that work the way XEmacs people expect seems reasonable to me. And the windows way should probably be the default. >While we are at it... would be nice to have an "append-to-clipboard" >function. I don't think there is one now, is there? Don't know but its easy to do. >Thanks, and sorry about the "heated" replies. No problem. Now I have to go and use that outside pool and jacuzzi - I like Northern California ..... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Experimental support for nmake /f xemacs.mak check (native build) 25 years, 5 months

Adrian Aichner

Hello All, today I am turing to the list for advice about the correctness of my approach to implement the check and check-temacs targets in xemacs.mak for the Windows native build. Atend is a patch against 21.2b15 (with some other harmless diffs) adding support for nmake /f xemacs.mak check and nmake /f xemacs.mak check-temacs One general question: Is it correct that check and check-temacs both load `site-start' and `user-init-file'? I don't have access to UNIX and can't be sure I interpreted ./src/Makefile.in.in correctly. I'll submit a patch implemnting these targets after incorporating and suggestions/corrections. Regards, Adrian -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

test-case README 25 years, 5 months

Hrvoje Niksic

Here is a README in the tests/automated directory.

1 participants
0 comments

Re: make-char update, part 2 25 years, 5 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Hrvoje Niksic writes: > > This adds a `make-char' function to non-Mule XEmacsen for partial > > compatibility with Mule. > > I don't see the value of this in a non-MULE XEmacs. make-char is the only portable interface for creating arbitrary characters. As such, it's useful in non-Mule XEmacsen for European uses. For example, I had old code that looked up Croatian characters in a table and inserted them in the buffer (I used it, and still use it, to emulate different keyboard styles.) The code basically looked like this: (let ((char ...look up...)) ;; CHAR is an 8bit value (self-insert-internal char)) Now, with Mule you need to convert the number to an actual Latin 2 character. The way to do it is using make-char, so now I have a function that looks like this: (defun latin2-convert (chr) (if (and (> chr 128) (featurep 'mule)) (make-char 'latin-iso8859-2 (- chr 128)) chr)) "make-char update", part 1, served to get rid of the 128 subtraction. With this new update, you can get rid of the featurep check and write the code like this: (defun latin2-convert (chr) (make-char (if (> chr 128) 'latin-iso8859-2 'ascii) chr)) This will do the expected thing with or without Mule. The same goes for (make-char 'ascii 65), etc. This is what I meant by "partial compatibility with Mule". This has all been hashed out between me, Olivier Galibert, and other subscribers on the Mule list, which I invite you to subscribe.

1 participants
0 comments

make-char update, part 2 25 years, 5 months

Kyle Jones

Hrvoje Niksic writes: > This adds a `make-char' function to non-Mule XEmacsen for partial > compatibility with Mule. I don't see the value of this in a non-MULE XEmacs.

1 participants
0 comments

Re: make check failure on Solaris 2.5.1 Mule 25 years, 5 months

Hrvoje Niksic

Raymond Toy <toy(a)rtp.ericsson.se> writes: > Here's what happens to me on Solaris 2.5.1 with Mule and my standard > config. (appended) [...] > mapconcat(char-to-string > > "AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4\nOTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3Bx\ncnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmq\nq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj\n5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w==" " ") I see that one too. It appears to be a memory corruption bug. I'm trying to track it down, but any help will be gracefully accepted.

1 participants
0 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 June 1999