May 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Re: some MULE inconsistencies [with patch] 24 years, 2 months

Alexey Mahotkin

>>>>> "BW" == Ben Wing <ben(a)666.com> writes: >> There is a tiny issue which could be considered an academic bug in >> redisplay code: (set-charset-ccl-program) does not redraw >> characters in specified encoding :) BW> try adding this line: face_property_was_changed (Vdefault_face, BW> Qfont, Qglobal); BW> to set-charset-ccl-program and see if it helps. Works. I've added it after XCHARSET_CCL_PROGRAM, sure. Thank you, --alexm

1 participants
0 comments

Crash with 21.4.1 24 years, 2 months

James LewisMoss

Here's the backtrace printed to the log file: Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. If you have access to the PROBLEMS file that came with your version of XEmacs, please check to see if your crash is described there, as there may be a workaround available. Otherwise, please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/bin/xemacs21 core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: dispatch-non-command-events() # (condition-case ... . ((nil))) progress-feedback-dispatch-non-command-events() # bind (tmsg top frame value message label) append-progress-feedback(font-lock "Fontifying test... " 100 nil) # bind (frame value message label) display-progress-feedback(font-lock "Fontifying test... " 100) # bind (str) # (unwind-protect ...) # bind (args value fmt label) progress-feedback-with-label(font-lock "Fontifying %s... " 100 "test") # bind (loudly loudvar end start) font-lock-fontify-keywords-region(1 11452 nil) # (unwind-protect ...) # bind (modified buffer-undo-list inhibit-read-only old-syntax-table buffer-file-name buffer-file-truename loudly end beg) font-lock-default-fontify-region(1 11452 nil) # bind (loudly end beg) font-lock-fontify-region(1 11452) # bind (val end beg) #<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3>(1 11452 t) map-range-table(#<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3> #s(range-table data ((1 11452) t))) # bind (zmacs-region-stays) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # bind (dummy buffer) #<compiled-function (buffer dummy) "...(49)" [font-lock-pending-buffer-table zmacs-region-stays font-lock-range-table buffer remhash buffer-live-p clear-range-table map-extents #<compiled-function ... "...(32)" ... 5> nil font-lock-pending t put-text-property map-range-table #<compiled-function ... "...(5)" ... 3>] 9>(#<buffer "test"> t) maphash(#<compiled-function (buffer dummy) "...(49)" [font-lock-pending-buffer-table zmacs-region-stays font-lock-range-table buffer remhash buffer-live-p clear-range-table map-extents #<compiled-function ... "...(32)" ... 5> nil font-lock-pending t put-text-property map-range-table #<compiled-function ... "...(5)" ... 3>] 9> #<hash-table size 0/29 weakness key 0x2452>) # (unwind-protect ...) # bind (match-data) font-lock-fontify-pending-extents() byte-code("..." [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2) # (condition-case ... . ((error (warn "Error caught in `font-lock-pre-idle-hook': %s" font-lock-error)))) font-lock-pre-idle-hook() # (condition-case ... . error) # (condition-case ... . error) # (catch top-level ...) The backtrace from the core file isn't so interesting: #0 0x40422801 in ?? () #1 0x40422738 in ?? () #2 0x8172cb6 in RadioUnset () #3 0x4014f905 in ?? () #4 0x4014f5eb in ?? () #5 0x4014f334 in ?? () #6 0x4014fcee in ?? () #7 0x40150058 in ?? () #8 0x4015a970 in ?? () #9 0x8151964 in emacs_Xt_event_handler () #10 0x8151a2e in emacs_Xt_event_handler () #11 0x80cb49f in allocate_command_builder () #12 0x80cd426 in Fdispatch_non_command_events () #13 0x80a85c6 in Feval () #14 0x80a6556 in condition_case_1 () #15 0x80a67df in condition_case_3 () #16 0x808af8d in execute_rare_opcode () #17 0x808a50b in funcall_compiled_function () #18 0x808a37f in funcall_compiled_function () #19 0x80a8bc1 in Ffuncall () #20 0x808a677 in funcall_compiled_function () #21 0x808a37f in funcall_compiled_function () #22 0x80a8bc1 in Ffuncall () ---Type <return> to continue, or q <return> to quit--- #23 0x808a677 in funcall_compiled_function () #24 0x808a37f in funcall_compiled_function () #25 0x80a8bc1 in Ffuncall () #26 0x808a677 in funcall_compiled_function () #27 0x808a37f in funcall_compiled_function () #28 0x80a8bc1 in Ffuncall () #29 0x808a677 in funcall_compiled_function () #30 0x808a37f in funcall_compiled_function () #31 0x80a8bc1 in Ffuncall () #32 0x808a677 in funcall_compiled_function () #33 0x808a37f in funcall_compiled_function () #34 0x80a8bc1 in Ffuncall () #35 0x808a677 in funcall_compiled_function () #36 0x808a37f in funcall_compiled_function () #37 0x80a8bc1 in Ffuncall () #38 0x808a677 in funcall_compiled_function () #39 0x808a37f in funcall_compiled_function () #40 0x80a8bc1 in Ffuncall () #41 0x8122a93 in Fmap_range_table () #42 0x80a8aca in Ffuncall () #43 0x808a677 in funcall_compiled_function () #44 0x808a37f in funcall_compiled_function () #45 0x80a8bc1 in Ffuncall () ---Type <return> to continue, or q <return> to quit--- #46 0x80a1a87 in Fmaphash () #47 0x80a8aca in Ffuncall () #48 0x808a677 in funcall_compiled_function () #49 0x808a37f in funcall_compiled_function () #50 0x80a8bc1 in Ffuncall () #51 0x808a677 in funcall_compiled_function () #52 0x808c8d1 in Fbyte_code () #53 0x80a85f2 in Feval () #54 0x80a6556 in condition_case_1 () #55 0x80a67df in condition_case_3 () #56 0x808af8d in execute_rare_opcode () #57 0x808a50b in funcall_compiled_function () #58 0x808a37f in funcall_compiled_function () #59 0x80a8bc1 in Ffuncall () #60 0x80a93cf in run_hook_with_args_in_buffer () #61 0x80a943e in run_hook_with_args () #62 0x80a919d in Frun_hooks () #63 0x80a9538 in run_hook () #64 0x80a9f11 in eval_in_buffer_trapping_errors () #65 0x80a6556 in condition_case_1 () #66 0x80aa104 in safe_run_hook_trapping_errors () #67 0x80ccda5 in in_single_console_state () #68 0x80cd015 in Fnext_event () ---Type <return> to continue, or q <return> to quit--- #69 0x8091a47 in Fcommand_loop_1 () #70 0x8091905 in Frecursive_edit () #71 0x80a6556 in condition_case_1 () #72 0x8091553 in Freally_early_error_handler () #73 0x8091577 in Freally_early_error_handler () #74 0x80a622c in internal_catch () #75 0x80916ae in initial_command_loop () #76 0x80a32e1 in xemacs_21_4_1_i386_debian_linux () #77 0x80a3a52 in main () #78 0x4041316b in ?? () I'm trying to get a better backtrace. This is with my default setup I'll also try with -vanilla, but figured this might be enough for someone to figure out what is happening. Jim -- ＠James LewisMoss <dres(a)debian.org> | Blessed Be! ＠ http://jimdres.home.mindspring.com | Linux is kewl! ＠"Argue for your limitations and sure enough, they're yours." Bach

