June 2001 - XEmacs-Beta - XEmacs Mailing List Archives

[Andy Lewis <andy.lewis@cyra.com>] c-mode blink-paren matching 24 years

Nickolay Pakoulin

I think it is one more syntax-related bug that c-mode revealed. Nick.

1 participants
0 comments

i am going on vacation and have two workspaces [mule, separate-stderr] for everyone to look at. 24 years

Ben Wing

I am leaving tomorrow for a one-month vacation to Spain. I'll be returning on August 1st. I will occasionally be checking mail at ben_wing(a)hotmail.com, but not at this address. If you have something that isn't urgent, go ahead and send it to this address [either ben(a)666.com or ben(a)xemacs.org] and i'll respond when i return. meanwhile, i've checked in two workspaces to cvs. i'd appreciate it if people take a look and fix any problems encountered. [i've checkpointed the workspaces at their current state, so i'll be able to review any changes made.] NOTE: The contents of this message are in README.ben-mule-21-5 at the top of the ben-mule-21-5 workspace. the two workspaces are: ------------------------------------------------------------------ -- ben-mule-21-5 this contains all the mule work i've been doing. this includes mostly work done to get mule working under ms windows, but in the process i've [of course] fixed a whole lot of other things as well, mostly mule issues. the specifics: - it compiles and runs under windows and should basically work. the stuff remaining to do is (a) improved unicode support (see below) and (b) smarter handling of keyboard layouts. in particular, it should (1) set the right keyboard layout when you change your language environment; (2) optionally (a user var) set the appropriate keyboard layout as you move the cursor into text in a particular language. - i added a bunch of code to better support OS locales. it tries to notice your locale at startup and set the language environment accordingly (this more or less works), and call setlocale() and set LANG when you change the language environment (may or may not work). - major rewriting of file-coding. it's mostly abstracted into coding systems that are defined by methods (similar to devices and specifiers), with the ultimate aim being to allow non-i18n coding systems such as gzip. there is a "chain" coding system that allows multiple coding systems to be chained together. (it doesn't yet have the concept that either end of a coding system can be bytes or chars; this needs to be added.) - unicode support. very raw. a few days ago i wrote a complete and efficient implementation of unicode translation. it should be very fast, and fairly memory-efficient in its tables. it allows for charset priority lists, which should be language-environment specific (but i haven't yet written the glue code). it works in preliminary testing, but obviously needs more testing and work. as of yet there is no translation data added for the standard charsets. the tables are in etc/unicode, and all we need is a bit of glue code to process them. see etc/unicode/README for the interface to implement. - support for unicode in windows is partly there. this will work even on windows 95. the basic model is implemented but it needs finishing up. - there is a preliminary implementation of windows ime support courtesy of ikeyama. - if you want to get cyrillic working under windows (it appears to "work" but the wrong chars currently appear), the best way is to add unicode support for iso-8859-5 and use it in redisplay-msw.c. we are already passing unicode codepoints to the text-draw routine (ExtTextOutW). (ExtTextOutW and GetTextExtentPoint32W are implemented on both 95 and NT.) - i fixed the iso2022 handling so it will correctly read in files containing unknown charsets, creating a "temporary" charset which can later be overwritten by the real charset when it's defined. this allows iso2022 elisp files with literals in strange languages to compile correctly under mule. i also added a hack that will correctly read in and write out the emacs-specific "composition" escape sequences, i.e. ESC 0 through ESC 4. this means that my workspace correctly compiles the new file devanagari.el that i added (see below). - i copied the remaining language-specific files from fsf. i made some minor changes in certain cases but for the most part the stuff was just copied and may not work. - i fixed post-read-conversion in coding systems to follow fsf conventions. (i also support our convention, for the moment. a kludge, of course.) - make-coding-system accepts (but ignores) the additional properties present in the fsf version, for compatibility. ------------------------------------------------------------------- -- ben-separate-stderr-improved-error-trapping this is an old workspace, very close to being done, containing - subprocess stderr output can be read separately; needed to fully implement call-process with asynch. subprocesses. - huge improvements to the internal error-trapping routines (i.e. the routines that call Lisp code and trap errors); Lisp code can now be called from within redisplay. - cleanup and simplification of C-g handling; some things work now that never used to. - see the ChangeLogs in the workspace. -- 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

forwarded message from Lionel Fourquaux 24 years

Stephen J. Turnbull

