HDTenEightyP/NetNews huggingface dataset:
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: min, max, and ANSI
Originator: krc@rac1.wam.umd.edu
Organization: University of Maryland at College Park
Date: Thu, 9 Apr 1992 16:58:59 GMT

I have a question about the ANSI C header stdlib.h. A certain compiler that
shall for the moment remain nameless includes macros for min(a,b) and 
max(a,b) in <stdlib.h>. Consequently, I managed to lose several hours
trying to find out why a working program suddenly broke---eventually
discovering, of course, that I had been using min as the name of a variable,
and had changed things hwen I #included <stdlib.h> for unrelated reasons.
Are min and max SUPPOSED to be in stdlib.h, and have I been just lucky
in avoiding this problem in the past?

Kevin Coombes <krc@math.umd.edu>
Newsgroups: comp.std.c
From: gordon@sneaky.lonestar.org (Gordon Burditt)
Subject: Re: ANSI C spec and GNU C preprocessing
Organization: Gordon Burditt
Date: Sun, 12 Apr 1992 03:12:37 GMT

>1) When a conforming preprocessor encounters a '#' directive which
>   is not listed in the preprocessor syntax (ex. '#foo'), what is
>   the correct behavior -- declare a fatal error, display a warning,
>   or pass it unchanged silently to the compiler?

There is no such thing as a 'conforming preprocessor'.  There is no 
ANSI-defined difference between different pieces of a compiler.
The output consists of warning/error messages and/or object code.
There is no ANSI-defined way to tell if a fatal error message came from
a "preprocessor" or a "compiler", whatever they are.  *SOMETHING*
needs to emit a diagnostic.  ANSI requires certain diagnostics and
permits others.  It is not at all clear that all ANSI-required diagnostics
should be fatal errors (The standard does not require it), so the
fatal/nonfatal line and the required/optional diagnostic line will
be drawn differently.

>2) A conforming preprocessor must output line directives (3.8.4)
>   in the format:

There is no such thing as 'a conforming preprocessor'.  Nothing
outputs line directives; a conforming implementation must accept them
as input.  There is no guaranteed way to even obtain something called
'preprocessor output', whatever that is.  Most implementations allow it, 
but there is no ANSI guarantee that you can obtain it, or that it
won't look like encrypted tokenized TRS-80 Model I BASIC.


>   'line'.  For example:
>
>	# 34 "myheader.h"

This form need not be accepted as input.  ANSI does not recognize the
existence of a 'preprocessor', nor 'preprocessor output', nor any
specified form of translating #line directives in one pass for use
by later passes.

					Gordon L. Burditt
					sneaky.lonestar.org!gordon
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Intermediate addr outside object: legal?
Date: 6 Apr 92 12:16:35 EDT

darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>In fact I don't think the standard even forbids "fn2(foo[-1000])"
>although your OS may complain (core dump) when you reference the data.

It is "forbidden":
In the section on Additive Operators, discussing the Semantics of pointer
arithmetic:  "If both the pointer operand and the result point to elements
of the same array object, or one past the last element of the array object,
the evaluation shall not produce an overflow; otherwise, the behavior is
undefined."

>>    } foo [10000];
>>    #define bar (foo - 8000)
>>        fn2(bar[9000]);		/* <---- */
>Chapter 3.3.2.1 says that E1[E2] is identical to "(*(E1+(E2)))."  After
>expanding macros the above becomes "(foo - 8000)[9000]" which is
>identical to "(*((foo - 8000)+(9000)))."  Removing superfluous parens
>that gives "*(foo - 8000 + 9000)" or "*(foo + 1000)" which looks
>perfectly legitimate to me.

The C abstract machine must perform the calculations as written in the order
specified by the syntax (3.3 Expressions, see footnote 35).  Implementations
are not obligated to simplify expressions when they can.  This expression
asks for the calculation of "foo - 8000" as an intermediate result, which is
illegal.
From: storm@cs.mcgill.ca (Marc WANDSCHNEIDER)
Newsgroups: comp.std.c
Subject: Re: const T **
Keywords: const
Date: 15 Apr 92 01:45:23 GMT
Organization: McGill University, Montreal, Canada

