October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Ben Wing

I've compiled a short list of bugs that I consider to be showstoppers for the 21.0 release. It's located at: http://devel.xemacs.org/xemacs/showstoppers.html Ben (typed by Martin)

6 participants
6 comments

Re: gud.el broken or is it just me? 23 years, 6 months

SL Baur

Aki Vehtari <Aki.Vehtari(a)hut.fi> writes in xemacs-beta(a)xemacs.org: ... > Btw. gud.el in XEmacs is dated 1993 and gud.el in emacs-20.3 is > dated 1998. Unfortunately gud.el in emacs-20.3 does not work in > XEmacs and I don't know much work it would need to make it work and I've done the initial port of gud.el to XEmacs. It mostly works[1], but it sorely lacks the functionality in gdbsrc.el. Making a gudsrc.el mode is on my list of things to do. It was in ftp://altair.xemacs.org/pub/xemacs-futures/ when I was on the 'net. It was delayed integration into the XEmacs packages pending 21.0 release. I also have a ported cua-mode.el to integrate. NOTE: The gud.el and cua-mode.el XEmacs portings are courtesy of Altrasoft, Inc. Thank you Altrasoft. Footnotes: [1] I have a report that my port does not work on Solaris with dbx.

2 participants
1 comments

RoboCup 23 years, 9 months

Akram Khodadadi

Hello Please answer my question. We maked a player in Linux with Lisp languaege ,but we dont know how to make a UDP connection between our player and the server with Lisp languaege. We looked in many sources ,but we didn't attain any affects. Please say to us for making a UDP connection and geting and sending messages with that Lisp languaege which orders . Please explan with an example. Thanks Mrs Khodadadi

3 participants
2 comments

Re: Bad addresses in wide reply. 24 years, 11 months

ShengHuo ZHU

>>>>> "Jérôme" == Jérôme Lacoste <lacostej(a)oslo.geco-prakla.slb.com> writes: Jérôme> Pterodactyl Gnus v0.96 Jérôme> XEmacs 21.1 (patch 3) "Acadia" [Lucid] (sparc-sun-solaris2.6) of Tue Jun 29 1999 on ardbeg Jérôme> 200 news.sinet.slb.com InterNetNews NNRP server INN 2.2.1 25-Aug-1999 ready (posting ok). Jérôme> I received a mail (cf RECEIVED MAIL section), with a header containing Jérôme> a lot of addresses. An error appeared when I tried to make a Wide Jérôme> reply (cf WIDE REPLY BUFFER section) : the mail server didn't accept Jérôme> the recipients (cf trace of SMTP session BUFFER). Jérôme> Gnus apparently processed badly the recipients, Jérôme> The error appears on the recipient Jérôme> "'Lacoste, Jerome (ORK)'" <lacostej(a)oslo.geco-prakla.slb.com>, Jérôme> which is shorten to "'Lacoste, Jérôme> Thus creating a parsing error (a '" is missing). [...] Jérôme> # start of WIDE REPLY BUFFER # Jérôme> ############################## Jérôme> To: "Eriksen, Kim Moore" <kim.moore.eriksen(a)folkehelsa.no> Jérôme> Cc: "'Ashton, Alan (ORK)'" <alan.ashton(a)unitor.com>, Jérôme> "'Bach-Gansmo, Tore (NRF)'" <tore.bach-gansmo(a)radiol.uu.se>, Jérôme> "'Bavridge, Nick'" <nickb(a)euroil.no>, Jérôme> "'Bjørkevoll, Johan (ORK)'" <johan.bjorkevoll(a)dnb.no>, Jérôme> "'Bressand, Jean Yves (ORK)'" <jyb(a)paellingsen.no>, Jérôme> "'Carriere, Stephane (ORK)'" <stephane.carriere(a)total.telemax.no>, Jérôme> "'Cooper, Colin (NRF)'" <ccolin(a)online.no>, Jérôme> "'Dalton, David'" <ddalton(a)se-as.no>, Jérôme> "'Davies, Jerry (NRF)'" <jdavies(a)eunet.no>, Jérôme> "'Deck, Bertrand (ORK)'" <bertrand.deck(a)hydro.com>, Jérôme> "'Demarest, Andre (ORK)'" <andre.v.demarest(a)no.pwcglobal.com>, Jérôme> "'Dinning, Jeff'" <jeff.dinning(a)get2net.dk>, Jérôme> "'Fogalele, Robin (ORK)'" <robin_fogalele(a)dmr.ca>, Jérôme> "'Gjertsen, Roar (NRF)'" <roar.gjertsen(a)iss-shipping.com>, Jérôme> "'Guvåg, Per Arne (ORK)'" <per.1395(a)online.no>, Jérôme> "'Hall, Keith (ORK)'" <keith.hall(a)winge.no>, Jérôme> "'Hodne, Per (NRF)'" <per.hodne(a)oslore.no>, Jérôme> "'Howells, J. Huw (ORK)'" <huw_jonathan_howells(a)dmr.com>, Jérôme> "'Johansson, Bradley (ORK)'" <bradley.johansson(a)avis.no>, Jérôme> "'Jones, Philip (ORK)'" <philip.jones1(a)chase.com>, Jérôme> "'Kittilsen, Jon (NRF)'" <jokittil(a)c2i.net>, "'Lacoste, "'Larsen, Jérôme> Øyvind (ORK)'" <oey-lar(a)online.no>, "'Laugerud, Jérôme> Eirik M. (ORK)'" <laueir(a)dph.no>, "'Lie, [...] It is a bug in `rmail-dont-reply-to'. The bug has been fixed in Gnu Emacs 20.4, while the bug still exists in XEmacs mail-lib (currently 1.24). (let ((rmail-dont-reply-to-names "test")) (require 'mail-utils) (rmail-dont-reply-to "a＠b, \"Last, First\" <test＠somewhere>")) => "a＠b, \"Last" It should be (as what does in Emacs 20.4) => "a＠b" -- Shenghuo

