HDTenEightyP/NetNews huggingface dataset:
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Bug in lemacs setting of WM_NORMAL_HINTS
Organization: Bell Northern Research
Date: Tue, 12 Jan 93 18:36:11 GMT

I think I've discovered a bug with the values Lucid Emacs 19.3 sets in
the WM_NORMAL_HINTS property of a lemacs screen (X window).

I started my lemacs with a geometry of "80x48-5-5".

Lucid emacs translated this to the following:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 385, 193
		program specified size: 888 by 824
		program specified minimum size: 118 by 110
		program specified resize increment: 11 by 18
		program specified base size: 8 by 38
		window gravity: SouthEast

For starters, it is possible that the size should be marked as "user
specified" rather than "program specified", since *I* specified 80x48.

The main problem is with the size values themselves.  Look at the
following calculations of character sizes from the above pixel values.

    (Xsize - Xbase) / Xincr  = (888 - 8 ) / 11 = 880 / 11 = 80
    (Ysize - Ybase) / Yincr  = (824 - 38) / 18 = 786 / 18 = 43 

Note that the final Y size in characters is *not* the same as the size
in characters I specified when starting Lucid emacs.  (43 != 45).

It looks like the Ysize should really be 824 + 18 * 2 = 860.

This problem comes to light when HPVue is restarting lemacs using its
session management.  Vue seems to use the previous WM_NORMAL_HINTS and
lemacs starts up with 43 rows rather than 45.

I've poked around in the source code, but I'm not enough of an X guru
to come up with the answer.  I believe it might be something to do
with the fact that code was "Lifted almost entirely from ... in
Shell.c".  Perhaps something was overlooked.

Hoping for a solution,

Thanks,
 Hamish.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 14:46:04 EST
Subject: Lemacs-19.3:  Selecting deleted buffer
Date: Tue, 12 Jan 1993 14:50:24 EST
From: ramabs2@rpi.edu (Shiva Ramabadran)
Newsgroups: alt.lucid-emacs.bug
Hi,

   I've built Lemacs on SunOS 4.1.2 and Aix 3.2.1. It works very 
well for the most part. Great work! Thanks!!

   I've noticed an occassional problem where it prints the message
'Selecting deleted buffer' in the minibuffer and goes into an 
infinite beeping loop. It floods the X server with so many requests,
the fastest way I have of fixing it is to reboot the machine. Naturally,
this is not a solution I prefer.

   Applications like 'gnus' and mh-e which use multiple buffer's can 
trigger this problem. When you quit the application, it deletes all 
the buffer's that it was using. However, lemacs's history stack of 
recently visited (and available) buffers seems to get corrupted and 
it tries to switch to a buffer that does not exist, and then produces
the above annoying phenomena. 

   Has anyone else seen this problem ?  Is there a fix I can apply ? 
I really like lemacs, and don't want to go back to using emacs. 

   Thanks for any help you can offer. 


-Shiva
---
ITS Systems Programmer, Rensselaer Polytechnic Institute, Troy NY 12180.
Phone: (518) 276 8733. Fax: (518) 276 2809. Internet: shiva@rpi.edu.
From: dharding@pollux.lssec.bt.co.uk (Derek Harding)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: Strange bug with font-lock-mode
Date: 12 Jan 93 09:33:32 GMT
Organization: BT D&P London

In article <Pine.3.05.9301101435.C21289-a100000@trillian>, max@ccrl.nj.nec.com (Maximilian Ott) writes:
|> 
|> For a while now I ran into this strange, anoying one.
|> 
|> Set a buffer to c-mode and font-lock-mode and insert the following
|> 
|> ----------< begin of buffer
|> func()
|> 
|> {
|>   int x;
|> 
|>   if (x == 0)
|>     happy();
|> }
|> ----------< guess
|> 
|> If I do a "Querry replace: x with: y" I end up with:
|> 
|> -----
|> func()
|> 
|> 
|>   int y;
|> 
|>   if (xy == 0)
|>     happy();
|> }
|> -----

