HDTenEightyP/NetNews huggingface dataset:
If I double click or drag to make an active selection,
then it seems that the selection is automatically copied to the clipboard.
(19.3 shows the same behaviour.)

This prevents me from replacing the current selection with the content of the clipboard.

But if I put something on the clipboard and then use an interactive function call, like M-x mark-defun,
than the whole selected defun can be replaced with the "old" clipboard content.

Shouldn't the activating of a region and the copying be separated functions?

Also I seem to loose my active region as soon as my popup-menu pops away,
this in contrast with the use of the menubar-menu which let me keep the active region 
after it pops up and away. (I apopogize for my English...)

I am using the "pending-del" package.

Regards, Frank.

---------------------------------------------------
Frank Siebenlist                 <franks@ntu.ac.sg>
---------------------------------------------------
Newsgroups: alt.lucid-emacs.bug
Subject: BUG: Lucid seems to still do background write in 19.4
From: bobhays@spss.com (Bob Hays)
Date: Tue, 26 Jan 1993 17:46:38 GMT
Organization: SPSS Inc.

SYSTEM: AIX 3.2.2

Seems that Lucid is still doing a background write in V. 19.4.  I
thought this was one thing fixed in 19.4 - guess I was wrong?

Thanks and have fun! - Bob

P.S.  People on AIX should, with 19.4, be able to build with almost no
problems whatsoever. - RLH

-- 
===============================================================================
The opinions expressed above are those of Bob Hays and not SPSS, Inc.
 bobhays@spss.com  Phone: (312) 329-3529 | "I'm hovering like a fly, waiting
                   Fax:   (312) 329-3657 |  for a windshield on a freeway" -PG
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Sun, 24 Jan 1993 09:56:37 EST
Date: Sun, 24 Jan 1993 14:55:14 GMT
From: djh@CIS.Prime.COM (David Hughes)
Subject: Re: Solution to highlight-headers problem in lemacs19.4
Newsgroups: alt.lucid-emacs.bug
Excerpt of message (sent 24 January 93) by David Hughes:
> Various people have complained that vm and gnus breaks under lemacs19.4 due
> to "highlight-headers-regexp having no value" and that a "sensible" default
> value should have been set up etc, etc.
> 
> The solution is quite simple :
> 
> At the bottom of highlight-headers.el add the line
> 
> (provide 'highlight-headers)
> 
> and at the top of vm-lucid.el and gnus-lucid.el add the line
> 
> (require 'highlight-headers)

I forgot to add that the following should be replaced in vm-lucid.el

(defun vm-highlight-headers (message window)
  (let ((highlight-headers-regexp (or vm-highlighted-header-regexp
                                      highlight-headers-regexp)))
    (highlight-headers (marker-position (vm-start-of (car vm-message-pointer)))
		       (marker-position (vm-text-of (car vm-message-pointer)))
		       t)))

--
Regards, David
From: bcotton@sergei.MITRE.org (Bob Cotton)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: _vendorShellWidgetClass: mutiply defined?
Date: 25 Jan 93 19:02:26 GMT
Organization: MITRE Corp. McLean Va.


leamcs is dying in _XmUnitTypeDefault at a macro XmIsManager which is defined to be

#define XmIsManager(w)		XtIsSubclass(w, xmManagerWidgetClass)

I recompiled motif with debugging and gdb says the following....
0x12cdcc in _XmUnitTypeDefault (widget=0x419c00, offset=177, value=0xf7ffc07c)
    at ResInd.c:1337
1337        if (XmIsManager(widget->core.parent))
(gdb) where
#0  0x12cdcc in _XmUnitTypeDefault (widget=0x419c00, offset=177,
    value=0xf7ffc07c) at ResInd.c:1337
#1  0x25a318 in _XtCreateIndirectionTable ()
#2  0x25a844 in _XtGetResources ()
#3  0x24ad10 in XtInitializeWidgetClass ()
#4  0x24b1a8 in _XtCreateWidget ()
#5  0x24b244 in XtCreateWidget ()
#6  0x133e08 in create (p=0x3ab400, name=0x39a3c0 "menubar", old_al=0x0,
    old_ac=0, type=1, is_radio=0) at RowColumn.c:3847
#7  0x1342d0 in XmCreateMenuBar (p=0x3ab400, name=0x39a3c0 "menubar", al=0x0,
    ac=0) at RowColumn.c:4025
