December 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Dan Holmsand

I don't think it's my fault... find-file-compare-truenames is just a variable, and my patch only gives it a new default value on windows. I don't see any of the functions I've changed in the backtrace. However, I don't have access to a Linux machine right now, so I'll have a hard time testing this myself. I'll try to look into this further tonight. /dan Martin Buchholz <martin(a)xemacs.org> writes: > On Linux, I get this crash on `make check'. > > This must be due to a very recent checkin to CVS (last couple of > days). Responsible party please fix. I thought Yoshiki was the > likely suspect, but right now this one looks like the one: > > 2000-08-31 Dan Holmsand <dan(a)eyebee.com> > > * buffer.c: Make find-file-compare-truenames default to true on > windows. > > * realpath.c (win32_abs_start): > (cygwin_readlink): > (win32_readlink): New functions. > (xrealpath): Return really real filenames on windows. > > * fileio.c (Ffile_truename): Make file-truename work on windows. > > given the occurrence of find-file-compare-truenames below. > -- Dan Ola Holmsand IB dan(a)eyebee.com

1 participants
0 comments

Re: GNU emacs feature 24 years, 1 month

Adrian Aichner

>>>>> "Foulds," == Foulds, Christopher <christopher.foulds(a)intel.com> writes: Foulds,> Hi: Foulds,> I have used both GNU Emacs and XEmacs and there is a feature in GNU Emacs Foulds,> that I don't see in XEmacs. It might be that I just don't know how to do it Foulds,> in XEmacs. The feature is as follows: Foulds,> In GNU Emacs, the user can have two buffers open with different files and Foulds,> then do a diff between the two files. The user can do this by choosing Tools-> Compare->Two Buffers... Foulds,> The user then hits enter twice to select both buffers that are displayed. Foulds,> The differences are then highlighted in the two buffers. Foulds,> Do you know if there is a way to do this in XEmacs? Sure. What is the version of XEmacs you use? You probably have to install the ediff package via Options -> Manage Packages -> Add Download Site SELECT A SITE NEAR YOU Options -> Manage Packages -> Update Package Index Options -> Manage Packages -> List & Install Best regards, Adrian Foulds,> Thanks, Foulds,> Chris Foulds -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

1 participants
0 comments

Fix widget buttons under motif 24 years, 1 month

Andy Piper

This makes button text appear normal under Motif. Its not a proper fix in that it disables accelerators, but I have no idea why the code doesn't work. If anyone understands Motif well, feel free to fix it properly. andy 2000-11-30 Andy Piper <andy(a)xemacs.org> * lwlib-Xm.c (xm_update_label): Hack to stop %_ labels until someone fixes it properly. -------------------------------------------------------------- Dr Andy Piper Principal Consultant, BEA Systems Ltd

1 participants
0 comments

Mule redisplay crash 24 years, 1 month

Gunnar Evermann