I have also noticed this problem. It occurs not only with query-replace, but with
replace-string. As far as I can tell it always inserts the replacement string after the
search string, and it only occurs in font-lock mode.

Derek
-- 

+------------------------------------+----------------------------------------+
| Derek Harding                      |                                        |
| London Engineering Centre, BT Labs | "Noone messes around with my brain ... |
| PP 6/3, Room 616 151 Gower Street  |  it`s my second favourite organ" -     |
| London WC1E 6BA                    |                                        |
|                                    |        Woody Allen (Sleeper)           |
| Tel: 071-728-7861                  |                                        |
| Email: dharding@lssec.bt.co.uk     |                                        |
+------------------------------------+----------------------------------------+
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 11 Jan 1993 13:38:15 EST
Subject: Re: Solution to buff-menu.el bug
From: Mly@lcs.mit.edu (Richard Mlynarik)
Fake-Sender: mly@adoc.xerox.com
Reply-To: Mly@lcs.mit.edu
Date: Mon, 11 Jan 1993 10:35:49 PST
Newsgroups: alt.lucid-emacs.bug
One should immediately discount any elisp code which includes "(require 'cl)"
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 6 Jan 1993 17:51:12 EST
Date: Wed, 6 Jan 1993 21:58:35 GMT
From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
Organization: W S Rupprecht Computer Consulting, Fremont CA
Subject: Re: Shouldn't the audio part be moved out of lemacs?
Newsgroups: alt.lucid-emacs.bug
The current lemacs method of opening /dev/audio directly is certainly
a nice hack.  It gives one builtin audio capability at very little
cost in code and complexity.  I use it all the time, (somewhat to the
dismay of co-workers I'm afraid).

Having said that, I think we should recognize it as just that, a nice
hack.  It isn't really a general purpose audio solution.  One
immediate problem is when lemacs *isn't* running on the local machine.
I often find myself running a second lemacs on a distant machine for
various reasons.  It would be nice to get sounds from this lemacs too,
but due to the constraint that all sounds data must go the the local
/dev/audio this unfortunately isn't possible.

I believe what we really need is the next level hack;-) a network
socket that emacs opens to the appropriate machine to send the audio
data down.  If done correctly this could even allow for multiple
simultaneous audio sources.  Is there already such a TCP port and
service specified?

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 17:59:45 EST
Date: Tue, 12 Jan 1993 14:59:04 PST
X-Windows: Power tools for power fools.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Solution to buff-menu.el bug
	<9301122117.AA07645@thymus.synaptics>
Newsgroups: alt.lucid-emacs.bug
I would like to see someone rewrite cl.el as several packages.  One for the
really small stuff like `when', `unless', and `pop'; one for the hairier 
control structures like `do'; one for `setf'; one for `defstruct'; etc.

The multiple-values stuff should be expunged.  The &key stuff should be
expunged.  So should most of the rest of it.  Implementing Common Lisp in
emacs-lisp is a fundamentally bad idea (not to mention doomed to failure.)
Implementing certain CL constructs which emacs-lisp has no trivially easy
way of simulating (like setf) has some merit.

Trying to implement a cl-compatible defstruct (constructors, etc) is a bad
idea.  You don't really need all that hair, and it is not a good fit with
emacs-lisp.

I don't think starting from the existing cl.el is a good idea, because that
code (pardon my bluntness) really really sucks.

If someone wants to take a stab at this they should become intimately familiar
with the byte compiler, hve a firm grasp on the differences between compile
time, macroexpand time, load time, and run time, and should know how not to
clutter up a namespace.  (I'm sure Daveg could handle it, but I just thought
that this needed to be said.)

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 6 Jan 1993 19:32:17 EST
Subject: Serious bug wrt floats and "equal" in 19.3
Reply-To: daveg@synaptics.com
Date: Wed, 06 Jan 1993 01:56:30 -0800
From: daveg@thymus.synaptics.com (Dave Gillespie)
Newsgroups: alt.lucid-emacs.bug
The "equal" function acts like "eq" when applied to two floats.
This is very wrong---it should test floats for numeric equality,
not for identical storage address.

For example: "(equal 3.0 3.0)" returns "nil".

In Fequal in fns.c, insert

#ifdef LISP_FLOAT_TYPE
  if (FLOATP (o1))
    return (XFLOAT (o1)->data == XFLOAT (o2)->data) ? Qt : Qnil;
#endif

at some suitable place to fix the bug.

This fix causes "(equal 0.0 -0.0)" to return "t" even on IEEE
machines that distinguish plus and minus zero, whereas the Common
Lisp standard says this should return "nil".  I don't think this
will be a big deal, though; anyway, it's not easy to distinguish
plus and minus zero portably in C, short of peeking at their bit
representations or sprintf'ing them.

Thanks,
								-- Dave
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Sun, 10 Jan 1993 15:03:58 EST
Date: Sun, 10 Jan 1993 14:55:35 -0500
From: max@ccrl.nj.nec.com (Maximilian Ott)
Subject: Strange bug with font-lock-mode
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Newsgroups: alt.lucid-emacs.bug
For a while now I ran into this strange, anoying one.

Set a buffer to c-mode and font-lock-mode and insert the following

----------< begin of buffer
func()

{
  int x;

  if (x == 0)
    happy();
}
----------< guess

If I do a "Querry replace: x with: y" I end up with:

-----
func()


  int y;

  if (xy == 0)
    happy();
}
-----

It is not always the same effect but the curly goes away almost everywhere
in the buffer. This even works with lemacs -q so it shouldn't be my own
changes. (19.3 it is)

Any ideas,

max


x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 7 Jan 1993 11:51:59 EST
Date: Thu, 7 Jan 1993 16:47:02 GMT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Re: motion events on mode lines
Newsgroups: alt.lucid-emacs.bug
Excerpt of message (sent 7 January 1993) by Jeff Sparkes:
> >> Another point is that there should be sth. like a
> >> mouse-{leaves,enter}-screen-hook, to be called when the mouse is
> >> leaving or entering an Emacs screen.
> >
> >That's what mouse-enter-hook and mouse-left-hook are.  But be careful not to
> 
> Shouldn't they both be the same tense?  It's inconsistent and annoying 
> this way.

   I agree, but also the problem would not have arisen if they had more
meaningful names. I suggest they be replaced by :

mouse-enter-screen-hook
mouse-leave-screen-hook

Do you agree?

--
Regards, David Hughes

44-223-872377x367
djh@cis.prime.com
COMPUTERVISION R&D Ltd, Harston Mill, Harston, Cambridge, UK
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 5 Jan 1993 17:53:10 EST
Date: Tue, 5 Jan 1993 14:50:50 PST
X-Windows: Sometimes you fill a vacuum and it still sucks.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Shouldn't the audio part be moved out of lemacs?
	<Pine.3.05.9301051642.D17104-c100000@trillian>
Newsgroups: alt.lucid-emacs.bug
Help Me!

   I'm on a Sun4 SPARC and SunOS 4.1.1.  The following resulted when
attempting to compile lucid; would appreciate any assistance you could
offer.

Trevor Wieman
Ford Microelectronics, Inc.
(719) 528-7683

make  -f xmakefile  all
/home/wieman/pub/gnu/bin/gcc -g     -Demacs  -I/usr/openwin/include  -I/net/enterprise/home/X11R5/usr/include -I./lwlib  -c  ScreenWidget.c
ScreenWidget.c: In function get_wm_shell:
ScreenWidget.c:201: dereferencing pointer to incomplete type
*** Error code 1
make: Fatal error: Command failed for target `ScreenWidget.o'
Current working directory /home/wieman/pub/prime/lucid/lemacs-19.2/src
*** Error code 1
make: Fatal error: Command failed for target `doall'
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 8 Jan 1993 16:02:13 EST
Return-Path: <sun001!mbattagl>
Date: Fri, 8 Jan 1993 14:20:27 CST
From: sun001!mbattagl@uunet.uu.net (M. Battagl)
Subject: Solution to buff-menu.el bug
Newsgroups: alt.lucid-emacs.bug
David,

I encountered a problem when trying your new buff-menu.el.
I had my lemacs running, and loaded your new buff-menu.el.  When I
execute it I get 'Symbol's function definition is void: unless'  Were
is this function?

Thanks,

Mike Battaglia
DSC Communications Corp
(214) 519-3253
mbattagl@dsccc.com
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 11 Jan 1993 05:01:23 EST
Date: Mon, 11 Jan 1993 09:53:30 GMT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Re: Solution to buff-menu.el bug
Newsgroups: alt.lucid-emacs.bug
In message <9301061609.AA09125@moebius.loria.fr> Guido Bosch wrote:
>
> Another point is that there should be sth. like a
> mouse-{leaves,enter}-screen-hook, to be called when the mouse is
> leaving or entering an Emacs screen.

That's what mouse-enter-hook and mouse-left-hook are.  But be careful not to
assume point-to-type focus policy: maybe what you want are select-screen-hook
and deselect-screen-hook.

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 04:50:44 EST
From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen)
Subject: Re: Solution to buff-menu.el bug
	<GAMIN.93Jan11180636@amadeus.ireq-robot.hydro.qc.ca>
Date: Tue, 12 Jan 1993 09:50:45 GMT
Newsgroups: alt.lucid-emacs.bug
> Many said that the 'cl package has problems -- and they are probably
> right, but the main problem is that those who make such claims can't
> pinpoint them and can't present examples.  If we are to fix those
> problems, please elaborate; 'cl is useful and certainly isn't beyond
> salvation.

% ls -l */cl.el*
-rw-r--r--   1 x11      logiciel    91006 Jun 30  1992 utils/cl.el
-rw-r--r--   1 x11      logiciel    50133 Jul 30 02:17 utils/cl.elc

I guess this is one of the problems.  Loading 50K of .elc just to get
the `unless' macro is certainly not economical.  It would have been
better to rewrite the two occurences of (unless foo bar) as (if foo
nil bar) or something like that.
-- 
Simon.
Newsgroups: alt.lucid-emacs.bug
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: Bug in lemacs setting of WM_NORMAL_HINTS
Organization: Bell Northern Research
Date: Tue, 12 Jan 93 18:57:39 GMT