#8  0xd86c4 in make_menubar (instance=0x39f300) at lwlib-Xm.c:1110
#9  0xd3558 in instanciate_widget_instance (instance=0x39f300) at lwlib.c:677
#10 0xd225c in allocate_widget_instance (info=0x39d100, parent=0x3ab400,
    pop_up_p=0 '\000') at lwlib.c:225
#11 0xd36dc in lw_make_widget (id=3794944, parent=0x3ab400, pop_up_p=0 '\000')
    at lwlib.c:716
#12 0xd3780 in lw_create_widget (type=0x49c60 "menubar",
    name=0x49c60 "menubar", id=3794944, val=0x39d900, parent=0x3ab400,
    pop_up_p=0 '\000',
    pre_activate_cb=0x4a854 <emacs_Xt_make_event_stream+3528>,
    selection_cb=0x4aaf0 <emacs_Xt_make_event_stream+4196>, post_activate_cb=0)
    at lwlib.c:731
#13 0x4b048 in set_screen_menubar (s=0x39e800, deep_p=0) at menubar.c:523


The parent of the "menubar" being created is an athena paned widget.. 
widget_class "Paned"..  

Can anyone shed some light as to what may be going on here?
(All this headache just to get tear-off menus...)

Bob Cotton
Newsgroups: alt.lucid-emacs.bug
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Subject: attributeUnderline broken?
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Date: 26 Jan 93 16:06:52 GMT


I have the following line in my .Xdefault file:

	Emacs*message-highlighted-header-contents.attributeUnderline: false

Yet my Subject: contents in VM always get underlined. Other attributes
on the same face get set correctly (foreground, font). Is it me or
lemacs 19.4?

Thanks.
-Barry
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 22 Jan 1993 18:09:23 EST
Date: Fri, 22 Jan 1993 17:30:02 EST
From: gilley@ndl.com (Greg Gilley)
Subject: vm problem
Newsgroups: alt.lucid-emacs.bug
In version 19.4 if you don't set vm-highlighted-header-regexp, then you get
an error (stringp nil) or something like that.  The problem is that
highlight-headers does not check for highlight-headers-regexp being nil.
(or that vm-highlight-headers doesn't check before it calls
highlight-headers).  Anyway there's a problem in here somewhere.

						Greg

--
-------------------------------------------------------
  Greg Gilley
  gilley@ndl.COM   [Numerical Design Limited]
  919-929-2917 (voice)
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 26 Jan 1993 04:03:29 EST
Date: Tue, 26 Jan 1993 01:03:31 PST
X-Windows: Some voids are better left unfilled.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Ultrix and lemacs19.4 (hanging)
Newsgroups: alt.lucid-emacs.bug
It's wrong to replace the call to XGetWindowProperty with a call to that
followed by a call to XDeleteProperty.  The read-and-delete needs to be
an atomic operation; it's a semaphore.  I don't understand why this
would fix anything, but probably it's just hiding the real bug instead
of fixing it.  (Either that or your X server or Xlib doesn't correctly
implement XGetWindowProperty, which is pretty inconcievable.)

	-- Jamie
From: neal@ctd.comsat.com (Neal Becker)
Newsgroups: alt.lucid-emacs.bug
Subject: Need info.el for 19.4
Date: 22 Jan 93 19:51:49 GMT
Organization: COMSAT Labs
NNTP-Posting-Host: neal.ctd.comsat.com
X-Md4-Signature: ff62fe772adf9eeda740d2ad77e6ffa1

I have a modified version of Dave Gillepsie's info.el that I used with
lemacs-19.3, but it no longer works with 19.4.  It can't find nodes
that are in alternative info directories (finds the top-level nodes
OK).

Does anyone have a fix?

Thanks.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 26 Jan 1993 04:46:39 EST
Date: Tue, 26 Jan 1993 01:46:41 PST
X-Windows: Dissatisfaction guaranteed.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: _vendorShellWidgetClass: mutiply defined?
	<9301251420.AA05693@maestro.mitre.org>
	<BCOTTON.93Jan25140226@sergei.MITRE.org>
