July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: support of bidirectional text? 25 years, 5 months

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > > Eli Za????? > > --- retsky ii

1 participants
0 comments

Re: psgml menus to work under window-system mswindows 25 years, 5 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> I have fixed this at long last! APA> Please advise me about the disposition of this patch. Hello Reviewers, could someone please comment on the status of my patch? I would really like to see it adapted to make PSGML work in an MSwindows XEmacs. Regards, Adrian APA> Under MSwindows, no HTML elements or entities could be APA> inserted via the context-sensitive menues. APA> MSwindows and X people, could you please verify this, thanks! APA> Is is correct that package functions do not need to undergo APA> the obsoletion process? I have removed APA> sgml-xemacs-get-popup-value, which is no longer needed. APA> Here are ChangeLog and patch against CVS repository. APA> Regards, APA> Adrian APA> 1999-06-13 Adrian Aichner <aichner(a)ecf.teradyne.com> APA> * psgml-xemacs.el (sgml-popup-menu): Use APA> `get-popup-menu-response' APA> instead of APA> `sgml-xemacs-get-popup-value'. APA> (sgml-xemacs-get-popup-value): Remove this unused APA> function.

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 5 months

SL Baur

Justin Vallon <vallon(a)mindspring.com> writes in xemacs-beta(a)xemacs.org: ... > Is `long long' ANSI? Further, is it guaranteed that sizeof(long long) > > sizeof(long)? I don't know, that's why I asked. I _know_ I don't like the other alternative I was presented with and that was to use a struct with two 32-bit ints as a Lisp Object. -- 蛙の子は蛙 (Like father, like son)

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 5 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> We aren't developing crappy commercial software here, > Hrvoje> after all. :-) > > Right. That's why we should do UCS-4 exactly right, and avoid > getting into "my buffers are bigger" can-you-piss-over-this-line > contests. No, we should get the buffers right and avoid UCS-x pissing contests. Your argument doesn't hold water here and I don't like Mule screwing the rest of us. > BTW: I don't care if Zed has .75GB buffers, or you do, or somebody > is simply trying to determine the period of (psychoanalyze-pinhead); > I think they're important. Just not as important to me, and I > believe to Mule-dependent people in general, as UCS-4. I think this conversation is starting to revert me to my original train of thought, that Mule is not the be-all end-all of everything. There are other people using XEmacs, and Mule advocates will have to realize that one of these days. > Yes. UCS-4 is going to be the standard unified character type in > the near future. It can handle all foreseeable needs for plain > text. Now your argument resembles to those of Markus Kuhn. The important question is whether UCS-4 is acceptable for our internal representation. To me it seems that it's not, regardless of whether it's the "standard unified character type" (ed is the standard editor, anyway). > >> o XEmacs will never again (well, for a future longer than the > >> history of electronic computers) need to change the abstract > >> format for a Lisp character. > > Hrvoje> This is true without UCS-4 too. It's only the > Hrvoje> implementation that changes. > > Unfortunately, probably not true. Current Mule representation has > probably reached the end of the line; we're running out of code > space. But who cares about that? You're not supposed to be relying on the value char-int returns, right? Right. The whole idea behind a character type is that things can be changed without breaking everything in sight.

2 participants
1 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 5 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> What does direct UCS-4 support in characters buy me > Hrvoje> anyway? Will it be another case of all-encompassing Mule > Hrvoje> priorities breaking the neck of the rest of us? > > It buys you direct UCS-4 support in characters. And what does that buy me? Are we running in circles here? > o XEmacs will never again (well, for a future longer than the > history of electronic computers) need to change the abstract > format for a Lisp character. This is true without UCS-4 too. It's only the implementation that changes. > o Mule backwards compatibility. Lisp code that relies on a particular representation of characters is broken in the first place. > Sure, those may not excite you. They don't excite me at all. 700M buffers excite me. Whose 700M buffer is this? Zed's. Who's Zed? Zed's dead baby. Zed's dead... > Hrvoje> right, you have to modify all the C code that relies on > Hrvoje> Lisp_Object integers fitting in an integral type called > Hrvoje> "EMACS_INT" (int or long). And there's a *lot* of such > Hrvoje> code, with possibly long integers propagating all over the > Hrvoje> place. > > ...I don't see that it has to be done all at once. How else would you do it? Bignums are not just another opaque data type -- they have to be done right. Unless, of course, you are satisfied with half-assed solutions a la Python or, for that matter, C. > You can (partially) implement a bignum type, and implement it where > it helps somebody. Places where it has not yet been implemented > will throw a type error automatically if you try to pass them in; Don't you get it? It breaks any hope of large buffers working with bignums. Integers get propagated all over the place. If you take the easy way out and throw type errors in XINT, you could as well not bother in the first place. That's why I never tried to add them. > Hrvoje> Also, with bignums avaialble, you would probably want to > Hrvoje> provide compiler declarations so that reasonably > Hrvoje> efficient code can be written, i.e. (declare (fixnum > Hrvoje> x)). > > Sure. But again, that's a project that can be put off until it > matters to somebody. (Maybe; I realize that it's possible that > checks for bignums will slow everything down and everybody will > care. But then the --with-bignums=no option wins.) --without-bignums never wins. Either do it right or don't do it at all. We aren't developing crappy commercial software here, after all. :-)

3 participants
3 comments

Re: [crash] Opening frame across ssh from inside a screen. 25 years, 5 months

SL Baur

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes in xemacs-beta(a)xemacs.org: > Why was there no stacktrace eye catcher in your backtrace, anyway? Overly > aggressive inlining by egcs? Yup, this has been known since the day we put that "feature" in. We should probably rename sort_args in the same way we renamed main_1. -- 窓番号を入力して下さい。 (recorded keybox message at ETL)

1 participants
0 comments

Re: building 21.2 with no-x fails 25 years, 5 months

SL Baur

This is a known problem, but I don't know what the hold up is about getting the fix in. At any rate, it will continue to delay b18 until it is fixed ... Jeff Miller <jmiller(a)smart.net> writes in xemacs-beta(a)xemacs.org: > glyphs.c:2930: parse error before `struct' > glyphs.c:2930: `image' undeclared here (not in a function) > glyphs.c:2930: initializer element for `glyph_description[0].offset' is not cons > tant > make[1]: *** [glyphs.o] Error 1 > make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' > make: *** [dump-elcs] Error 2 > probably an ifdef based on whether X is available is missing. -- 蛙の子は蛙 (Like father, like son)

1 participants
0 comments

Re: support of bidirectional text? 25 years, 5 months

William M. Perry

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes: > On 1 Jul 1999, Jan Vroonhof wrote: > > > "Uwe Brauer" <oub(a)eucmos.sim.ucm.es> writes: > > > > > As I understand it this would keep the text, written from the > > > left-to-the-right but displayed vice versa. Now it is supposed that > > > GNUemacs 20.4 will have something like this, but it is not clear when > > > it will be released. > > > > Are you sure about the version number? > > > > Eli Za????? said in March that he was thinking about it. Progress > > must have been extremely fast then. > > didn't Handa-san actually demo this?? I seem to remember seeing it. I don't remember seeing it, but I missed part of handa-san's demo that day, so may simply have been out of the room. > > It is more likely they meant 20.5 which is going to contain the new > > end-to-all-problems mystical display engine. > > :-) Has anyone actually ever seen that thing? Is there maybe even > something like design document available somewhere (e.g. on the "secret > FTP site")? Or is writing stuff like that just not the way FSF Emacs > development is done? I've seen it. :) If you want to actually see some of the code that takes advantage of it, look at 'font.el' in the latest Emacs/W3 releases. It works just fine with the new redisplay engine, which is really quite sexy. I haven't worked much with the graphics stuff, but I need try and patch PNG support into it in the next month or so. I'm not supposed to give out the URL to the source to public lists, but if anyone wants it, lemme know and I can email it to you privately. Gerd Moellmann is the one working on it. -Bill P.

1 participants
0 comments

a 3rd build failure for 21.2 25 years, 5 months

Jeff Miller

this is the configuration i use to test building with lesstif ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -mal ign-jumps=2 -malign-functions=2' '--with-dialogs=motif' '--with-menubars=motif' '--package-path=/usr/local/lib/xemacs/packages-21.0' '--with-scrollbars=motif' I get this error: scrollbar-x.c: In function `update_one_scrollbar_bs': scrollbar-x.c:189: `XtNuseBackingStore' undeclared (first use this function) scrollbar-x.c:189: (Each undeclared identifier is reported only once scrollbar-x.c:189: for each function it appears in.) make[1]: *** [scrollbar-x.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 jeff

1 participants
0 comments

another 21.2 failure 25 years, 5 months

Jeff Miller

Doing a minimal build fails as well for me. ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -mal ign-jumps=2 -malign-functions=2' '--with-database=no' '--with-dialogs=none' '--w ith-gif=no' '--with-gpm=no' '--with-jpeg=no' '--with-menubars=none' '--with-offi x=no' '--package-path=/tmp' '--with-png=no' '--with-scrollbars=none' '--with-shl ib=no' '--with-sound=no' '--with-toolbars=no' '--with-tiff=no' '--with-xface=no' '--with-xpm=no' gives this error: glyphs-x.c: In function `x_widget_instantiate': glyphs-x.c:2184: `popup_selection_callback' undeclared (first use this function) glyphs-x.c:2184: (Each undeclared identifier is reported only once glyphs-x.c:2184: for each function it appears in.) make[1]: *** [glyphs-x.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 I think this is because the menubars are compiled out. jeff

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