July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

Sean MacLennan <seanm(a)storm.ca> writes in xemacs-beta(a)xemacs.org: > I then switched to an itimer and found what I believe is an inconsistency > with decode/encode-time. > `decode-time' produces a list of three (3) integers but `encode-time' > only produces a list of two (2) integers. Is this the correct > behavior? It makes it hard to use `itimer-time-difference'. Times are encoded very poorly in emacs. The split into two or three integers is a crock. I would very much like to see an API change and have time values as opaque objects. In the next few years, we're going to have to deal with Unix specs changing time_t into 64 bits (or whatever), so we might as well get the pain over with now.

1 participants
0 comments

font-lock faces 26 years, 4 months

Vin Shelton

I recently built up my first copy of 21.0 (b48) and I lost my font-lock X resources. Here's what I used to use: Emacs.font-lock-comment-face.attributeForeground: turquoise4 This no longer works. Changing 'Emacs' to 'XEmacs' does not help. The following works, but gives me a warning: Emacs*font-lock-comment-face.attributeForeground: turquoise4 The warning is: (1) (resource/warning) Bad resource specification encountered: something like Emacs*font-lock-comment-face.attributeForeground: turquoise4 You should replace the * with a . in order to get proper behavior when you use the specifier and/or `set-face-*' functions. What is the proper X resource hierarchy to use? thanks, vin

2 participants
4 comments

Re: What is /usr/dt/lib? 26 years, 4 months

Matt Simmons

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks(a)vt.edu> writes: Valdis> 2) It is a reasonable assumption that if a /usr/dt exists, that the Valdis> machine has CDE installed. As such, it's probably preferable to use Valdis> the Motif libraries found in /usr/dt/lib over any other Motif-oid Valdis> patterns of bits you may find, because the /usr/dt version is the one Valdis> that the vendor built to work with the CDE environment. You get /usr/dt with every Solaris 2.6 and 2.7 installation, regardless of which metacluster you select. You even get it if you select "Core System Support", which doesn't even have a Window system. In 2.5.1, you got SUNWdtcor with SUNWCuser (End User Support) and above. CDE was unbundled in 2.5.1, so you might run across a /usr/dt directory on a system without CDE installed. You'd have links to ToolTalk and PAM stuff, but not much else. I don't have any pre-2.5.1 images at home, so I can't check them. Matt -- Matt Simmons - simmonmt(a)acm.org - http://www.netcom.com/~simmonmt To attack a man for talking nonsense is like finding your mortal enemy drowning in a swamp and jumping in after him with a knife. --Karl Popper

1 participants
0 comments

Re: key bindings from the user's point-of-view 26 years, 4 months

SL Baur

Marc Aurel <4-tea-2(a)bong.saar.de> writes in xemacs-beta(a)xemacs.org: ... > Actually my goal is to be able to use XEmacs without having to learn > elisp (hey, you need that kind of beta-tester, too, right?). You are absolutely correct. We need testers like you as a sanity check.

1 participants
0 comments

Re: Iceberg, right ahead 26 years, 4 months

SL Baur

Olivier Galibert <galibert(a)pobox.com> writes in xemacs-beta(a)xemacs.org: > On Fri, Jul 17, 1998 at 03:42:40AM -0700, SL Baur wrote: >> My available time for XEmacs has dwindled to a minimum. > How should we parse that exactly ? Pick one :-) O.K. > 1- I now have a time problem which is going to cause difficulties with > the 21.0 release but some time after it will be ok again > 2- There's no hope in sight, but I can still manage pre-21.0 and > 21.1+betas if I don't have to go with the burden of actual releases > (announces, binaries, etc...) and if you do X, Y and Z instead of > having to do it myself > 3- There's no hope in sight, and you should seriously look for someone > else to replace me > Note that this is far from a critic of what you do (actually, I think > that 3/ would suck badly) but the semantics of your message are not > clear for the non-native english speaker I am... Sorry about that. #1 is closest to what I meant.

1 participants
0 comments

Re: Iceberg, right ahead 26 years, 4 months

Michael Harnois

Olivier Galibert <galibert(a)pobox.com> writes: > How should we parse that exactly ? Pick one :-) > the semantics of your message are not clear for the non-native > english speaker I am... No, actually, you did an excellent job of teasing out the various ambiguities in the message. You don't need to be the least apologetic. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)sbt.net aa0bt(a)aa0bt.ampr.org Earth has its boundaries, but human stupidity is limitless. -- Gustave Flaubert

1 participants
0 comments