Newsgroups: alt.lucid-emacs.bug
Bob Cotton wrote:
> 
> leamcs is dying in _XmUnitTypeDefault at a macro XmIsManager which is
> defined to be
> 
> #define XmIsManager(w)		XtIsSubclass(w, xmManagerWidgetClass)
> 
> I recompiled motif with debugging and gdb says the following....
> 0x12cdcc in _XmUnitTypeDefault (widget=0x419c00, offset=177, value=0xf7ffc07c)
>     at ResInd.c:1337
> 1337        if (XmIsManager(widget->core.parent))
> (gdb) where
> #0  0x12cdcc in _XmUnitTypeDefault (widget=0x419c00, offset=177,
>     value=0xf7ffc07c) at ResInd.c:1337
..
> #7  0x1342d0 in XmCreateMenuBar (p=0x3ab400, name=0x39a3c0 "menubar", al=0x0,
>     ac=0) at RowColumn.c:4025

This could mean that there's something that we need to do before calling
XmCreateMenuBar that we aren't; it's going to be hard for me to debug this
remotely, so I'm going to have to depend on someone else to track this down.

> The parent of the "menubar" being created is an athena paned widget.. 
> widget_class "Paned"..  

Perhaps this is the problem.  The Motif code is fundamentally confused about
what "object oriented" means, so it wouldn't surprise me if there was some
horribly incestuous relationship between menubars and their parents.  Try
making emacs use the Motif version of Paned instead, and see if that helps...

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 28 Jan 1993 15:04:34 EST
Date: Thu, 28 Jan 1993 11:53:44 PST
X-Windows: A moment of convenience, a lifetime of regret.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: lemacs freezes
Newsgroups: alt.lucid-emacs.bug
The lhilit code is broken in some serious ways.  I recommend against using it
unless someone fixes it (not me.)  Use font-lock instead, you can make it do
everything interesting that lhilit does, and it's much, much faster.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 17:53:00 EST
From: amir@matis.ingr.com (Amir J Katz)
Subject: Problems building/running 19.4
Organization: This Mortal Coil & Spring Factory
Reply-To: amir@matis.ingr.com
X-Mailer: ELM [version 2.3 PL11]
Date: Wed, 27 Jan 1993 22:53:01 GMT
Newsgroups: alt.lucid-emacs.bug
When trying to build Lemacs 19.4 on my machine (see config below), I ran
into the following problems:

1. Using gcc for a dynamic build results in multiply defined symbols
   from lwlib/xrdb.c. These symbols appear in libXt.sa.*
   See A below.

2. Building with Motif 1.2 (from ICS), either without USE_LUCID (that is,
   all menus are Motif) or with (only dialog boxes are Motif), emacs
   (probably Motif) dumps core before anything meaningful happens.
   See B below.

3. Makefiles have some problems:

   etc/Makefile  - no support for GCC
   src/ymakefile - 'make' is hardcoded, instead of using $(MAKE). I use GNU
                   make here, called 'gmake'.

4. I don't understand why the DOC file (in the etc dir) is created twice, once
   as DOC and once as DOC-19.4.*-Lucid. Why not do a link (like it's done
   for xemacs in the src dir)? This exists in emacs 18.59 as well.

My configuration is:

- Sun SparcStation 1, 12MB, cg6 (GX)
- SunOS 4.1.3 (no patches)
- MIT X11R5, patch #21
- mwm, Motif 1.2 (from ICS)
- GNU gcc 2.2.2, gdb 4.7
----------------- appendices ----------------
A. 
gcc   -dynamic    -L. -L./lwlib -o temacs  dispnew.o ...\
     [all objects].... \
     -L/usr/demo/SOUND -laudio    \ 
     -llw -lXm -lXpm -lXaw -lXext -lXt -lXmu -lX11   -ltermcap  -lg  -lm -lc
ld: /lib/libXt.sa.4.10(sharedlib.o): __XtInherit: multiply defined
ld: /lib/libXt.sa.4.10(sharedlib.o): _XtAppInitialize: multiply defined
ld: /lib/libXt.sa.4.10(sharedlib.o): _XtToolkitInitialize: multiply defined
ld: /lib/libXt.sa.4.10(sharedlib.o): _XtInitialize: multiply defined
collect: /usr/bin/ld returned 2 exit status
*** Error code 1