In article <1611@imec.UUCP> donne@imec.be (Werner Donne) writes:
>int
>main(void)
>
>{
>
>  const char **a;
>  char **b;
>
>  a = b;
>
>  return 0;
>
>}
>
>
>Why is the assignment illegal?

	As far as I can see, it isn't.  I ran it on cc for the NeXTs, gcc
running under SunOS 4.1.1 and as well, on MSC and Borland C++ 3.0 on my
PC in front of me...  Not one compiler even complained about the assignment.

	Perhaps you have a non standard compiler...?

	I'd be interested to see if this really IS an error, or just something
that your compiler barfed on....

-- 
  storm@cs.mcgill.ca           McGill University         C program run.  Run  
  Marc Wandschneider           Montreal, CANADA          Program run! PLEASE!
Ever wonder how Worf got to be Security Officer on the Enterprise when the 
Capt gets kidnapped from the bridge every two episodes and Troy Beats him up?
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.std.c
Subject: Re: const T **
Keywords: const
Date: 15 Apr 92 18:02:01 GMT
Organization: Twin Sun, Inc

jfw@ksr.com (John F. Woods) writes:

>Losing the compile-time diagnostic is regrettable,
>but note that there is no diagnostic required by the following:

>	#include <string.h>
>		*strchr("hammer me", ' ') = 0;

But this argument uses one botch in the C definition to justify another
proposed botch.  If C had C++-style overloaded functions (or better
yet, polymorphic functions), there would be no problem, because there
could be two versions of strchr:

	char *strchr(char *, int);
	char const *strchr(char const *, int);

and the above error would be caught at compile-time (assuming string
constants were changed to be of type char const *, not char *).  Since
C lacks such features, it must botch strchr's declaration; but that's no
excuse for also botching the semantics of pointer assignment.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Intermediate addr outside object: legal?
Date: 8 Apr 92 13:23:56 EDT

shankar@aspen.IAG.HP.COM (Shankar Unni) writes:
>This, of course, does not address the question of what is "the right
>thing to do" when the compiler sees this expression (the user-
>friendliness question).

The most "*user*-friendly" thing for a compiler to is to severely spank
*developers* who write nonportable, illegal code.  Eventually, *developers*
would start writing code with few enough bugs that *users* would enjoy
using it.

It should not be the compiler's job to *delay* bug reports.
From: bhoughto@hopi.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: What's EOF when sizeof(int)==sizeof(char)?
Date: 3 Apr 92 16:59:42 GMT
Organization: Intel Corp, Chandler, AZ

In article <1992Apr02.223752.4101@ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:
>In article <TT.92Mar31175445@tarzan.jyu.fi> tt@tarzan.jyu.fi (Tapani Tarvainen) writes:
>>As far as I can tell the standard allows int to be of the same size as char,
>>as long as it's at least 16 bits.  [But what about EOF being out of band?]

