September 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > That's a bug, but deleting spaces (any ASCII space or tab > characters) in Japanese is data corruption, pure and simple. Don't > fix it by breaking Japanese. The Japanese fixed it by breaking English. And French. And Croatian. And... We'll revert to the state of affairs when things worked for European languages, and then we'll accept correct fixes for Japanese. Which is how we should have dealt with it in the first place.

1 participants
0 comments

XEmacs for WinNT 24 years, 7 months

Zheng, Shibo

Hi, Sorry to trouble you. In your main web page http://www.xemacs.org/ , it says that XEmacs will run on NT. I could not find how to and do not know who to ask. Could you help? Thanks, Shibo

1 participants
0 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: > Um, what bug, where, how? (I wasn't here yet in 20.0....) There are spurious blanks left at the end of lines when auto-filling English. It is most annoying.

2 participants
1 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > The problem here is that we don't know what language we're working on, > so the space is left in anyway. > > But that annoys the hell out of non-Asian users, so I think it's a > bug. I vote for reverting to old behaviour until a correct patch is > submitted. So it should depend on the language environment? With default to "no-spaces"? FWIW FSF Emacs seems to ditch the spaces. Jan

2 participants
1 comments

Making XEmacs a little faster 24 years, 7 months

Martin Buchholz

Unfortunately, I noticed in the gcc docs that gcc supports computed gotos in C. It goes on to say this: Another use of label values is in an interpreter for threaded code. The labels within the interpreter function can be stored in the threaded code for super-fast dispatching. So, of course I had to try using it in bytecode.c. It does make XEmacs faster, but not enough that it would be worth the annoyance of severely obfuscating the code. So this experiment was mostly a waste of time, albeit an instructive one. On the way, I did find a couple of small optimizations that speed up these lisp operations: (+ x y) (- x y) (1+ x) (1- x) (- x) 1999-09-16 Martin Buchholz <martin(a)xemacs.org> * lisp-union.h: * lisp-disunion.h: Define new, potentially faster INT arithmetic macros INT_PLUS, INT_MINUS, INT_PLUS1, INT_MINUS1 * bytecode.c (execute_optimized_function): Use new macros. * (meter_code) Fix bitrotted metering code. * bytecode.c (bytecode_negate): Optimize for integer case. Index: bytecode.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/bytecode.c,v retrieving revision 1.13.2.7 diff -u -r1.13.2.7 bytecode.c --- bytecode.c 1999/07/05 05:56:40 1.13.2.7 +++ bytecode.c 1999/09/17 01:52:55 ＠＠ -235,21 +235,17 ＠＠ Lisp_Object Vbyte_code_meter, Qbyte_code_meter; int byte_metering_on; -#define METER_2(code1, code2) \ - XINT (XVECTOR_DATA (XVECTOR_DATA (Vbyte_code_meter)[(code1)])[(code2)]) - -#define METER_1(code) METER_2 (0, (code)) - -#define METER_CODE(last_code, this_code) do { \ - if (byte_metering_on) \ - { \ - if (METER_1 (this_code) != ((1<<VALBITS)-1)) \ - METER_1 (this_code)++; \ - if (last_code \ - && METER_2 (last_code, this_code) != ((1<<VALBITS)-1)) \ - METER_2 (last_code, this_code)++; \ - } \ -} while (0) +static void +meter_code (Opcode prev_opcode, Opcode this_opcode) +{ + if (byte_metering_on) + { + Lisp_Object *p = XVECTOR_DATA (XVECTOR_DATA (Vbyte_code_meter)[this_opcode]); + p[0] = INT_PLUS1 (p[0]); + if (prev_opcode) + p[prev_opcode] = INT_PLUS1 (p[prev_opcode]); + } +} #endif /* BYTE_CODE_METER */ ＠＠ -259,12 +255,12 ＠＠ { retry: + if (INTP (obj)) return make_int (- XINT (obj)); #ifdef LISP_FLOAT_TYPE if (FLOATP (obj)) return make_float (- XFLOAT_DATA (obj)); #endif if (CHARP (obj)) return make_int (- ((int) XCHAR (obj))); if (MARKERP (obj)) return make_int (- ((int) marker_position (obj))); - if (INTP (obj)) return make_int (- XINT (obj)); obj = wrong_type_argument (Qnumber_char_or_marker_p, obj); goto retry; ＠＠ -643,7 +639,7 ＠＠ #ifdef BYTE_CODE_METER prev_opcode = this_opcode; this_opcode = opcode; - METER_CODE (prev_opcode, this_opcode); + meter_code (prev_opcode, this_opcode); #endif switch (opcode) ＠＠ -760,6 +756,7 ＠＠ opcode == Bunbind+6 ? READ_UINT_1 : READ_UINT_2)); break; + case Bgoto: JUMP; break; ＠＠ -997,11 +994,11 ＠＠ } case Bsub1: - TOP = INTP (TOP) ? make_int (XINT (TOP) - 1) : Fsub1 (TOP); + TOP = INTP (TOP) ? INT_MINUS1 (TOP) : Fsub1 (TOP); break; case Badd1: - TOP = INTP (TOP) ? make_int (XINT (TOP) + 1) : Fadd1 (TOP); + TOP = INTP (TOP) ? INT_PLUS1 (TOP) : Fadd1 (TOP); break; ＠＠ -1055,7 +1052,7 ＠＠ Lisp_Object arg2 = POP; Lisp_Object arg1 = TOP; TOP = INTP (arg1) && INTP (arg2) ? - make_int (XINT (arg1) + XINT (arg2)) : + INT_PLUS (arg1, arg2) : bytecode_arithop (arg1, arg2, opcode); break; } ＠＠ -1065,7 +1062,7 ＠＠ Lisp_Object arg2 = POP; Lisp_Object arg1 = TOP; TOP = INTP (arg1) && INTP (arg2) ? - make_int (XINT (arg1) - XINT (arg2)) : + INT_MINUS (arg1, arg2) : bytecode_arithop (arg1, arg2, opcode); break; } ＠＠ -1107,7 +1104,6 ＠＠ TOP = Fmemq (TOP, arg); break; } - case Bset: { Index: lisp-disunion.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lisp-disunion.h,v retrieving revision 1.9.2.2 diff -u -r1.9.2.2 lisp-disunion.h --- lisp-disunion.h 1999/04/22 07:27:23 1.9.2.2 +++ lisp-disunion.h 1999/09/17 01:52:55 ＠＠ -87,6 +87,10 ＠＠ #define XREALINT(x) ((x) >> INT_GCBITS) #define XUINT(x) ((EMACS_UINT)(x) >> INT_GCBITS) #define INTP(x) ((EMACS_UINT)(x) & Lisp_Type_Int_Bit) +#define INT_PLUS(x,y) ((x)+(y)-Lisp_Type_Int_Bit) +#define INT_MINUS(x,y) ((x)-(y)+Lisp_Type_Int_Bit) +#define INT_PLUS1(x) INT_PLUS (x, make_int (1)) +#define INT_MINUS1(x) INT_MINUS (x, make_int (1)) #define Qzero make_int (0) #define Qnull_pointer ((Lisp_Object) 0) Index: lisp-union.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lisp-union.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 lisp-union.h --- lisp-union.h 1999/04/22 07:27:23 1.8.2.2 +++ lisp-union.h 1999/09/17 01:52:55 ＠＠ -127,6 +127,11 ＠＠ #define EQ(x,y) ((x).v == (y).v) #define INTP(x) ((x).s.bits) +#define INT_PLUS(x,y) make_int (XINT (x) + XINT (y)) +#define INT_MINUS(x,y) make_int (XINT (x) - XINT (y)) +#define INT_PLUS1(x) make_int (XINT (x) + 1) +#define INT_MINUS1(x) make_int (XINT (x) - 1) + #define GC_EQ(x,y) EQ (x, y) /* Convert between a (void *) and a Lisp_Object, as when the

1 participants
0 comments

crash - latest cvs 24 years, 7 months

Jeff Miller

i recall people mentioning this before i think. just pulled cvs, and installed. xemacs seems to randomly disappear on me. wasn't there a problem with gnuserv/client that someone mentioned? i don't get a core or backtrace. it just disappears this time i noted that this error msg was display Error: Couldn't find per display information sound familiar?

1 participants
0 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Dan Harkless

[I am now subscribed to xemacs-beta and xemacs-mule, so no need to Cc me on further mails on this topic.] Olivier Galibert <galibert(a)pobox.com> writes: > On Thu, Sep 16, 1999 at 10:11:21PM +0200, Jan Vroonhof wrote: > > How good is your french? If I parse > > > > http://babel.alis.com:8080/glossaire/bouclage.fr.htm > > > > correctly, then kinsoku just means "line breaking". Which is not > > trivial as Japanese does not separate words with spaces. > > To be more precise, the kinsoku is a set of rules on when line breaks > are allowable in japanese, and also the name of the set of characters > near which it is forbidden to do the breaking (like just before a > comma). > > I still remember part of the flamew^Wdisscusison there has been after > the bug report. My original bug report? Well, not having been subscribed to the lists then, I hope I'm not retreading old ground below... > The justification for the space was "space is not equivalent to newline in > asian languages (while in european ones they can be exchanged freely) so > when there is a space, it should stay". Space in japanese is often used > to separate big blobs of kanas at (mostly, but not exactly) the end of > words, while a line break can happen anywhere in the words. Sounds reasonable, but should that introduce fuzziness into the concept of the fill-column? Shouldn't the auto-fill mechanism look backwards for the previous legal fill boundary and insert a newline there, preserving the user's space without making a line of fill-column + 1 characters? ----------------------------------------------------------------------- Dan Harkless | To prevent SPAM contamination, please dan-xemacs(a)dilvish.speed.net | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.

1 participants
0 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > I still remember part of the flamew^Wdisscusison there has been > after the bug report. The justification for the space was "space is > not equivalent to newline in asian languages (while in european ones > they can be exchanged freely) so when there is a space, it should > stay". The problem here is that we don't know what language we're working on, so the space is left in anyway. But that annoys the hell out of non-Asian users, so I think it's a bug. I vote for reverting to old behaviour until a correct patch is submitted.

1 participants
0 comments

Re: Huge auto-fill-mode bug intro'd in 20.0 still not fixed in 21.2.19 24 years, 7 months

Olivier Galibert

On Thu, Sep 16, 1999 at 10:11:21PM +0200, Jan Vroonhof wrote: > How good is your french? If I parse > > http://babel.alis.com:8080/glossaire/bouclage.fr.htm > > correctly, then kinsoku just means "line breaking". Which is not > trivial as Japanese does not separate words with spaces. To be more precise, the kinsoku is a set of rules on when line breaks are allowable in japanese, and also the name of the set of characters near which it is forbidden to do the breaking (like just before a comma). I still remember part of the flamew^Wdisscusison there has been after the bug report. The justification for the space was "space is not equivalent to newline in asian languages (while in european ones they can be exchanged freely) so when there is a space, it should stay". Space in japanese is often used to separate big blobs of kanas at (mostly, but not exactly) the end of words, while a line break can happen anywhere in the words. I don't really know what should be done. OG.

1 participants
0 comments

None 24 years, 7 months

Jeff Rancier

unsubscribe

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 September 1999