B.
Program terminated with signal 11, Segmentation fault.
#0  0x169ac4 in _XmGetNavigability ()
#1  0x16b274 in _XmNewTravGraph ()
#2  0x16b478 in _XmNewTravGraph ()
#3  0x16b040 in _XmNewTravGraph ()
#4  0x16abc4 in _XmTraverse ()
#5  0x167a4c in _XmMgrTraversal ()
#6  0x168dd0 in XmProcessTraversal ()
#7  0xcdcdc in xm_set_keyboard_focus ()
#8  0xcb61c in lw_set_keyboard_focus ()
#9  0x31680 in x_focus_screen (s=0x31c800) at xterm.c:2466
#10 0x8d20 in select_screen (s=0x31c800) at screen.c:295
..
#46 0x8d0c8 in apply_lambda (fun=405133792, args=69990404, eval_flag=1) at eval.c:2006
#47 0x8be08 in Feval (form=338525860) at eval.c:1526
#48 0x4d180 in top_level_2 () at keyboard.c:388
#49 0x8aa1c in condition_case_1 (handlers=69990624, bfun=0x4d16c <command_loop_2+104>, 
    barg=69990404, hfun=0x4cc94 <Frecursive_edit+352>, harg=69990404) at eval.c:1017
#50 0x4d210 in top_level_1 (dummy=69990404) at keyboard.c:397
#51 0x8a704 in internal_catch (tag=69990604, func=0x4d1bc <command_loop_2+184>, arg=69990404)
    at eval.c:887
#52 0x4d0b4 in command_loop () at keyboard.c:355
#53 0x4cac8 in recursive_edit_1 () at keyboard.c:216
#54 0x4cbe0 in Frecursive_edit () at keyboard.c:242
#55 0x4c308 in main (argc=1, argv=0xf7fffa64, envp=0xf7fffa6c) at emacs.c:963

-- 
-- Regards,
   Amir.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Sat, 23 Jan 1993 00:46:38 EST
Date: Fri, 22 Jan 1993 21:21:33 PST
From: rdm@cfcl.com (Rich Morin)
Subject: Complementary PTF Offer
Newsgroups: alt.lucid-emacs.bug
!!! You May Already Have Won !!!

Really.  The latest issue of Prime Time Freeware (PTF 2-1) is now in
production.  We are offering complementary copies of the issue to all
major contributors.  Specifically, we are sending this message to the
contact points we have listed for every major piece of software found
in the issue.

We have three motives for taking this bold (and somewhat costly) step:

   1)	We think freeware producers and archivists should be encouraged.
	A free copy of PTF 2-1 may not be much of an incentive, but it's
	all we can afford (:-).

   2)	Producers may (hint!) wish to let users know that PTF carries
	their freeware.  If producers use and like their free copies,
	they may even say nice things about PTF on the Net.

   3)	Giving things away has a certain public relations value.  We
	hope this gesture will help folks have nice thoughts about us.

To help you decide whether this offer is worth your time and effort,
here is a precis of the issue:

  PTF 2-1 contains over 3000 MB of current, substantial, UNIX-related
  freeware.  1000+ MB of language tools.  900 MB of TeX code and fonts.
  300+ MB of graphics and windowing code.  300+ MB of math, simulation,
  and statistics code.  200+ MB of ICOT (5th. Generation AI) code.  All
  of this is contained in compressed archives on two ISO-9660 CD-ROMs.
  The discs are accompanied by a 50+ page introductory booklet.

To get in on this bonanza, send us (ptf@cfcl.com) some info:

   1)	the mail header from this message

   2)	your name, shipping address (no PO boxes), and telephone number

   3)	your institution and/or project name

After verifying that you are the intended party, we will register you
as the recipient of a complementary copy.  Your copy should arrive in
mid-February, unless we encounter production or shipping problems.

Yours, Rich Morin
Prime Time Freeware

P.S.	We cannot, in general, afford to send multiple complementary
	issues to a single development project.  If we get more than
	one request from a given project, we will point the secondary
	requesters to the original recipient.
        
P.P.S.	This message may get picked up by some sort of !@#$ mailing-list
	forwarder.  If so, we apologize, and ask you to understand that
	our offer ONLY applies to the original, intended addressee.  We
	will, of course, be happy to *sell* you a copy for $60, plus tax
	and S/H charges.  Contact us if you desire more information...
From: me@Sunburn.Stanford.EDU (Martin Frost)
Newsgroups: alt.lucid-emacs.bug
Subject: name-last-kbd-macro in 19.4 on Ultrix 4.1A and on SunOS 4.1.2
Date: 28 Jan 93 00:57:06 GMT
Reply-To: me@CS.Stanford.EDU
Distribution: alt
Organization: Computer Science Department, Stanford University.

Our version of 19.4, running on an Ultrix 4.1A DECstation 5000/200, dies
when given the command M-x name-last-kbd-macro.  It doesn't get as far as
prompting for the name.  To kill it, I just started it with 'lemacs -q',
then defined with C-x ( ... C-x ) a trivial macro to move up three lines,
then M-x name... and it crashes and goes away.

