July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

John Eikenberry

unsubscribe -- John Eikenberry [jae(a)zhar.net - http://zhar.net] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin

1 participants
0 comments

IRIX binary-kit builder needed 26 years

Jason R Mastaler

We are in the process of preparing precompiled binary-kits for 21.1, but my regular IRIX binary-kit builder doesn't seem to be around these days. Is there anyone out there who compiles/uses XEmacs on IRIX fairly regularly and would like to help out the project with a binary-kit contribution? If so, please get in touch with me directly. If you want to know what you are getting into before committing, you can take a look at the instructions and materials for V21.1 binary-kit builders at: ftp://ftp.xemacs.org/pub/xemacs/beta/binary-kits/21.1/ Thanks.

1 participants
0 comments

"Stack overflow in regexp" 26 years

Justin Vallon

All, In a couple of places (compilation-mode, message-headers), I get errors about stack overflow in regexp pattern matching. The first one was in compile mode, which builds a looking-at regexp from: mode1\|mode2\|mode3\|...\|mode99. When given a compile line that is very long (lots of -I, ~>1000 chars), I get the error. I had figured that maybe the union of the regexps was too complicated for the regexp engine. However, I got some almost-department-wide email addressed to lots of recipients (~300), and got the error. The header-highlighting was barfing on a find-the-header regexp: highlight-headers.el:215: (looking-at "^\\([^ \t\n:]+[ \t]*:\\) *\\(.*\\(\n[ \t].*\\)*\n\\)") header ws : space field (continued field)* The regexp isn't that complicated, but it caused the highlighting to barf. Questions: a) Is there anyway to make the regexp stack larger? b) Does a larger regexp stack hurt performance? (a little memory isn't that expensive, but I wouldn't want to slow things down) I imagine these might be GNU regexp questions. -Justin vallon(a)mindspring.com

1 participants
0 comments

Re: XEmacs 21.1.4 (Arches) is released 26 years

Jason R Mastaler

SL Baur <steve(a)xemacs.org> writes: > > - always use a ＠xemacs.org address and an associated .sig (I think Ben > > suggested this a long time ago) > > I don't think this is a good idea because of address harvesting. Perhaps > a generic usenet posting address can be created that gets filtered to > /dev/null. This is an option. Alternatively, someone whose ＠xemacs.org address has already been harvested (like me) or who isn't bothered much by spam could make the usenet announcements. > (I don't currently have access to Usenet). As a reminder, e-mail sent to `xemacs(a)xemacs.org' will get automatically posted to comp.emacs.xemacs.

1 participants
0 comments

Re: XEmacs 21.1.4 (Arches) is released 26 years

Jason R Mastaler

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > - always use a ＠xemacs.org address and an associated .sig (I think Ben > > suggested this a long time ago) > > I have a problem with that. The address I use on Usenet has a spam > filter on it. I prefer not to post with official contact addresses. Understandable, but I think the release announcements should be done with an ＠xemacs.org address. If it helps any, mail.xemacs.org is quite aggressive with its anti-spam precautions.

1 participants
0 comments

Re: XEmacs 21.1.4 (Arches) is released 26 years

Jason R Mastaler

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes: > P.S.: who is the keeper of the ＠xemacs.org aliases/accounts? `postmaster(a)xemacs.org', or `list-manager(a)xemacs.org' for mailing list specific issues. These go to me, but always use the above aliases so someone can cover them when I go on vacation and stuff.

1 participants
0 comments

Re: XEmacs 21.1.4 (Arches) is released 26 years

SL Baur

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes in xemacs-beta(a)xemacs.org: ... > In my opinion we should rethink our presence on c.e.x (or our PR in > general). I makes me very sad if the public perception of the XEmacs team > is a bunch of debian-bashing hackers who don't care about their user > base. "debian-bashing hackers"? I guess I've gotten very out of touch. > I do answer a lot of questions on c.e.x (either on the list or more often > by email) and so do some others (especially Jan and Hrvoje come to mind). > I suggest we adopt a slightly modified policy on this: > - whenever possible send the first followup to a question to c.e.x and > offer to sort out detailed problems via email (I think I'm currently > helping three people through the XEmacs install process). This also > avoids duplication of effort (e.g. if Jan already told someone to read > README.packages then I don't have to repeat that). If you're going to take this kind of time, it's probably a better idea to post it so it gets archived by dejanews. Otherwise you are going to be answering the same questions over and over and over again. > - always use a ＠xemacs.org address and an associated .sig (I think Ben > suggested this a long time ago) I don't think this is a good idea because of address harvesting. Perhaps a generic usenet posting address can be created that gets filtered to /dev/null. (I don't currently have access to Usenet).

1 participants
0 comments

Re: [Success] XEmacs 21.1.4 "Arches", i386-pc-win32 26 years

Adrian Aichner

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >> Built from CVS on natively on Windows NT. >> Built info docs using my modifications to nt/xemacs.mak to generate >> info docs with XEmacs itself (no requirement to install texinfo). >> >> I believe a 21.2 bug which broke face specifiers has infiltrated >> 21.1.4. Jan> Are you sure you checked out 21.1.4? My specifier based custom stuff After time travelling all the way back to 21.1-b2 I was convinced that all those verions can't be broken. Here's the scoop, Jan: When the problem (http://www.xemacs.org/list-archives/xemacs-beta/9906/msg00235.html) first occured in 21.2-b16 I modified my .emacs like this: (custom-set-faces - '(default ((t (:family "Courier New" :bold nil :italic nil))) t) + '(default ((t (:background "white" :bold nil :italic nil))) t) '(gui-button-face ((t (:foreground "black" :background "white"))) t) This works fine with 21.2-b17+ with your frob-face-property patch applied. However, the new setting for face 'default does not work for 21.1-b2 21.1.3 21.1.4 Regards, Adrian Jan> isn't in 21.1.x (I checked using cvsweb: faces.el has stayed the same Jan> all the time) >> Jan fixed this bug for 21.2-b17++. I'll see whether the fix works for >> 21.1.4 too. Jan> So it works for you, that is nice. Jan> Jan

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 26 years

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: ... > Note that no editor on 32-bit systems can grok a >2G buffer because of > limited pointer size. Thus a 1G limit is just one step below the > "theoretical" limit. You can argue that being two steps below it is > not much worse, but I am not really convinced. O.K. Since size matters to you, how about another alternative? What would/could we gain or lose by using long long as EMACS_INTs on 32 bit architectures? -- 果報は寝て待て (All things come to those who wait)

3 participants
2 comments

Re: [Success] XEmacs 21.1.4 "Arches", i386-pc-win32 26 years

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Yes, your frob-face-property patch against 21.2-b17++ applied OK and > fixed the problem for system-configuration "i586-pc-win32". Thanks! I > just wanted to give it some testing before I got back to you. Ok thanks, I created the bug in the first place :-). copy-specifier could do with a better interface though. Jan

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