2 participants
1 comments

Re: (insert 8000) crashes XEmacs 21.2.16 25 years

SL Baur

Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes in xemacs-beta(a)xemacs.org: > xemacs -vanilla > (insert 8000) Ouch! -- 窓番号を入力してください

4 participants
4 comments

--pdump 25 years, 1 month

Hrvoje Niksic

I've just tried configuring with --pdump, and it worked. Of course, the build process failed because make expected to see an `xemacs' executable after dumping, but that's OK. I tried running `./src/temacs', and I got a working XEmacs. Wow. Almost unbelievable. :-) BTW, I notice that the hash-tables are "reorganized" after the undumping. Why is that?

2 participants
1 comments

menubar.c in current cvs doesn't like me 25 years, 1 month

Michael Harnois

/usr/src/xemacs-21.2/src/menubar.c:531: macro `DEFVAR_SYMVAL_FWD_OBJECT' used with too many (55) args make[1]: *** [menubar.o] Error 1 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin

1 participants
0 comments

Re: [bug report, 21.2] font-lock face inheritance 25 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I am slowly moving custom to specifiers, but it isn't that easy > unfortunately. I know how you feel -- I tried to do that, and I gave up. > 2. Specifier tags for _all_ domains. Customize uses 'dark and 'light > tags to have different color sets for different backgrounds. There > must be some way to turn those into specifier tags. The current > solution is a cop-out (basically emulating FSF frame-properties) > but a perfect solution would be dynamic and work per window. Note that it would be possible to compatibly add new specifier tags for all domains, e.g. by a new DOMAINS optional argument to `define-specifier-tag', or by a new function `define-specifier-tag-in-domains'. However, the problem is that the current specifier implementation has to be extended to support such on-the-fly fetching of relevant data. I believe Kirill did some work on this, but it was never finished.

1 participants
0 comments

Re: [bug report, 21.2] font-lock face inheritance 25 years, 1 month

Jan Vroonhof

[Olivier, I'm away. Please allow me to get back to you after having a real look] Ben Wing <ben(a)666.com> writes: > Hmm, I don't completely understand this, but it sounds like this caching > in get-custom-frame-properties is obviously wrong, right? The results > for one frame are clearly not the same as those for another frame -- this > is the whole point of specifiers! Also, does font-lock-comment-face have > tags associated with its values (e.g. (bold t) is tagged with 'mono, > etc.)? If not, that's also wrong. What may be is the problem, is that custom doesn't really use specifiers. It is really is trying some emulation of the FSF frame properties stuff. I am slowly moving custom to specifiers, but it isn't that easy unfortunately. For the current level of support there is the problem that we cannot use frob-face-property to set the size of the font. This would not be difficult but it needs to be done. What would be needed to move it to specifiers would be 1. A real font model (i.e. let the family, weight and size be individual specifiers). Somebody really should have a look at what FSF 21 will have. It is supposed to well design in this area. 2. Specifier tags for _all_ domains. Customize uses 'dark and 'light tags to have different color sets for different backgrounds. There must be some way to turn those into specifier tags. The current solution is a cop-out (basically emulating FSF frame-properties) but a perfect solution would be dynamic and work per window. > > Now, the question is, what is the Right Way[tm] to fix that? Customize is supposed to work around this by (which is Not the Right Way But Works) comparing the properties of each new frame against the "default" and the switching to using "frame properties", i.e. frame-locale specifiers, when the new one is different. I haven't checked why that is failing in your case. Jan

1 participants
0 comments

Re: Announcements 25 years, 1 month

Jason R Mastaler

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > If we take the current numbering system seriously, you just send > 21.1.x announcements to xemacs-announce, and 21.2.x announcements to > xemacs-beta. Exactly. I've gone ahead and implemented the nesting, so now all xemacs-announce messages will also go to both the xemacs (comp.emacs.xemacs) and xemacs-beta lists as well. For those of you who post announcements, please send Beta related messages to xemacs-beta and continue to send all other announcements to xemacs-announce. Thanks, and a Happy Halloween to all.

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