This is one of the oldest crashes on my to do list. loading the following in a vanilla Mule XEmacs will trigger a crash. (defun delete-and-split () (interactive) (delete-other-windows) (split-window)) (split-window-vertically) (insert "$B$,(B") (backward-char) (redraw-frame) (delete-and-split) Fatal error: assertion failed, file /deb-huge/home/gunnar/src/XEmacs/xemacs/src/objects.h, line 143, RECORD_TYPEP (obj, &lrecord_font_instance) #3 0x808eb81 in assert_failed (file=0x8218c60 "/deb-huge/home/gunnar/src/XEmacs/xemacs/src/objects.h", line=143, expr=0x8218d40 "RECORD_TYPEP (obj, &lrecord_font_instance)") at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/emacs.c:2825 #4 0x80c9db4 in error_check_font_instance (obj=136776524) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/objects.h:143 #5 0x81c730f in x_output_string (w=0x85a8c10, dl=0x8609808, buf=0x85e7640, xpos=4, xoffset=0, clip_start=4, width=16, findex=0, cursor=1, cursor_start=4, cursor_width=16, cursor_height=13) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-x.c:883 #6 0x81c60d5 in x_output_display_block (w=0x85a8c10, dl=0x8609808, block=0, start=0, end=1, start_pixpos=4, cursor_start=4, cursor_width=16, cursor_height=13) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-x.c:390 #7 0x81799c2 in redisplay_output_display_block (w=0x85a8c10, dl=0x8609808, block=0, start=0, end=1, start_pixpos=4, cursor_start=4, cursor_width=16, cursor_height=13) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:1088 #8 0x8178a28 in output_display_line (w=0x85a8c10, cdla=0x0, ddla=0x85e2668, line=1, force_start=4, force_end=20) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:751 #9 0x8179839 in redraw_cursor_in_window (w=0x85a8c10, run_end_begin_meths=1) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:1029 #10 0x81798be in redisplay_redraw_cursor (f=0x8577f00, run_end_begin_meths=1) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay-output.c:1054 #11 0x81760e9 in Fforce_cursor_redisplay (frame=139951872) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay.c:8938 #12 0x8176761 in text_cursor_visible_p_changed (specifier=137474936, w=0x85e8148, oldval=136988916) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/redisplay.c:9005 #13 0x81999b1 in recompute_one_cached_specifier_in_window (specifier=137474936, w=0x85e8148) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/specifier.c:2812 #14 0x8199b67 in recompute_all_cached_specifiers_in_window (w=0x85e8148) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/specifier.c:2854 #15 0x81d5e1e in Fset_window_buffer (window=140411208, buffer=137541312) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/window.c:3198 #16 0x81d6b4e in Fsplit_window (window=140151824, chsize=136988916, horflag=136988916) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/window.c:3503 #17 0x8094ed9 in Feval (form=140010872) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:2975 #18 0x8090870 in Fprogn (args=140010812) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:767 #19 0x8096629 in funcall_lambda (fun=140010896, nargs=0, args=0xbffff048) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:3497 #20 0x8095522 in Feval (form=140007804) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/eval.c:3081 #21 0x8146b51 in readevalloop (readcharfun=140386240, sourcename=139813548, evalfun=0x80947b0 <Feval>, printflag=0) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/lread.c:1448 [...] #43 0x808d520 in xemacs_21_2_b23_i586_pc_linux (argc=4, argv=0xbffffc34, envp=0xbffffc48, restart=0) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/emacs.c:1898 #44 0x808e0ab in main (argc=4, argv=0xbffffc34, envp=0xbffffc48) at /deb-huge/home/gunnar/src/XEmacs/xemacs/src/emacs.c:2323 The problem is that the face cache doesn't contain the font instance for the relevant charset or to be precise that the cache has been cleared but we do not regenerate the necessary entries. A quick fix for the crash would be adding a call to ensure_face_cachel_contains_charset() at the relevant place in x_output_string like this: Index: redisplay-x.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-x.c,v retrieving revision 1.23.2.17 diff -u -r1.23.2.17 redisplay-x.c --- redisplay-x.c 1999/10/15 10:11:51 1.23.2.17 +++ redisplay-x.c 1999/12/13 22:58:35 ＠＠ -879,10 +879,14 ＠＠ for (i = 0; i < nruns; i++) { - Lisp_Object font = FACE_CACHEL_FONT (cachel, runs[i].charset); - struct Lisp_Font_Instance *fi = XFONT_INSTANCE (font); + Lisp_Object font; + struct Lisp_Font_Instance *fi; int this_width; int need_clipping; + + ensure_face_cachel_contains_charset(cachel, window, runs[i].charset); + font = FACE_CACHEL_FONT (cachel, runs[i].charset); + fi = XFONT_INSTANCE (font); if (EQ (font, Vthe_null_font_instance)) continue; This works but is kindof expensive to do, as x_output_string is called very very often :-) Maybe our Mule and redisplay experts can try to come up with something more clever... Gunnar

3 participants
2 comments

crash when loading file which contains EUC-JP and ISO-2022-JP 24 years, 1 month

Mike FABIAN

