August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Where do you want to go tomorrow? 27 years, 1 month

William M. Perry

SL Baur <steve(a)xemacs.org> writes: > [My previous message was not blank.] > > Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > > > karlheg(a)inetarena.com (Karl M. Hegbloom) writes: > mts> You really *do* need that blank line after the headers. > >> > >> Hmmm. I'm using `gnus'. > > > Do you have the famous `--text follows this line--' in your message > > buffer ? > > Messages with initial indented text lines are having those lines > swallowed into the headers by Majordomo. Ewwwhhh -bill p.

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years, 1 month

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > karlheg(a)inetarena.com (Karl M. Hegbloom) writes: mts> You really *do* need that blank line after the headers. >> >> Hmmm. I'm using `gnus'. > Do you have the famous `--text follows this line--' in your message > buffer ?

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years, 1 month

Didier Verna

karlheg(a)inetarena.com (Karl M. Hegbloom) writes: > mts> You really *do* need that blank line after the headers. > > Hmmm. I'm using `gnus'. Do you have the famous `--text follows this line--' in your message buffer ?

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years, 1 month

Karl M. Hegbloom

>>>>> "mts" == Mike Scheidler <c23mts(a)eng.delcoelect.com> writes: mts> "Michael" == Michael Sperber mts> <sperber(a)informatik.uni-tuebingen.de> writes: Michael> Michael> PS: Karl, quite a few posts of yours end up empty out Michael> here. Maybe something is wrong with your MUA? mts> I noticed this too, and looked at the apparently-empty mts> messages outside of my mail tool. They each consist of a mts> single paragraph with no blank line between the message mts> headers and the body. Also, multi-paragraph messages show mts> up, but with the first paragraph missing. mts> You really *do* need that blank line after the headers. Hmmm. I'm using `gnus'.

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years, 1 month

Mike Scheidler

"Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: Michael> Michael> PS: Karl, quite a few posts of yours end up empty out here. Michael> Maybe something is wrong with your MUA? I noticed this too, and looked at the apparently-empty messages outside of my mail tool. They each consist of a single paragraph with no blank line between the message headers and the body. Also, multi-paragraph messages show up, but with the first paragraph missing. You really *do* need that blank line after the headers. -- Mike Scheidler c23mts(a)eng.delcoelect.com Corporate Software Technology Delphi Delco Electronics Systems PHONE: (765) 451-0319 Kokomo, IN 46904-9005 GMNET: 8-322-0319

1 participants
0 comments

vertical-motion and point 27 years, 1 month

Pekka Marjola

The NEWS file claims that vertical-motion is corrected in 21.0. Then how I can use the new position (see below)? (defun test-v-m (&optional buf) (let* ((buf (or buf (current-buffer))) (win (get-buffer-window buf t))) (save-excursion (set-buffer buf) (goto-char (point-min)) (princ (point)) (princ " ") (vertical-motion 1 win) (point)))) ; Run in *scratch* (test-v-m) -> 1 28 (test-v-m (get-buffer "*mail to xemacs-beta(a)xemacs.org*")) -> 1 1 20.4 gives different results for the second test... -- Pekka Marjola * pema(a)iki.fi * http://www.iki.fi/pema/ * PGPid 0x2865206D

1 participants
0 comments

Re: Two silly XEmacs questions 27 years, 1 month

Didier Verna

"Amir J. Katz" <amir(a)ndsoft.com> writes: > 2. When a new version of a package is released, is it enough to > unpack it, then do this: > > rm lib-src/DOC > gmake It's better to remove all preceding lisp files at least before unpacking it. I sometimes got duplicates by just unpacking on top of the former one. As for your particular question, I remember having to remove src/xemacs too in some cases. But I think the Makefile has been fixed. --didier

2 participants
1 comments

a custom oddity a custom oddity a custom oddity 27 years, 1 month

Didier Verna

Gee, I thought I entered an infinite loop while saving a customization buffer, but that was not the case actually: I edited about 12 faces at once with custom. I pressed the global `save' button, and custom started to save options.el 12 times !! (13 actually: it calls the :custom-save widget property for all chagned faces, and then calls custom-save-all) :-/ :-/ --didier-didier-didier-didier-didier-didier-didier-didier-... done

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years, 1 month

Michael Sperber

>>>>> "Karl" == Karl M Hegbloom <karlheg(a)inetarena.com> writes: >>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "Reggie" == Reggie Perry <Reggie.Perry(a)digital.com> writes: Reggie> There are several arguments for common lisp. Michael> I claim that migration to Common Lisp is roughly as Michael> expensive as migration to Scheme. Karl> But the theses was that Common Lisp is a better language for Karl> developing large software products with. Well, that's a different issue. Both are important and interesting. Note that we only want to develop one very specific large software product. Karl> So perhaps it "costs" the same to get to the point where you Karl> can start writing code in the new language, but one is better Karl> than the other for creating complex interworking systems. (For Karl> code developers, system administration, process control Karl> interfaces, ... (tell me what else! I'm interested.)) Both languages have been used for complex interworking systems. The issues are not as clear-cut. For example, let's take Common Lisp's package system, one of the things most commonly cited as qualifying Common Lisp for large systems development. Let's have slightly closer look: What can a package/module system do? 1. name space management 2. separate compilation/linking 3. separation between interface and implementation to support maintenance, multiple developers, and high-level abstraction 4. describing parameterized software architectures and instantiating them Of these, the Common Lisp package system achieves at most the first two. (It certainly allows for separate compilation, but that is largely independent of the package system, as far as I can tell.) However, 3. and 4. are extremely helpful in developing complex software. XEmacs *is* a highly parameterized application. The reason why Scheme doesn't have a standardized module system is that 1. and 2. just by themselves are not enough, and 3. and 4. are hard. However, - Scheme 48's module system does 1, 3, and 4. The planned new module system does all 4. - MzScheme's module system does all 4. - Gambit's name space management system does 1 and 2. - RScheme's module system does 1 and 2. (Jamie used to bitch about CL's package system all the time, though I'm not sure he ever substantiated his rants.) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla PS: Karl, quite a few posts of yours end up empty out here. Maybe something is wrong with your MUA?

1 participants
0 comments

Re: [ EXPERIMENTAL PATCH ] package-get mods for local files (CDROMS) 27 years, 1 month

SL Baur

Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes in xemacs-beta(a)xemacs.org: > Darryl Okahata wrote: >> >> This patch fixes the package-get routines to optionally look on a >> local disk for packages. Basically, package-get-remote was modified to >> allow for a system name of `nil', in which case the directory is taken >> to be a local directory. > [snip] > I think that this is a good thing in general, not just for mswindows > users. I agree. ... > More fundamentally, is there any reason why add-big-package.sh should be > a Bourne shell script? It doesn't have to be. I coded it that way because it was faster and easier to verify as a shell script. Having it available as a shell script also allows for a nonXEmacs-based package configureer/installer. I don't see any reason why a version of it can't be done in Lisp. > It doesn't appear do anything that couldn't easily be done in > lisp. If we implemented the current add-big-package.sh in lisp > inside package-admin-add-binary-package, we wouldn't have to invent > package-admin-default-install-function or > package-admin-install-function-mswindows and our mswindows problems > would go away. O.K. With me.

3 participants
2 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 August 1998