EOF is a negative integer that is not otherwise a recognized
character value.  It's up to the implementation to ensure
that there's no conflict between EOF and a recognizable
character.  As it stands, ^Z or ^D are in most terminal
conventions not `CHAR_MIN - 1', and it is up to the
terminal driver to convert the recognized character into
the proper EOF value for the processes that read the
stream.

There's no requirement for the value of SCHAR_MIN
to be the least value possible in the given bit-width.

If int and char are both 16 bits, it's still possible for
char to be considered `unsigned char', so long as the
`signed int' interpretation of the number allows for a
negative value for EOF.

"Out of band" necessarily requires a definition of "in band."

>This is actually an argument in favor of the viewpoint that X3J11 does *not*
>allow sizeof(int)==sizeof(char).  If it hasn't been done already, somebody
>should send in a Request For Interpretation.  I hope that the official answer
>is that such implementations are not legal.

What's wrong with it?  The implementation (plus platform
and OS) merely need to coordinate their use of the values
of the char type so that there's one that matches EOF and
it means end-of-file.

>I would not expect such a compiler to do well in the marketplace, anyway.
>Having a 16-bit char type means that there's way to access an 8-bit datum.
                                             ^no(?)

Of course, all of the character-retrieval functions
actually "access" 8-bit data by returning 16-bit data
and letting the programmer mask for 8 bits...

As for 9-bit char machines, I'd call them rather a
qualified success...

				--Blair
				  "We've got data hiding
				   and procedure hiding,
				   now all we need is
				   policy hiding..."
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: const T **
Keywords: const
Organization: Twin Sun, Inc
Date: Wed, 15 Apr 1992 01:43:09 GMT

jfw@ksr.com (John F. Woods) writes:

>it certainly seems to make sense to be able to
>assign a pointer-to-pointer-to-char into a pointer-to-pointer-to-constant-char.

Actually, it doesn't make sense to allow such assignments, because if you
allowed them, you could convert pointer-to-constant-char to pointer-to-char
without any cast or diagnostic, which leads to obvious problems.  Here's an
example.  (I write `char const' instead of `const char' because it's clearer if
you always make `const' follow the type that it modifies.)

	char const *c = "abc";
	char const **cc;
	char *p;
	char **pp = &p;
	cc = pp; /* violates C constraint */
	*cc = c;
	*p = 0; /* assigns to read-only storage */

If C allowed such assignments, the line marked ``violates C constraint'' above
would be strictly conforming C, and there would be no compile-time diagnostic
for the problem in the last line that (at least on my machine) makes the
program dump core.
From: dje@sspiff.UUCP (Doug Evans)
Newsgroups: comp.std.c
Subject: long long with #pragma ?
Date: 8 Apr 92 17:10:48 GMT
Organization: Edmonton, Alberta

fredriks@alexn.austin.ibm.com (Lars Fredriksen) writes:
>Hi,
>	I am probably out of my league here, but instead of typedefs and
>	long long or what have you, why not use the #pragma directives to
>	tell the compiler what size longs to use. This way a long is a long
>	is a long, and you can compile it the way you want it.

To me, this is an interesting idea (that doesn't necessarily mean much! :-).
I don't recall seeing "#pragma whatever" bashed about. Anyone?
-- 
Doug Evans                   |
..!{canada,uunet}!sspiff!dje | Vancouver 11, Calgary 0
dje@sspiff.UUCP (prefered!)  | There is no joy in Cowtown.
dje@ersys.edmonton.ab.ca     | But how 'bout those Canucks, eh?
From: 478clifton@gw.wmich.edu
Newsgroups: comp.emacs
Subject: Re: Emacs for OS/2 2.0
Date: 13 Apr 92 23:54:24 EST
Organization: Western Michigan University

IMHO recompiling Demacs to run under OS/2 would be a waste of all the
features of this OS that make it such an attractive replacement for DOS.
How about something closer to the original? Threaded makes come to mind.
Or how about a Epoch-like version to run under WPS?

Well, that might be to much to ask, at least at this point.
 
Newsgroups: comp.emacs
From: mills@ccu.umanitoba.ca (Gary Mills)
Subject: Re: Why won't my emacs v18.57 resolv any but full pathname files?
Organization: University of Manitoba, Winnipeg, Canada
Date: Fri, 17 Apr 1992 02:25:51 GMT

In <1992Apr16.063429.26250@ncar.ucar.edu> root@acd.acd.ucar.edu () writes:


>For us, emacs will not locate files in the current directory without
>providing a full pathname.

You probably have an PWD environment variable that is confusing emacs.
-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-
Newsgroups: comp.emacs,gnu.emacs.sources
From: cs201139@umbc5.umbc.edu (cs201139)
Subject: Emacs for IBM
Organization: University of Maryland Baltimore Campus, Academic Computing Services
Date: Thu, 9 Apr 1992 19:41:48 GMT

I was told that there is an emacs program for the IBM, but have no idea where
I can pick up a copy...If anyone can give me one it would be greatly
appreciated!

Newsgroups: comp.emacs
From: nickel@cs.tu-berlin.de (Juergen Nickelsen)
Subject: Re: Backspace Key
Reply-To: nickel@cs.tu-berlin.de
Organization: STONE Project, Technical University of Berlin, Germany
	<1992Apr12.231906.29069@fmsrl7.srl.ford.com>
Date: Mon, 13 Apr 1992 17:55:54 GMT

In article <1992Apr12.231906.29069@fmsrl7.srl.ford.com>
moconnor@pms704.pms.ford.com (Mike O'Connor) writes:

: In article <1992Apr12.220136.10412@ux1.cso.uiuc.edu>
: djn20624@uxa.cso.uiuc.edu (Danielson) writes:
: :	Is there some way to get the backspace key to actually be a backspace
: :key is emacs???  I usually work on an IBM type keyboard and the backspace
: 
: :	I heard that you need something like a 3 line script in your .emacs
: :file.  Does anyone know what those lines are to make the backspace key work??
: 
: Three lines?
: 
: (global-set-key "\C-h" 'backward-delete-char)
: 
: will do the job for you in .emacs.

Not quite, since the Backspace is still not the same as Delete if some
other mode redefines the Delete key to any other function than
backward-delete-char.

To make Emacs really *believe* the Backspace key sends a Delete, use
the following ONE line:
	(load "term/bobcat")

Or look into term/bobcat.el and make this code fit your special needs.

--
Juergen Nickelsen
From: rutges_ass@RUGB38.BDK.RUG.NL ("")
Newsgroups: comp.emacs
Subject: Problems applying the patches for MicroEmacs 3.11c
Date: 10 Apr 92 16:34:00 GMT

Hi all.

During updating MicroEmacs 3.11 to MicroEmacs 3.11c, I got the following error
during the compilation of MAIN.C. As I noticed, the errors should be the result
of alterations in the E*.H files. Maybe someone can tell me what went wrong?
(I am 100% possitive I applied the patches correctly, I even wrote a MicroEmacs
macro to substitute the PATCH command, so that I could check what was going
on! :-) )
The files that are INCLUDEd in main.c are:
<stdio.h>
ESTRUCT.H
EPROTO.H
EFUNC.H
EDEF.H
ELANG.H
EBIND.H

and as can be seen from the error I got, it all went wrong in the EBIND.H file.


		{CTRL|'A',		BINDFNC,	gotobol},
%CC-W-INVALINIT, The initialization of "keytab" is not valid.
		At line number 12 in 
                                    TWG$TMP:[000000.UEMACS.NEW.SOURCE]EBIND.H;1.

%CC-I-SUMMARY, Completed with 0 error(s), 1 warning(s), and
		0 informational messages.
		At line number 1069 in 
                                    TWG$TMP:[000000.UEMACS.NEW.SOURCE]MAIN.C;1.

Any help very much appreciated. I will be happy to supply more info, in which
case I recommend you to mail to me directly.

Greetings, and thanx.

Tijs Coumans
Computer Simulation + VAX/VMS Expert
Faculty of Management Studies, University of Groningen (The Netherlands)
Mail: RUTGES_ASS @ RUGB38.BDK.RUG.NL
------------------------------------------------------------------------
Disclaimer: All I say, is on my own behalf, not that of my employer's.
From: gardner-justin@CS.YALE.EDU (justin gardner)
Newsgroups: comp.emacs
Subject: auto-fill-mode in GNU emacs
Date: 7 Apr 92 20:40:36 GMT
Article-I.D.: cs.1992Apr7.204036.13594
Organization: Yale University, Department of Computer Science



I was wondering if there is some emacs program that makes fill mode work
right when you insert text into previous lines. I realize that you can
hit Meta-Q to re-fill the paragraph, but is there any way to have emacs
do this on the fly? Also, Meta-Q does not seem to work properly in
Lisp mode, since the semi-colons get all out of whack... Is there a way
to fix this?

please e-mail replys!

thanks,

justin
Newsgroups: comp.emacs,gnu.emacs.sources
From: price@helios.unl.edu (Chad  Price)
Subject: Re: Emacs for IBM
Organization: University of Nebraska - Lincoln
Date:  9 Apr 92 23:07:30 GMT

cs201139@umbc5.umbc.edu (cs201139) writes:

>I was told that there is an emacs program for the IBM, but have no idea where
>I can pick up a copy...If anyone can give me one it would be greatly
>appreciated!

"the IBM" ??? what operating system and what hardware??
chad
price@helios.unl.edu
From: janne@seita.oulu.fi (Janne Himanka)
Newsgroups: comp.emacs
Subject: Re: Need emacs (exes) for MPE on HP3000
Date: 11 Apr 92 23:56:57 GMT
	<GNU-Emacs-FAQ-2.92Feb23210646@bigbird.bu.edu>
	<1992Apr5.052917.3024@vicstoy.UUCP>
Organization: OPS --- Oulun PuolipalloSeura
In-reply-to: michaelc@vicstoy.UUCP's message of 5 Apr 92 05:29:17 GMT

>>>>> On 5 Apr 92 05:29:17 GMT, michaelc@vicstoy.UUCP (Michael Campbell) said:

	Michael> I would be willing to pay a finders fee to the first
	Michael> person who can point me in the right direction to
	Michael> acquiring emacs (any recent version) for the MPE OS
	Michael> running on an HP 3000 mini.  Reply here or to
	Michael> michaelc(at)obmarket.  Thanks in advance!

And I'll give warm thanks too! Micro Emacs is alright too. In point of
fact, *any* emacs. Or frankly, any decent full screen editor.

-Janne

Lone Ranger and Tonto were riding down the line,   + shem@phoenix.oulu.fi
fixing everybody's troubles, everybody's but mine, + himanka@tolsun.oulu.fi
someone must have told them that I was doing fine. + TKOP-HJH@FINOU


--
      Verba iactas           + shem@phoenix.oulu.fi TKOP-HJH@FINOU.BITNET
      ut imber aquas         + Oulu University, Dept. of Library & Inf. Sc.
      at cave! vacca volat.  + X.400: /C=fi/ADMD=fumail/PRMD=inet
                             + /O=oulu/OU=phoenix/G=Janne/S=Himanka
From: weber@chinook.cs.washington.edu (Eric Weber)
Newsgroups: comp.emacs
Subject: Re: What PURESIZE value will work best?
Date: 9 Apr 92 12:52:51 GMT
Distribution: comp
Organization: University of Washington


The PURESIZE variable controls the size of pure storage.  This storage
is used only for packages which are preloaded into emacs during the
compilation process, and not for packages loaded by users after
starting emacs.  Hence, if you don't get an error message when
preloading temacs, you have enough pure storage.   The impure storage
used for user loaded packages will expand as needed within the limits
of the operating system.

----------------------------------------------------------------------------
Eric Weber                                           weber@cs.washington.edu
----------------------------------------------------------------------------
Newsgroups: comp.emacs,comp.os.os2.misc
From: sip1@ellis.uchicago.edu (Timothy F. Sipples)
Subject: Re: Emacs for OS/2 2.0
Reply-To: sip1@midway.uchicago.edu
Organization: Dept. of Econ., Univ. of Chicago
Date: Tue, 7 Apr 1992 04:31:25 GMT

In article <1992Apr7.033241.13205@sura.net> vargish@sura.net (Nicholas Vargish) writes:
>(Any reference to OS/2 is to OS/2 2.0...)
>Having finally found the One True Editor (please, no religious
>flames), Emacs, I need to know if there is a version of Emacs for OS/2
>2.0 before I become willing to switch to the new OS. I will probably
>avoid buying OS/2 until there is something GNU-like enough that I can
>run GNU lisp scripts with only minor changes (like directory names)
>and use the same "nick.el" between my UN*X accounts at work and Demacs
>on my 386 at home.

I believe 32-bit full blown emacs for OS/2 2.0 is in alpha.  I also
believe Demacs is DPMI-compliant and, thus, will run just fine under
OS/2 2.0.

Your bases are covered.  (Someone correct me if I'm wrong on Demacs.)
-- 
Timothy F. Sipples       Keeper of the OS/2 Frequently Asked Questions
sip1@ellis.uchicago.edu  List, available via anonymous ftp from
Dept. of Economics       128.123.35.151, directory pub/os2/faq, or via
Univ. of Chicago  60637  netmail from LISTSERV@BLEKUL11.BITNET.
Newsgroups: comp.emacs
From: prichard@devon.larc.nasa.gov
Subject: MicroEmacs crypt mode question
Organization: Lockheed Engineering & Sciences Co.
Date: Tue, 7 Apr 1992 12:53:46 GMT


I am using MicroEmacs 3.11 on an IBM PC-XT clone.  I want to play around
with the crypt mode, but haven't figured out how to get it to work.

example session; do "emacs file1", go start crypt mode with esc-E, give
a encryption key, ^x^w to write buffer to file2.  but file2 is still
readable.

can anyone out there give me a hand?



--
 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 | Devon Prichard                     The four phases of public office; |
 | Designated Scapegoat                           Nomination, Election, |
 | Lockheed Engineering & Sciences Co.          Indictment, Conviction. |
 | prichard@devon.larc.nasa.gov                                         |
 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Newsgroups: gnu.emacs,gnu.emacs.source,comp.emacs
From: meggin@epas.utoronto.ca (David Megginson)
Subject: auto-fill in middle of par (source)
Organization: University of Toronto - EPAS
Distribution: comp
Date: 15 Apr 92 08:18:32
Originator: meggin@epas.utoronto.ca

(I place the code and discussion in this posting into the public
domain -- DPM).

Recently, someone asked about refilling a paragraph in auto-fill-mode
which inserting text into the _middle_ of a line. The following
function, which should be bound to the printing keys (alpha-numeric,
space, punctuation, etc), will do just that:

(defun self-insert-fill (n) 
  "Insert a character and fill."
  (interactive "p") 
  (self-insert-command n) 
  (let ((len (save-excursion (end-of-line) (current-column))))
    (if (> len fill-column) (fill-paragraph nil))))))

Basically, this function inserts the key's character as usual, then
checks the total length of the current line -- if it is greater than
the value of `fill-column', it calls (fill-paragraph) to refill the
paragraph (always unjustified, for now). I don't know a better way to
check the line length, but I would be very interested in knowing one
(it _must_ exist). If you always call (fill-paragraph), keyboard
response can just crawl. In this case, even though the function has a
_lot_ of overhead for each keystroke ((save-excursion) for example),
it can keep up with me (ca. 60wpm) even on my 8 MHZ Atari ST (well, it
slows down a bit when actually filling, but that is inevitable).