Save the following attached file: (This file is only gzipped, because Gnus runs into an endless loop when I attach it without gzipping. That is probably also a bug, but a different one.). Gunzip it, start XEmacs and let it load this file: mfabian＠gregory:~/xemacs-bug$ LANG=ja_JP xemacs -q -vanilla kanji.euc-iso Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. It is important to use "LANG=ja_JP", it will not happen with "LANG=C". The file "kanji.euc-iso" contains only two lines. Both lines contain only the Japanese word "漢字" (Kanji). The first line contains this word in EUC-JP encoding, the second line in ISO-2022-JP encoding. The order of these lines is also important, if the ISO-2022-JP line comes first like in the gunzipped version of this file: XEmacs will not crash (but of course the EUC-JP part is unreadable). I encounter this problem often when opening Japanese *.patch files, which often contain both EUC-JP in some hunks and ISO-2022-JP in other hunks. If the EUC-JP comes first, XEmacs will crash. I use the following XEmacs version: In XEmacs 21.1 (patch 10) "Capitol Reef" [Lucid] (i686-pc-linux, Mule) of Mon May 8 2000 on nozomi configured using `configure --prefix=/opt/stow/xemacs-21.1.10 --with-mule=yes --with-dialogs=athena3d --with-xface=yes --with-wnn=yes --with-canna=yes --with-xim=xlib --with-xfs --with-menubars=lucid --site-includes=/opt/include --site-libraries=/opt/lib '--cflags=-g -O4 -fno-strength-reduce'' (The same problem also occurs with the XEmacs 21.1.12 from the SuSE rpm). Here is the lisp backtrace: And here is the C backtrace: -- Mike Fabian <mfabian(a)suse.de>

3 participants
4 comments

Re: Commenting out code in lisp 24 years, 1 month

Adrian Aichner

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> Deleting XEmacs Review from the CC list. >>>>> "APA" == Adrian Aichner <adrian(a)xemacs.org> writes: APA> Using double-semicolon will set up the same re-indentation APA> trap Stephen> Only if the surrounding code moves. The double semicolon Stephen> style should indent the first semicolon to the current Stephen> indent-column, and push all the blocked-out code 2 (or 3) Stephen> columns to the right. The lines get a little longer, but This is the problem I refer to. ;; comments so indented cannot be uncommented using C-u M-x comment-region. Using ;;; avoid this short-coming of C-u M-x comment-region. Do we want to make C-u M-x comment-region smarter? Stephen> not disasterously so unless the code is very deeply Stephen> nested in the first place. APA> and make uncomment-region impossible. Stephen> Not as long as it can assume that the region is Stephen> double-semicolon commented. That's not how C-u M-x comment-region works currently. Stephen> I don't know how much the existing code would have to Stephen> change. I don't oppose your proposal on the grounds that Stephen> ;; is better than ;;;, for sure. I just put it forward Stephen> as one I like better. I see your point. Maybe C-u M-x comment-region needs to become smarter. APA> If my proposal to comment broken or unneeded blocks of code APA> (if they shouldn't be deleted alltogether) by triple APA> semicolon makes sense, then we should make it the dafault. Stephen> Well, that kinda depends on whether we would screw up Stephen> usage outside of the core Lisp. I don't know anything Stephen> about that, but if people are used to the single Stephen> semicolon style, this would be something of a shocker. Stephen> :-) Not any more than re-indenting this from, ahem, lisp-mnt.el: (require 'picture) ; provides move-to-column-force ;(require 'emacsbug) ; XEmacs, not needed for bytecompilation APA> However, re-indenting XEmacs core lisp files (unless APA> otherwise noted explicitely) should be harmless and APA> desirable. Stephen> Please, no! Reindent code that you have to touch for Stephen> other reasons, OK. But gratuitous format changes create Stephen> distracting diffs and conflicts in update. I agree with you. But having to manually indent functions, just because someone else had used default XEmacs commenting on it before, is a real pain. Best regards, Adrian Stephen> -- Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 Stephen> _________________ _________________ _________________ _________________ Stephen> What are those straight lines for? "XEmacs rules." -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

2 participants
1 comments

GNU emacs feature 24 years, 1 month

Foulds, Christopher

Hi: I have used both GNU Emacs and XEmacs and there is a feature in GNU Emacs that I don't see in XEmacs. It might be that I just don't know how to do it in XEmacs. The feature is as follows: In GNU Emacs, the user can have two buffers open with different files and then do a diff between the two files. The user can do this by choosing Tools->Compare->Two Buffers... The user then hits enter twice to select both buffers that are displayed. The differences are then highlighted in the two buffers. Do you know if there is a way to do this in XEmacs? Thanks, Chris Foulds

2 participants
1 comments

Re: Attention Mule users... 24 years, 1 month

Nickolay Pakoulin

>>>>> "YH" == Yoshiki Hayashi <yoshiki(a)xemacs.org> writes: YH> Here's my version slightly differs from Nick's. I didn't give very close YH> look so I would be grateful if it could be merged to Nick's version. Your patch is nice and merged it with my changes but i have some questions, ok? Reading your patch I found that you decided not to define `string-as-unibyte' and `string-as-multibyte' functions. Could you explain your idea, please? May be these functions should be defined in mule core for compatibility reasons? YH> -- Yoshiki Hayashi Nick.

2 participants
1 comments

Re: Cannot install 21.2 from CVS after specifying --datadir 24 years, 1 month

Vin Shelton