I've just realized that there are some inconsistencies in my article.

>>>>> On Tue, 12 Jan 93 18:36:11 GMT,
>>>>> In message <1993Jan12.183611.3792@bmerh85.bnr.ca>,
>>>>> Hamish.Macdonald@bnr.ca (Hamish Macdonald) wrote:

Hamish> I started my lemacs with a geometry of "80x48-5-5".

Hamish> Lucid emacs translated this to the following:

Hamish>     (Xsize - Xbase) / Xincr  = (888 - 8 ) / 11 = 880 / 11 = 80
Hamish>     (Ysize - Ybase) / Yincr  = (824 - 38) / 18 = 786 / 18 = 43 

Hamish> Note that the final Y size in characters is *not* the same as
Hamish> the size in characters I specified when starting Lucid emacs.
Hamish> (43 != 45).

I'm not sure what lemacs actually does with my 80x48 specification.

Suffice it to say that I am happy with the size I get when specifying
this geometry.  I get 45 lines including the modeline and minibuffer
echo area, and not including the menubar.

The problem is when HPVue restores lemacs.  I end up with 43 lines
including the modeline and minibuffer echo area and not including the
menubar.  I lose 2 lines somewhere along the way.

Since no other X application has such an error and from my
calculations above I have concluded that the problem is with lemacs.