I tested this same command in the pre-compiled 19.4 on a Sun 4/490 running
SunOs 4.1.2.  Although emacs didn't die, it preloaded the minibuffer input
line with the character \210 (which I've typed here as 4 chars) or
sometimes with the character ^F, after the usual prompt for the name.

I'm hoping that these problems are related and will provide a clue to
the problem.
--
Martin Frost		Computer Science Department, Computer Facilities
Systems Programmer	Stanford University, Stanford, CA  94305-2140
me@CS.Stanford.EDU	(or mfrost@stanford.bitnet)
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 21 Jan 1993 11:04:37 EST
Date: Thu, 21 Jan 1993 17:03:08 +0100
From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec)
Subject: lemacs 19.4 IOT Trap
Newsgroups: alt.lucid-emacs.bug
From: haydens@bullwinkle.juliet.ll.mit.edu (Hayden Schultz x3685 g42)
Subject: Re: lemacs19.4/lisp/cl.el
Reply-To: haydens@juliet.ll.mit.edu
Organization: M.I.T. Lincoln Lab - Group 42
Date: 25 Jan 93 21:58:57


In article <9301251839.AA24913@thalidomide.lucid> jwz@lucid.com (Jamie Zawinski) writes:
   > What is this good for? (besides making packages that do (require 'cl)
   > not working anymore)

   That is exactly the intent.

   I don't ever want cl.el to muck up my environment if I accidentally load
   something that tries to use it.  I won't run anything that uses cl.el.

Does this mean that cl.el doesn't work in 19.4?

If cl.el does work, and is merely morally corrupt, is it possible to
disable the disabling of cl.el? I've already sold my soul to
Completions.el, so I don't really have anything to loose.

	Thanks,

	Hayden Schultz (haydens@ll.mit.edu)
	MIT Lincoln Lab

x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 17:48:16 EST
From: amir@matis.ingr.com (Amir J Katz)
Subject: help-for-help, k - no prompt
Organization: This Mortal Coil & Spring Factory
Reply-To: amir@matis.ingr.com
X-Mailer: ELM [version 2.3 PL11]
Date: Wed, 27 Jan 1993 22:48:17 GMT
Newsgroups: alt.lucid-emacs.bug
When hitting M-x help-for-help, then 'k' (for key binding) the
prompt 'Describe Key:' does not appear. Hitting a key will display the
binding. From the Help pulldown menu it works as expected. It happens both
in 19.3 & 19.4. Just a minor nuisance, mind you... 

My configuration is:

- Sun SparcStation 1, 12MB, cg6 (GX)
- SunOS 4.1.3 (no patches)
- MIT X11R5, patch #21
- mwm, Motif 1.2 (from ICS)
- GNU gcc 2.2.2, gdb 4.7
- Lucid Emacs 19.4
-- 
/* ----------------------------------------------------------- */
/*  Amir J. Katz             |   amir@matis.ingr.COM           */
/*  System Specialist        |   Voice:  +972 52-584684        */
/*  SEE Technologies Ltd.    |   Fax:    +972 52-543917        */
/*  ....... To Boldly Go Where No One Has Hacked Before....... */
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 25 Jan 1993 20:25:06 EST
Date: Mon, 25 Jan 1993 17:25:11 -0800
From: erose@leland.stanford.edu
Subject: more problems with vm in 19.4
Newsgroups: alt.lucid-emacs.bug
I installed the patches recently posted for VM.  Unfortunately it still does
not rememdy the problem.  (I patched vm-lucid and highlight-headers)

I traced it to "vm-headers-of" in the vm-message lisp file.  The
argument, "message" is being passed in ass null.  I added a test for
null to return nil, and then the problem went to the "vm-text-of"
function, with the same problem.

So, either the functions should be checking for a nil message, or it
shouldn't call the functions.  Any ideas or suggestions?

Running: Dec 5000/240 Ultrix 4.2A
Emacs: Lucid 19.4

-Eric

x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 18:03:03 EST
Date: Tue, 26 Jan 1993 16:28:31 EST
From: wxj20@cas.org (Wayne Johnson)
Subject: Problem with vm in 19.4
Newsgroups: alt.lucid-emacs.bug
When I try to execute VM from an LEMACS 19.4 image, it fails to complete
initialization and produces the error:  invalid argument (or something
like this): stringp, nil.  It seems to have difficulty loading the 
vm.elc provided in the ftp source.  When I remove the vm.elc file and
replace it with a single file containing:
(load "vm...")
..
instead, it initializes as I expect it to.

Wayne
Newsgroups: alt.lucid-emacs.bug
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Odd behavior when creating a screen with 19.4
Organization: Bell Northern Research
Date: Mon, 25 Jan 93 19:39:37 GMT

I have recently started upgrading to Lucid emacs 19.4.
 
I have noticed the following problem with it, which didn't happen with
19.3.

When I create a new screen (using C-x 5), it is initially mapped with
the same size as my initial X screen (window).

It then immediately resizes to a size of 80 columns by 4 lines.

This is a bit annoying.

Has anyone else experienced this?

Are there any workarounds?

Thanks,
 Hamish.
Newsgroups: alt.lucid-emacs.bug
From: walter@optimla.aimla.com (Walter Hunt)
Subject: Re: _vendorShellWidgetClass: mutiply defined?
Organization: OptImage Interactive Services Co., L.P.
Date: Tue, 26 Jan 1993 02:31:20 GMT

In article <BCOTTON.93Jan22150119@sergei.MITRE.org>, bcotton@sergei.MITRE.org (Bob Cotton) writes:
|> 
|> Did not see this in the PROBLEMS file.. 
|> 
|> When compiling 19.4 I get the following:
|> 
	[munch]

|> ld: /usr/local/X11R5/lib/libXaw.sa.5.0(sharedlib.o): _vendorShellWidgetClass: multiply defined
|> collect: /usr/bin/ld returned 2 exit status
|> make[1]: *** [temacs] Error 1
|> make: *** [doall] Error 1
|> xcalibur [286]
|> 
|> Any clues?
|> 
|> Reading specs from /usr/local/lib/gcc-lib/sun4-sunos4.1/2.3.3/specs
|> gcc version 2.3.3
|> Sun4 4.1.3
|> Motif 1.2.1
|> 
|> Trying to use the Motif widgets..
|> 
|> Thanks, 
|> Bob


	I got the same type of error with gcc 2.3.2 using plain X11R5. The
multiply defined routines were all Xt stuff (XtInitialize, etc.). When I turned
off shared libs, it compiled fine. (Note that nothing else ever seemed to have
problems being compiled -dynamic with X11R5, just Lucid Emacs.)


-- 
Walter Hunt					walter@optimla.optimage.com
OptImage Interactive Services Company, L.P.	walter@optimla.aimla.com
11040 Santa Monica Blvd., Suite #300		netcom!optimla!walter
Los Angeles, Ca. 90025				(310) 445-5718
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 22 Jan 1993 17:19:55 EST
Date: Fri, 22 Jan 1993 17:05:58 -0500
From: max@ccrl.nj.nec.com (Maximilian Ott)
Subject: Re: 19.4 problems
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Newsgroups: alt.lucid-emacs.bug
I'm not sure if my message ever got out. Here it is again:

 
On Fri, 22 Jan 1993, Philippe Defert wrote:
 
> ld: Undefined symbol
>    _get_wmShellWidgetClass
>    _get_applicationShellWidgetClass
 
This is due to a bug in the Xmu library Sun had distributed with openwin.
Call sun and they'll send you a patch.
 
max
From: murthy@margaux.inria.fr (Chet Murthy)
Newsgroups: alt.lucid-emacs.bug
Subject: 19.4 problems (mode-motion and gmhist-app)
Date: 25 Jan 93 11:43:25 GMT
Distribution: alt
Organization: INRIA Rocquencourt,Le Chesnay, France.

Well, I got 19.4, but I can't get it to work - at least, it
doesn't seem to understand several things:

(1) I used to use the old mode-motion package, which now
should be integrated into Lemacs?  But the old lisp-mode
highlighting is gone.  Did I miss something about how
to get the old functionality from the new standard
package ?? (I figure I probably did)

(2) The tree dired package, along with ghmist, used to
work with lemacs 19.3.  I got the freshest version,
and tried to load it, in both 19.3 and 19.4.  It worked
in 19.3, but not in 19.4 - the error on load of
ghmist-app.el was something like "keep-lines: too complex".
I also tried with the provided "lisp/dired" package - 
same results.  Anybody out there know what's going wrong?

Thanks in advance,
--chet--


Newsgroups: alt.lucid-emacs.bug