This will have to be fixed by the EFS maintainers. You should send all bug reports concerning packages to the appropriate maintainers. In many cases Lisp packages are externally maintained and we just distribute the packages.) Forwarding to the leading maintainer, just in case. In this case we appreciate the report here too, since obviously it's a generic problem with Lisp programs that any "expect"-type application will face. >>>>> "Lionel" == Lionel Fourquaux <lionel.fourquaux(a)wanadoo.fr> writes: Lionel> The problem seems to come from a localized message from Lionel> ftp.exe (the one that comes with Windows 2000). Is this message "localized" (ie, hard-coded) or "internationalized" (using switchable catalogs, with the appropriate language -- English -- available on your machine)? That is, suppose you set the environment variable "LANG" to "C". Do you then get the French message, or do you get English? The "right" solution to this kind of problem (short of AI) is to make the program speak the language that EFS expects. Emacs Lisp currently doesn't provide appropriate facilities for this, but it should. In the meantime, EFS can probably get away with temporarily setting LANG=C in Emacs's environment, starting the FTP process, then resetting it to whatever. (I don't know that the EFS maintainers will choose that solution, that's just the one I suggest.) In the long run, I think XEmacs should grab the user's locale out of the environment, stash it somewhere for reference (eg, to set up input methods), and then set its internal locale to "C" so that processes will start in a known state. -- 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."

10 participants
21 comments

something wrong in lazy-lock? 24 years

Katsumi Yamaoka

Hi, I was using the following setting in my XEmacs startup file. It is introduced in etc/sample.init.el. (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) (setq lazy-lock-stealth-time nil) I found there is something wrong with it. For example, the following code should return " *temp*" in any case. (with-temp-buffer (read-key-sequence "Press any key: ") (buffer-name)) However, the next one returns "*scratch*" when I evaluate the code in *scratch* buffer. (progn (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) (turn-on-font-lock) (make-frame) (with-temp-buffer (read-key-sequence "Press any key: ") (buffer-name))) Because of this, I often could not quit away from minibuffer after I entered the password using the function `read-passwd'. -- Katsumi Yamaoka <yamaoka(a)jpl.org>

1 participants
0 comments

speaking of non-profileration of types ... 24 years

Ben Wing

Given that I added a couple of types in my unsigned-removal patch, I think it's useful to consider anti-proliferating the types. Extcount could arguably be eliminated, though it provides some nice parallelism with Bytecount. Of course, what really should happen is some more general rethinking of the type names, in particular: [buffer positions, 1-based] Bufpos -> Charpos Bytind -> Bytepos Memind -> Mempos? [string positions or character data counts, 0-based] Bytecount Charcount Extcount -> Bytecount? Does it make sense to distinguish these two? [coded character data] Bufbyte -> Intbyte Extbyte [general] Element_Count Memory_Count Lstream_Data_Count -> Memory_Count? Does it make sense to distinguish these two? 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.

2 participants
2 comments

Sherlock Holmes Museum 24 years

Sherlock Holmes

1 participants
0 comments

21.5 (latest CVS) crash on hash-table-tests.el 24 years

Vin Shelton

Running 'make check' on an XEmacs 21.5 built from the latest CVS sources results in the following crash in the hash-table-tests. 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 (beta1) "anise" [Lucid] (sparc-sun-solaris2.5.1) of Mon Jun 25 2001 on ise4 configured using `configure --prefix=/u/shelton/new/SunOS-5.5/xemacs-21.5-2001-06-25-debug --with-gcc --site-includes=/u/shelton/new/SunOS-5.5/include --site-libraries=/u/shelton/new/SunOS-5.5/lib --infopath=/u/shelton/new/info --with-mule=no --compiler=gcc '--cflags=-O2 -pipe -ffast-math -fno-exceptions -g' --with-dialogs=no --with-widgets=no --package-path=/u/shelton/new/site-packages::/u/shelton/new/xemacs-packages --debug --error-checking=all' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Running the hash-table-tests from 'make check' caused XEmacs to crash. Recent keystrokes: misc-user Recent messages [Not really - this is a separate invocation of XEmacs] (most recent first): Loading efs-cu... Parsing /u/shelton/.mailrc... done Parsing /u/shelton/.mailrc... Loading mail-extr...done Loading mail-extr... Loading emacsbug...done Loading emacsbug... Loading emacs...done Loading pending-del...done Loading pending-del... Here is the C stack backtace: #0 0xeeef9e0c in _libc_kill () from /usr/lib/libc.so.1 (gdb) bt #0 0xeeef9e0c in _libc_kill () from /usr/lib/libc.so.1 #1 0x9b2cc in fatal_error_signal (sig=10) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/emacs.c:535 #2 <signal handler called> #3 free_hentries (hentries=0x6520666f, size=1070762936) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/elhash.c:409 #4 0x987c0 in finalize_hash_table (header=0x5c3200, for_disksave=0) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/elhash.c:422 #5 0x65550 in sweep_lcrecords_1 (prev=0x272c3c, used=0xefff9f1c) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/alloc.c:2537 #6 0x66558 in gc_sweep () at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/alloc.c:3118 #7 0x66b58 in garbage_collect_1 () at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/alloc.c:3501 #8 0xa3e64 in Feval (form=6290480) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:3203 #9 0x9f7ec in Fprogn (args=6290492) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:775 #10 0xa7b7c in unbind_to_hairy (count=33) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:4928 #11 0xa7a64 in unbind_to (count=33, value=2787332) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:4903 #12 0xa1100 in unwind_to_catch (c=0xefffba88, val=2604032) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:1372 #13 0xa11fc in throw_or_bomb_out (tag=6339092, val=6290720, bomb_out_p=0, sig=2787332, data=2787332) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:1455 #14 0xa1240 in Fthrow (tag=6339092, value=6290720) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:1494 #15 0xa2268 in signal_1 (sig=2788004, data=6290684) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:1995 #16 0xa23e4 in Fsignal (error_symbol=2788004, data=6290684) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:2101 #17 0xa2408 in signal_error_1 (sig=2788004, data=6290684) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:2110 #18 0xa2bd4 in maybe_signal_error (type=2788004, reason=0x2a8aa4 "\004\200", frob=6290684, class=2606080, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 76008012}) at /u/shelton/new/src/xemacs-21.5-2001-06-25-debug/src/eval.c:2337