Hamish.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 19:20:45 EST
Date: Tue, 12 Jan 1993 16:20:18 PST
From: Aaron.Endelman@Eng.Sun.COM (Aaron Endelman)
Subject: Solution to buff-menu.el bug
Content-Length: 1166
Newsgroups: alt.lucid-emacs.bug
>Reply-To: daveg@synaptics.com
>Date: Tue, 12 Jan 93 13:17:12 -0800
>From: Dave Gillespie <daveg@thymus.synaptics.com>
>Content-Length: 1491
>
>Jamie writes:
>> I disagree; cl.el is indeed beyond salvation.
>
>Then here is a constructive thing to do about it:  Many people use
>cl.el for just a few convenience functions, like "cadr" and "incf".
>Why not include some of these in Emacs 19 directly, so that people
>will be less tempted to use cl.el?
>
>I'd recommend taking most of the "cadr"-like goodies and just
>tossing them into simple.el or something else that is always
>loaded.  Some day the byte compiler can be hacked to generate
>good byte codes for these, but for now just having them at all
>would be a big help.
>
>The one cl.el function I am most envious of is "list*".  I have
>need for it all the time, and it's so much nicer than nested
>"cons" calls.
>
>Same goes for "when", "unless", and "case".

I put in a vote for "dolist" and "dotimes".  Much easier then the
alternatives!  Please consider them if you do clean up cl.el.