Re: font-lock faces 26 years, 4 months

Greg Klanderman

these seem to be working fine for me... XEmacs.default.attributeForeground: white XEmacs.default.attributeBackground: midnightblue XEmacs.modeline.attributeForeground: midnightblue XEmacs.modeline.attributeBackground: white XEmacs.gui-element.attributeBackground: gray XEmacs.primary-selection.attributeBackground: green4 XEmacs.isearch.attributeBackground: blue emacs-version = "21.0 \"Zhong Wei\" XEmacs Lucid" solaris 2.5.1, openwin greg >>>>> "acs" == Vin Shelton <acs(a)alumni.princeton.edu> writes: acs> acs> I recently built up my first copy of 21.0 (b48) and I lost my font-lock acs> X resources. Here's what I used to use: acs> acs> Emacs.font-lock-comment-face.attributeForeground: turquoise4 acs> acs> This no longer works. Changing 'Emacs' to 'XEmacs' does not help. acs> The following works, but gives me a warning:

1 participants
0 comments

Iceberg, right ahead 26 years, 4 months

SL Baur

My available time for XEmacs has dwindled to a minimum. A 21.0 release this month looks very remote. I'm going to try to have things ready by some time next month. Um, if anyone has any ambition on taking over XEmacs, please let me know. We're not done delegating responsibility, so I'm not desperate yet, but I'm getting close. Delegating out specific releases has worked (thank you Vinnie Shelton!), so perhaps it might work the other way. In the meantime, I've got places to put future patches to XEmacs that are not suitable for the current release and I encourage developers to continue on with new features if they wish. Please mark your patches "for XEmacs 21.2" so there won't be any confusion.

3 participants
2 comments

Xemacs b48/Cygwin/Windows 95 bails to shutdown completely 26 years, 4 months

David Bush

Something has changed between b46 and b48. I have always started xemacs from the cygwin bash command line and up to now it has shutdown cleanly. With b48, I exit and the window goes away, but there is still something running. System performance goes into a tailspin. If I bring up the End Task screen there is still an entry for Xemacs. When I kill it, system performance improves and bash comes back to life. Note I am not using runemacs. david

1 participants
0 comments

Re: scheme - my opinion 26 years, 4 months

Jerry James

On 17 Jul 1998 at 09:11:43 +0200, sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) wrote: > Jerry> Common Lisp is not inherently incompatible with tail recursion > Jerry> elimination. > > I never said that, and you're quoting both of us out of context. The > issue was emulation of Scheme inside Common Lisp. Once you lose > tail-recursiveness, you can't get it back. I did, in fact, lose track of the context of your remarks, for which I apologize. I knew you had never said that, but that wasn't the point I wanted to make anyway. To make that point, I'll have to digress for a moment. > Since the standard does not mandate proper tail recursiveness, and > since not all implementations have it, you cannot rely on it being > present in general Common Lisp programming. This has a strong impact > on programming style. That is absolutely correct. But, are we talking about replacing the elisp substrate with *any* [Common Lisp/Scheme] engine, or with *some particular* engine? If the former, then you have to program against the lowest common denominator which, in the case of Common Lisp, does not include tail recursion elimination. My impression, though, is that the latter is intended. In that case, if the intention is to provide a Common Lisp substrate and a Scheme emulation on top, then it would be wise to pick a Common Lisp implementation that does tail recursion elimination. In that case, I see no reason why you could not provide a Scheme emulation that also provides tail recursion elimination. Note that this is independent of whether extension programmers take advantage of the TRE capabilities of the Common Lisp substrate or not (i.e., whether they program for general Common Lisp implemenations, or optimize for the specific engine chosen). So, the point I was trying to make with my previous message is that Common Lisp implementations that do TRE actually exist. If Common Lisp is judged to be a desirable replacement for elisp, then one could identify TRE as a necessary (or at least highly desirable) property of the specific implementation chosen. Two more things, in random order: (1) I am still interested in a further clarification of call/cc vis-a-vis lexical closures. (2) Do not consider me, by any means, a Common Lisp proponent. I am merely trying to be helpful by providing some bits of information that I happen to have in my head. I share the concerns of some others, namely that: (a) Free CL implementations seem to be having a hard time moving from CLtL1 to CLtL2, much less to full ANSI compliance (and this is true of CLISP in particular); and (b) CL may be too heavyweight for an XEmacs implementation. Regards, -- Jerry James Email: jerry(a)cs.ucsb.edu WWW: http://www.cs.ucsb.edu/~jerry/

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 1998