1 participants
0 comments

assertion failed, file event-stream.c, line 1037, tm 24 years, 2 months

Philip Aston

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.5 (beta0) "alfalfa" [Lucid] (i686-pc-cygwin) of Wed Apr 18 2001 on PASTON configured using `configure --with-dragndrop --site-includes=/usr/include/w32api' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: For a whlie now I've been getting occasional assertions: Fatal error: assertion failed, file event-stream.c, line 1037, tm Until now, I did not have a repeatable test case. With the latest source from CVS I've managed to repeat this when rendering an HTML rich VM message. I have a VM folder containing said message with which ... $ xemacs -q M-x vm-visit-folder bug (Spinning, messages about contacting www:80 etc) Assertion failure This happens under cygwin/native NT UI. It does not happen with -nw. The e-mail is private, but I'll forward it if anyone wants to investigate. - Phil Recent keystrokes: M-button1 M-button1up misc-user misc-user Recent messages (most recent first): Parsing /home/philipa/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... M-Sh-insert not defined. M-Sh-insert not defined. M-Sh-insert not defined. Loading emacsbug...done Loading emacsbug... 5 messages, 0 new, 0 unread, 0 deleted Loading smiley...done

3 participants
2 comments

[bug] kill-line broken in macros 24 years, 2 months

Hrvoje Niksic

Ben, I believe one of your changes to kill-line broke its execution in macros. For some time now I've been witnessing a strange discrepancy in the behavior of keyboard macros during recording and execution. Finally I've narrowed it down to `kill-line' misbehaving. The problem is that the variable `kill-whole-line' is not respected when `kill-line' is executed as part of a keyboard macro. TO REPEAT: Start `xemacs -vanilla', set `kill-whole-line' to t. See that kill-line at BOL kills the entire line. Now record a macro solely consisting of C-k: C-x ( C-k C-x ) Try executing it with `C-x e' and you'll see that it no longer kills the whole line, but only the part up to the newline, as if kill-whole-line were set to nil. I haven't had the time to investigate this properly, but I suspect the problem is in this change: If called interactively, may kill the entire line when given no ^^^^^^^^^^^^^^^^^^^^^^^ argument at the beginning of a line; see `kill-whole-line'. Apparently functions bound to keys executed in keyboard macros get call non-interactively[1]. In the case of kill-line, it makes a big difference, thus causing the macro weirdness. I'm working around the problem by redefining kill-line in my .emacs, but a real fix would be to make macro execution execute commands with `call-interactively', as God intended. (But this may cause other side effects.) [1] This is easy to test by creating a dummy command that prints a message if (interactive-p) and binding it to a key. And indeed, I confirmed that such a command prints its message on a key press, but not when invoked as part of macro execution!

2 participants
3 comments

find-function & load-history 24 years, 2 months

Steve Youngs

Just because I'm a curious old soul, and this has been bugging me for a while now... By default, 'M-x find-function RET abbrev-mode RET'[1] shows a buffer with /usr/local/src/xemacs-21.5/lisp/abbrev.el in it. And if that file doesn't exist, an error. How can I make it show me: /usr/local/lib/xemacs-21.5-b0/lisp/abbrev.el ie, the installed version? Footnotes: [1] Just a randomly chosen defun in core lisp to make the point. -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------<youngs(a)xemacs.org>---|

2 participants
2 comments

Re: Bug in cc-mode v5.27 and v5.28 24 years, 2 months

Martin Stjernholm

Charles Hines <hines(a)gderome.com> wrote: > void > foo(int a) > { > switch (a) > { > case 1: // Example: "1:2:3" > { > } > break; // "unbalanced paren" error occurs here > } > } The following patch fixes this. Thanks. diff -u -r5.106 cc-langs.el --- cc-langs.el 2001/02/18 16:09:44 5.106 +++ cc-langs.el 2001/05/05 13:14:36 ＠＠ -344,7 +344,7 ＠＠ (make-variable-buffer-local 'c-comment-start-regexp) ;; Regexp describing a switch's case or default label for all languages -(defconst c-switch-label-key "\$\\(case[( \t]+\\S .*\$\\|default[ \t]*\\):") +(defconst c-switch-label-key "\$\\(case[( \t]+\\S [^:]*\$\\|default[ \t]*\\):") ;; Regexp describing any label. (defconst c-label-key (concat c-symbol-key ":\$[^:]\\|$\$"))

1 participants
0 comments

about those print margins ... 24 years, 2 months

Ben Wing

i changed top and bottom defaults to 0.5". 1" seemed like wasted space. comments? -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

1 participants
0 comments

Bug in XEmacs config script for finding ld 24 years, 2 months

Andrew Begel

I was trying to build XEmacs 21.4.1 on Solaris 8. I've got gcc 2.95.2 installed and configured to use GNU ld. However, I also have Solaris's ld installed too. The XEmacs configure script uses a macro defined in aclocal.m4 to check for GNU ld vs. the local platform's ld. This macro has a mistake in it. It uses gcc -print-prog-name=ld to get the path to the linker used by gcc, and then should use the result to run ld -v to see if the linker is GNU. But the original macro assumes that if the linker's path has gcc-lib in it, then running gcc -v must be just as good as running the linker with -v directly. But that's not ok. Running gcc -v tells you nothing about the linker that gcc is using, so the GNU ld test fails when it's supposed to succeed. You should really run the linker that gcc reports. This bug fix to the macro will allow configure to correctly use the GNU ld when building XEmacs. Andrew Index: aclocal.m4 =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/aclocal.m4,v retrieving revision 1.3 diff -u -r1.3 aclocal.m4 --- aclocal.m4 2001/04/12 18:20:32 1.3 +++ aclocal.m4 2001/05/04 22:46:03 ＠＠ -313,12 +313,13 ＠＠ # Accept absolute paths. /*) if test -z "$LTLD"; then - case "$ac_prog" in - *gcc-lib*) LTLD="$CC" - ;; - *) LTLD="$ac_prog" - ;; - esac +# case "$ac_prog" in +# *gcc-lib*) LTLD="$CC" +# ;; +# *) + LTLD="$ac_prog" +# ;; +# esac fi ;; "")

1 participants
0 comments

Bug fix for defining types in external modules 24 years, 2 months

Andrew Begel

Here's a small bug fix to compiling external modules that declare new lrecord types: Index: lrecord.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lrecord.h,v retrieving revision 1.9 diff -u -r1.9 lrecord.h --- lrecord.h 2001/04/12 18:24:00 1.9 +++ lrecord.h 2001/05/05 00:20:16 ＠＠ -495,7 +495,7 ＠＠ #define INIT_EXTERNAL_LRECORD_IMPLEMENTATION(type) do { \ lrecord_type_##type = lrecord_type_count++; \ - lrecord_##type.lrecord_type_index = lrecord_type_##type; \ + lrecord_##type.lrecord_type_index = (enum lrecord_type)lrecord_type_##type; \ INIT_LRECORD_IMPLEMENTATION(type); \ } while (0) We just needed one more typecast to stop gcc from complaining about casting an unsigned int to an enum lrecord_type. Andrew

1 participants
0 comments

Re: XEmacs on the Emacs web ring 24 years, 2 months

Adrian Aichner

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> adrian -- i've added www.xemacs.org to the Emacs web ring. Ben> please add this html somewhere on the site: Ben, All! You'll be thrilled to hear that XEmacs is now part of the Emacs Web Ring See http://www.gnusoftware.com/WebRing/zone.cgi?list Thanks, Ben, for suggesting this. Best regards, Adrian Ben>  <center><br> Emacs-Ring - Site Number 28 <br> [ Ben> <a Ben> href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=next">Next Site</a> Ben> | <a Ben> href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=skipnext">Skip Next Ben> Site</a> | <a Ben> href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=prev">Previous Ben> Site</a> | <a Ben> href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=skipprev">Skip Ben> Previous Site</a> | <a Ben> href="http://www.gnusoftware.com/WebRing/zone.cgi?list">List Sites</a> | <a Ben> href="http://www.gnusoftware.com/WebRing/">Home</a> ] </center><br> Ben>  Ben> -- Ben> ben Ben> I'm sometimes slow in getting around to reading my mail, so if you Ben> want to reach me faster, call 520-661-6661. Ben> See http://www.666.com/ben/chronic-pain/ for the hell I've been Ben> through. -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

1 participants
0 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 May 2001