You will still have to decide where and when to bind this function to
the printing keys.


David

--
#################################################################
David Megginson                  meggin@epas.utoronto.ca
Centre for Medieval Studies      david@doe.utoronto.ca
University of Toronto            39 Queen's Park Cr. E.
#################################################################
From: michael@hpfcso.FC.HP.COM (Michael Schoonover)
Date: Wed, 8 Apr 1992 22:58:42 GMT
Subject: Re: Books....
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.emacs

Just a couple of corrections:

>         Title:          GNU Emacs:  UNIX Text Editing and Processing
                                                            ^^^^^^^^^^
                                                            Programming
>         Authors:        Michael Schoonover, John Bowie, Bill Arnold
>         Pubisher:       Addison-Wesley / HP Press*
>         Size:           640pp, 14 chapters, 4 appendices
>         ISBN:           0-201-56345-2
>         Price:          ?
			  ^
			  US$26.95

Michael S.
Xref: sparky comp.emacs:1979 gnu.emacs.help:2364
From: kolks@imec.be (Tilman Kolks)
Newsgroups: comp.emacs,gnu.emacs.help
Subject: Function-key bindings on Apollo ...
Keywords: Function-key Apollo emacs
Date: 9 Apr 92 14:23:39 GMT
Followup-To: comp.emacs
Organization: IMEC vzw, 3030 Leuven, Belgium

Hi there,

I would like to know how to bind
the function keys of my Apollo 3500 terminal to specific commands,
like binding F0 to 'repeat-matching-complex-command' etc etc...

Anybody knows how to do this (preferable in the .emacs file) ??

Post it, or send a mail to : kolks@imec.be

Thanks,

Tilman Kolks
"....I had a wonderfull live, shooting suspects with my .47  you know...."
 from Naked Gun 2 1/2.

 T. Kolks
 at IMEC
    Kapeldreef 75,
    3001, Leuven
    belgium
    Email: kolks@imec.be
Newsgroups: comp.emacs