Aaron

>If this sounds like a good proposal, I'd be willing to clean up
>cl.el in a suitable way.
>
>								-- Dave
>
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 5 Jan 1993 12:15:38 EST
Date: Tue, 5 Jan 1993 11:49:57 -0500
From: max@ccrl.nj.nec.com (Maximilian Ott)
Reply-To: max@ccrl.nj.nec.com (Maximilian Ott)
Subject: Shouldn't the audio part be moved out of lemacs?
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Newsgroups: alt.lucid-emacs.bug
The title says it all. Whith all those brain damaged audio APIs around,
wouldn't it make more sense to play audio through an external program?

The main problem now is that the audio output (at least on a sun) is not a
sharable resource. Furthermore, lemacs will (hopefully soon) become a full
X-client which requires the sound to "travel" as well. We don't have a
standard yet. Mark (boyns@sciences.sdsu.edu) made a nice step in the right
direction with rplay. However, it might be a bit too complex to use it as
default. 

By moving the "player" into an external program the audio part can envolve
independently.

One solution would be to use a interface similar to "ispell". Last night I
hacked up a simple program "eplay" which waits for the name of a sound
file, opens the audio port, plays it, closes the audio port and loops back
to the beginning. 

Through a command line flag (and in turn a user defined lisp variable) the
sound can be played through "rplay" instead. (rplayd needs some changes to
be fully usable, but that's easy)

The elisp interface should fit on a single page. (It is a bit messy as it
seems that the (only?) C-primitive ring_bell[_hook] is called within a few
built-in defuns: play-sound-file play-sound ding)

Before I take this any further I wanted to start a discussion about the
pros and cons of separating the audio part.

Regards,

max

---
Max Ott                 max@ccrl.nj.nec.com         phone: (609)951-2469
NEC C&C Research        Princeton, NJ, 08540        fax:   (609)951-2499





x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 11 Jan 1993 12:02:25 EST
Date: Mon, 11 Jan 1993 12:05:07 -0500
From: dodd@roebling.poly.edu (Lawrence R. Dodd)
Subject: v19.3 Lucid Emacs, quotes on *Buffer List*
Reply-To: dodd@roebling.poly.edu
Newsgroups: alt.lucid-emacs.bug
GNU Emacs 19.3 Lucid of Wed Sep  9 1992 on watergate (berkeley-unix)
 
list-buffers (C-x C-b) displays the buffer `*Buffer List*'
as `"*Buffer List*"' (note the double quotes). 

Is this intended? It causes errors in GTbuf-menu.el, the extended buffer menu
package.

Larry
dodd@roebling.poly.edu
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 11 Jan 1993 04:32:23 EST
Date: Mon, 11 Jan 1993 09:26:09 GMT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Re: Solution to buff-menu.el bug
Newsgroups: alt.lucid-emacs.bug
I think it's because of the Emacs menubar.

The initial geometry (in characters) is used to compute the size of the emacs
window and only later the menubar is inserted into the window.  Inserting the
menubar has the effect of changing the base_height as the menubar is not
something that resizes when you resize your emacs but I bet that the WM
properties are not updated in that case.


x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 7 Jan 1993 02:34:41 EST
From: dror@FibHaifa.com (Dror Caspi)
Subject: next/previous-line does not maintain current column.
Reply-To: dror@FibHaifa.com
Date: Thu, 7 Jan 1993 07:34:42 GMT
Newsgroups: alt.lucid-emacs.bug
As opposed to emacs-18.xx, when I use next-line or previous-line in
Lucid emacs 19.2, the current column is not maintained. Suppose you
are in column 60, then go up twice. If the line in the middle is only
40 characters long, then you'll end up in column 40, even if the last
line is longer.

This behaviour is annoying, but it may be due to some feature or deliberate
modification. In this case, a flag should be available to keep it working
the old way.

Any help is welcome.

Dror

#### ## #### ####  | Dror Caspi  
   #  #    #   #   | Fibronics Ltd, MATAM Industrial Park, Haifa 31905, Israel 
   #  #    #   #   | phone : +972-4-313655    fax: +972-4-550266/550550
                   | e-mail: dror@FibHaifa.com   or  dror@fibronics.UUCP
## #### ##### #### |----------------------------------------------------------
 # #  # #   #    # |
      # #   #    # |
   ###   ###  ###  |

x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 16:43:35 EST
Subject: Re: Solution to buff-menu.el bug
Reply-To: daveg@synaptics.com
Date: Tue, 12 Jan 1993 13:17:12 -0800
From: daveg@thymus.synaptics.com (Dave Gillespie)
Newsgroups: alt.lucid-emacs.bug
Jamie writes:
> I disagree; cl.el is indeed beyond salvation.

Then here is a constructive thing to do about it:  Many people use
cl.el for just a few convenience functions, like "cadr" and "incf".
Why not include some of these in Emacs 19 directly, so that people
will be less tempted to use cl.el?

I'd recommend taking most of the "cadr"-like goodies and just
tossing them into simple.el or something else that is always
loaded.  Some day the byte compiler can be hacked to generate
good byte codes for these, but for now just having them at all
would be a big help.

The one cl.el function I am most envious of is "list*".  I have
need for it all the time, and it's so much nicer than nested
"cons" calls.

Same goes for "when", "unless", and "case".

The sequence functions might be nice, but they're kind of bulky.
The multiple-value simulation is hokey and probably not very
important.

I note that cl.el defines functions like "floor" and "ceiling",
which will clobber Emacs 19's floating-point functions of the
same name.  Sigh.

The "setf" stuff would be *really* nice.  It should probably be
autoloaded the way the backquote package is.

The struct stuff could be handy, but again it's kind of bulky.
I guess you could autoload it through "defstruct", and put
"make$structure$instance" in simple.el.  Then only the compiler
would ever need to load must of the struct code.

If this sounds like a good proposal, I'd be willing to clean up
cl.el in a suitable way.

								-- Dave
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 6 Jan 1993 09:01:46 EST
Return-Path: <eaj@trionix.com>
Date: Wed, 6 Jan 1993 09:01:22 EST
From: eaj@trionix.com (Eric Jenkins)
Subject: lemacs and SS10
Newsgroups: alt.lucid-emacs.bug