1 participants
0 comments

CORE when closing gnuclient 24 years

Norbert Koch

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 (beta1) "anise" [Lucid] (i386-unknown-freebsd4.3, Mule) of Tue Jun 19 2001 on lamia.LF.net configured using `configure --prefix=/sw/i386_fbsd4/xemacs-21.5 '--site-includes=/client/include /usr/local/include' '--site-libraries=/client/lib /usr/local/lib' --use-union-type --with-mule --pdump' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Recently, I get a core dump when I close a gnuclient (-nw). This happens with a vanilla xemacs, ie xemacs -vanilla -nw -f gnuserv-start gnuclient -nw C-x 5 0 The C-trace reads #0 0x2861f8d4 in kill () from /usr/lib/libc.so.4 #1 0x80c863b in fatal_error_signal (sig=6) at emacs.c:535 #2 0xbfbfffac in ?? () #3 0x80cba4d in assert_failed (file=0x830ccc9 "events.h", line=505, expr=0x830cd20 "RECORD_TYPEP (obj, lrecord_type_command_builder)") at emacs.c:3314 #4 0x812e84a in execute_command_event (command_builder=0x8482700, event={...}) at events.h:505 #5 0x812f350 in Fdispatch_event (event={...}) at event-stream.c:4234 #6 0x80af23a in Fcommand_loop_1 () at cmdloop.c:583 #7 0x80af4e6 in command_loop_1 (dummy={...}) at cmdloop.c:494 #8 0x80cddeb in condition_case_1 (handlers={...}, bfun=0x80af4a8 <command_loop_1>, barg={...}, hfun=0x80af558 <cmd_error>, harg={...}) at eval.c:1692 #9 0x80af657 in command_loop_2 (dummy={...}) at cmdloop.c:256 #10 0x80d6074 in internal_catch (tag={...}, func=0x80af614 <command_loop_2>, arg={...}, threw=0x0) at eval.c:1317 #11 0x80aea92 in initial_command_loop (load_me={...}) at cmdloop.c:305 #12 0x80c9b91 in xemacs_21_5_b1_i386_unknown_freebsd4_3 (argc=3, argv=0xbfbff598, envp=0xbfbff5a8, restart=0) at emacs.c:2352 #13 0x80cbc8a in main (argc=3, argv=0xbfbff598, envp=0xbfbff5a8) at emacs.c:2719 #14 0x808cac9 in _start () norbert.

1 participants
0 comments

Whither bug-reports? 24 years

David A. Cobb

Since I have recently seen references to all of the following * crashes(a)xemacs.org * xemacsbugs(a)xemacs.org * xemacs(a)xemacs.org * xemacs-beta(a)xemacs.org Which is the destination for auto-generated bug reports that has the best chance of eventually improving the code? David A. Cobb, Software Engineer, Public Access Advocate, All around nice guy. Get my PGP key at :<http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit> Fingerprint=0x{6E3E_DB8C_2E8C_4248_62B2_FE29_08EE_CF0A_3629_E954} "By God's Grace I am a Christian man, by my actions a great sinner." --The Way of a Pilgrim, R. M. French [tr.] <---.----!----.----!----.----!----.----!----.----!----.----!----.---->

3 participants
2 comments

21.5.1 CVS, darwin, and gcc 24 years

Raymond Toy

I just tried compiling a CVS version of 21.5.1 on Mac OS X with X11 support. Config is ok, but when it compiles glyphs-x, gcc -O3 seems to hang. (I let it run for some 40 minutes). I stopped compilation and maually compiled that file with -O instead. This compiled quickly. The result works in tty mode. Haven't had a chance to try the X11 version yet. Ray

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