Martin, --exec-prefix worked (I can build on SunOS-5.5 and 4.1 and share the shareable files), but it's not my preferred solution. Michael Sperber, please take a look at the --datadir problem with 21.2 at your earliest possible convenience. Thanks, vin >>>>> On Mon, 27 Nov 2000, Martin Buchholz <martin(a)xemacs.org> said: >>>>> "Vin" == Vin Shelton <acs(a)xemacs.org> writes: Vin> I routinely build XEmacs here at work on SunOS-4.1.4 and SunOS-5.5 in Vin> order to make sure no major breakage occurs between releases. I do Vin> not have sufficient time to spend major hours on this, but it provides Vin> a simple sanity check on 21.1 and 21.2 development status. Vin> Last week I decided it would be nice to share the Vin> architecture-independent data directories between the 4.1 and 5.5 Vin> builds. I have not been able to get this to work under 21.2 from CVS. Vin> In order to accomplish this, I'm specifying --datadir to configure; Vin> after doing this, 'make beta' and 'make check' work fine, but 'make Vin> install' fails. Here's how: MB> The canonical way to do this is to do MB> configure --prefix=$XEMACS_INSTALLDIR --exec-prefix=$XEMACS_INSTALLDIR/$ARCH MB> I did this many times back when I was in a corporate environment, MB> although not recently. MB> You can then either `make install' twice or make install once and then MB> `make install-arch-dep' for subsequent architectures. MB> This is not to say that what you're doing shouldn't work. Rewriting MB> install is one of the projects on my list. But I believe it is a MB> project, not just a bugfix. -- In a minute there is time For decisions and revisions which a minute will reverse. T.S. Eliot [URL: http://www.cs.amherst.edu/~ccm/prufrock.html]

1 participants
0 comments

Re: Attention Mule users... 24 years, 1 month

Nickolay Pakoulin

>>>>> "JV" == Jan Vroonhof <jan.vroonhof(a)ntlworld.com> writes: JV> npak(a)ispras.ru (Nick V. Pakoulin) writes: NVP> contains changes to ps-mule that I made to enable printing in russian. JV> This looks promising.. >> --- - Thu Nov 30 16:27:49 2000 >> +++ lisp/ps-print/ps-mule.el Thu Nov 30 15:12:55 2000 >> ＠＠ -143,8 +143,9 ＠＠ >> >> ;; For Emacs 20.2 and the earlier version. >> (eval-and-compile >> - (if (and (boundp 'mule-version) ; only if mule package is loaded >> - (not (string< mule-version "4.0"))) >> +;; (if (and (boundp 'mule-version) ; only if mule package is loaded +;; >> (not (string< mule-version "4.0"))) >> + (if (featurep 'mule) >> (progn (defalias 'ps-mule-next-point '1+) (defalias >> 'ps-mule-chars-in-string 'length) JV> This was to be expected This might be done as Yoshiki proposed: to add one more disjunk that takes care about xemacs case. >> +;;; The following commented code does not compile under XEmacs 21.2.36 >> +;;; npak(a)ispras.ru + >> [ Ethiopic support comment out] JV> Ok, we simply have no Ethoipic support >> ;; A charset which we are now processing. >> (defvar ps-mule-current-charset nil) ＠＠ -934,6 +939,10 ＠＠ >> (string-as-unibyte (cond ((coding-system-p encoding) (encode-coding-string >> str encoding)) >> + ;; XEmacs change npak(a)ispras.ru >> + ((and (symbolp encoding) >> + (find-coding-system encoding)) >> + (encode-coding-string str (find-coding-system encoding))) >> ((functionp encoding) (funcall encoding str)) JV> Hmm.. Do we have a slight API incompatibility here, i.e. can we not take JV> a coding system name in encode-coding-string? Anyway, it just another JV> minor problem. The problem is that ps-mule uses symbols as names for encodings. As I understand GNU Emacs allow names of coding systems in place of the coding systems. E.g. in GNU Emacs the following is evaluated to t while in XEmacs to nil: (coding-system-p 'iso-8859-5) In XEmacs one should transform it to: (coding-system-p (find-coding-system 'iso-8859-5)) >> (and (boundp 'enable-multibyte-characters) >> - enable-multibyte-characters >> + ;; FIXME >> + ;;enable-multibyte-characters JV> I think is again just a misguided FSF-specific mule test `enable-multibyte-characters' behaves rather strangely in xemacs. Sometimes it is t, but sometimes it is `nil'. I hit myself against it several times so I preferred to comment this test out. >> [From another message:] >> >> (define-coding-system-alias 'cyrillic-iso-8bit 'iso-8859-5) JV> I think was the essential bit... FSF Emacs has a whole bunch of different JV> names for coding systems. Ususal Emacs way ;(( JV> I think the core bits work. JV> Could you, just for laughs, try printing using the bdf fonts if you have JV> the intlfont package installed. It seems that bdf-fonts are the only way to print russian via ps-mule. I tried to set `ps-multibyte-buffer' to nil, non-latin-printer, bdf-font, bdf-font-except-latin and only the bdf variants worked on my box. JV> Jan Nick.

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 December 2000