HDTenEightyP/NetNews huggingface dataset:
As an update to my earlier bug email, I should note that I have hilit'ing
turned on, and that may be the cause of the problem.  I have recently
crossed a threshold in file size where, when I save a file, I get the
"Wrote <filename>" message, then lemacs freezes, leaving the "**" in the
mode line, and ignores input until C-g is pressed.  The file has been
saved, so this problem must be in the re-hilit'ing. Perhaps the other one
is too.

--
+---------------------------------------------------------------+
| Tom Yonkman                 UUCP:      seismo!esosun!yonkman  |
| Open Systems Division       Internet:  yonkman@esosun.css.gov |
| SAIC, Mail Stop A2-F        PHONE:     (619)458-4949          |
| 10260 Campus Point Drive    FAX:       (619)458-4993          |
| San Diego, CA  92121                                          |
+---------------------------------------------------------------+

x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 25 Jan 1993 13:49:07 EST
Date: Mon, 25 Jan 1993 10:39:08 PST
X-Windows: There's got to be a better way.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: lemacs19.4/lisp/cl.el
Newsgroups: alt.lucid-emacs.bug
Guido Bosch wrote:
> 
> (error "you were about to load cl.el")

This was an accident; I didn't mean to distribute that file.

> 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.

	-- Jamie
From: garath@irony.engin.umich.edu (Scott Grosch)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: _vendorShellWidgetClass: mutiply defined?
Date: 23 Jan 1993 02:00:52 GMT
Organization: University of Michigan (CAEN)
Distribution: world
Reply-To: garath@engin.umich.edu
NNTP-Posting-Host: irony.engin.umich.edu
Originator: garath@irony.engin.umich.edu



> ld: /usr/local/X11R5/lib/libXaw.sa.5.0(sharedlib.o): _vendorShellWidgetClass: multiply defined

I had this exact same problem when trying to use the motif widgets.

SunOS 4.1.2
gcc something or other
Motif 1.1.4

-- 
Scott Grosch                                   Internet: garath@engin.umich.edu
Programmer                                             Bitnet: user7a4b@umichum
Computer Aided Engineering Network                       University of Michigan
Newsgroups: alt.lucid-emacs.bug
From: me@Sunburn.Stanford.EDU (Martin Frost)
Subject: fnexpand.el under 19.4
Reply-To: me@CS.Stanford.EDU
Organization: Computer Science Dept., Stanford University
Distribution: alt
Date: 23 Jan 93 17:21:23

I've been using fnexpand.el from

    ;; Written by eirik@theory.tn.cornell.edu and trost@reed.edu
    ;; Original idea by karl@cs.umb.edu

for some time for filename completion in emacs shell buffers.  It's great.
It even works unaltered with Lucid Emacs.

But in 19.4, I've started seeing a new undesirable result in completion,
and I'd like to know if anyone has a fix for this to restore the old
effects.

The problem is that when I complete a relative filename with TAB in a 19.4
shell window, Emacs converts the relative filename to an absolute filename,
filling in all the leading directory names.  In 19.3 and 18.58, the
relative filename is simply completed.

For example, if I say, in a 19.4 shell window:

  cd /etc
  ls -l reso<TAB>

the current shell input line changes to say

  ls -l /etc/resolv.conf

instead of just

  ls -l resolv.conf

This is particularly undesirable when I'm trying to create a relative
symbolic link to an existing file in the current directory.  I don't want
an absolute link.  But in general, when the absolute pathname is long, this
new result makes things much harder to read in the shell window.

By the way, if I say

  ls -l ./reso<TAB>

then the filename is kept relative (to .) after expansion:

  ls -l ./resolv.conf

But I just as soon not have to type ./ all the time.

This is with the precompiled 19.4 binaries on a Sun 4/490 running SunOS 4.1.2.
--
Martin Frost		Computer Science Department, Computer Facilities
Systems Programmer	Stanford University, Stanford, CA  94305-2140
me@CS.Stanford.EDU	(or mfrost@stanford.bitnet)
Jamie Zawinski writes:
 > 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"..  
What function does the athena paned widget serve in emacs? This may help me in 
trying to figure out what needs to be done.. 

Not sure if this has any implication, but our X11R5 was compiled with MotifBC
for motif 1.1.4.. I wonder if that is messing with 1.2.1?
 > 
 > 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

Bob
Newsgroups: alt.lucid-emacs.bug
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Subject: Bug in isearch-edit-string, isearch-mode.el
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Date: 25 Jan 93 18:52:14 GMT


Lemacs 19.4: I bind isearch-edit-string to Control-6. i-e-s has a bug
where the cursor does not move while editing the string in the
minibuffer.  Eg: you're editing the string, and you hit C-a. Newly
inserted characters are inserted at the beginning of the string, but
the cursor remains at the end.  Similarly for C-f and C-b.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 17:53:46 EST
Date: Wed, 27 Jan 1993 18:29:48 +0100
From: Guido.Bosch%loria.fr@lucid.com (Guido Bosch)
Subject: Re: vm search bug
Reply-To: bosch%loria.fr@lucid.com (Guido Bosch)
Newsgroups: alt.lucid-emacs.bug
I'm using lemacs-19.4 (Lucid widgets) on a NeXT (OS3.0, co-Xist 3.0).
I have a few NeXT-specific problems, but one that may be more general
is the following: when I kill lemacs, I get a memory error. Of course,
at that point I don't care a lot....but it's kind of graceless,
nonetheless. Perhaps someone can figure out what's going on from the
gdb output below.

--Steve Anderson

sapir:~
zsh [5]% gdb lemacs
Reading symbol data from lemacs...done.
Reading symbol data from /usr/shlib/libsys_s.B.shlib...done.
(gdb) run
Starting program: /usr/local/bin/lemacs 
emacs-19.4.1-Luci: privileges disabled because of outstanding IPC access to task
memory allocation error: attempt to free or realloc space not in heap
bad zone

Program received signal 6, IOT trap
0x5007914 in kill ()
(gdb) bt
#0  0x5007914 in kill ()
#1  0x5 in ?? ()
#2  0x50535b4 in abort ()
#3  0x50571c4 in DefaultMallocError ()
#4  0x50092d8 in free ()
#5  0xc2948 in LINEAR_RGB_FreeSCCData ()
#6  0xc081e in _XcmsFreeDefaultCCCs ()
#7  0xb5462 in _XFreeDisplayStructure ()
#8  0xad03e in XCloseDisplay ()
#9  0x23e86 in Fx_close_current_connection () at xfns.c:2097
#10 0x2fc88 in Fkill_emacs (arg=68364896) at emacs.c:1089
#11 0x57d26 in Ffuncall (nargs=1, args=0x3fff24c) at eval.c:1904
#12 0x6abda in Fbyte_code (bytestr=202413164, vector=269522132, maxdepth=5) at bytecode.c:425
#13 0x5834a in funcall_lambda (fun=403739708, nargs=1, arg_vector=0x3fff3a8) at eval.c:2076
#14 0x57e26 in Ffuncall (nargs=2, args=0x3fff3a4) at eval.c:1943
#15 0x54cd0 in Fcall_interactively (function=68498196, record_flag=68364896) at callint.c:626
#16 0x57d3c in Ffuncall (nargs=2, args=0x3fff4dc) at eval.c:1907
#17 0x5790c in call1 (fn=68384432, arg=68498196) at eval.c:1698
#18 0x188ba in dispatch_command_event_internal (event=0x206c08, leaf=68364896) at event-stream.c:1619
#19 0x1898a in dispatch_menu_event (e=0x206c08) at event-stream.c:1671
#20 0x1780e in dispatch_event_internal (event=1746955272, execute_p=1) at event-stream.c:1004
#21 0x18b3a in Fdispatch_event (event=1746955272) at event-stream.c:1745
#22 0x30724 in command_loop_1 (dummy=68364896) at keyboard.c:509
#23 0x56618 in condition_case_1 (handlers=68365116, bfun=0x305a8 <command_loop_1>, barg=68364896, hfun=0x300cc <cmd_error>, harg=68364896) at eval.c:1017
#24 0x3043e in command_loop_2 (dummy=68364896) at keyboard.c:377
#25 0x563f2 in internal_catch (tag=68365096, func=0x30414 <command_loop_2>, arg=68364896) at eval.c:887
#26 0x303f4 in command_loop () at keyboard.c:356
#27 0x2ffda in recursive_edit_1 () at keyboard.c:216
#28 0x3007c in Frecursive_edit () at keyboard.c:242
#29 0x2fbac in main (argc=1, argv=0x3fff7a4, envp=0x3fff7ac) at emacs.c:963
(gdb) 
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 18:00:50 EST
From: piggy%hilbert.maths.utas.edu.au@lucid.com (La Monte Yarroll)
Subject: BUG: extents dribble
Date: Wed, 27 Jan 1993 17:32:51 EST
X-Mailer: ELM [version 2.2 PL11]
Newsgroups: alt.lucid-emacs.bug
I'm running the lucid emacs 19.4 sparc binary currently available for ftp.

I've noticed an annoying feature of the realization of extents.  Under
conditions I don't yet understand, and extent can dribble over into
the next character for a short period.

You can see this effect most easily by highlighting a region and then
using ^w.  You delete one less character than it looked like.

At first I thought this was the cursor getting in the way, but it
isn't.  There appear to be conditions under which extents show
themselves from [start, end] instead of [start, end).

To investigate this bug, eval the following code to set up an extent.

(setq bug-face (make-face 'smile))
(defun demonstrate-extent-problem ()
  (let ((start (point))
	(end))
    (insert "Put it here-")
    (setq end (point))
    (insert "!-to demonstrate bug.")
    (set-face-font bug-face "7x13b")
    (setq bug-extent (make-extent start end))
    (set-extent-face bug-extent bug-face))
)


Now evaluate (demonstrate-extent-problem).  Put your cursor on the "!".
Type a single character.  Notice that the "!" is now bold.  Now eval
(cons bug-extent (point)); note that (point) is supposedly not
included in the extent.  Now move to the "-" after the "!".  Type
another character, and the "!" reverts.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 25 Jan 1993 03:46:06 EST
Date: Mon, 25 Jan 1993 09:47:17 +0100
From: frans%kiwi.uia.ac.be@lucid.com (Francois Staes)
Subject: Building lemacs-19.4 on Sun3
Newsgroups: alt.lucid-emacs.bug
Anybody already tried to build lemacs-19.4 on a Sun 3/60 ? I tried building it
using the s-sunos4.h config file, but it seems there are some hardcoded
references to the SPARC architecture in the unexsunos4.c file...

Francois Staes
University of Antwerp
Antwerp, Belgium
Email: frans@kiwi.uia.ac.be

PS: Thanks for the nice job done...
Newsgroups: alt.lucid-emacs.bug
From: carney@rocky.rational.com (Mike Carney)
Subject: Problems with V19.4 and superman.el
Organization: Rational, Santa Clara, CA
Distribution: alt
Date: Mon, 25 Jan 1993 19:24:40 GMT


I'm running Lucid Emacs V19.4 on a Sparcstation 2. I've been using the
superman.el package for a while under V19.3. In V19.3, when cross
referencing to other manual pages, the pages refered to in the "SEE
ALSO" section would highlight with mouse button 2, and the get
followed when button2 was depressed. This doesn't work with version
19.4. Anyone have any ideas?

Thanks in advance.

--
               '`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`
               '                                   |  `
               ' Michael D. Carney                 |  `
               ' carney@rational.com               |  `
               ' Santa Clara, CA  _   _   _+      _|_ `
               '                 /_`-'_`-'_|  \+/  0  `
               ' "You can never  \_`M'_`C'_| _<=>_//  `
               '  really *know*    `-' `-' 0/ \|/ /   `
               '  anything"                \/]\|/[    `
               '        -Heisenberg        | /_V_\    `
               '         (paraphrased)     | [] []    `
               '                           | d! !b    `
               `'`'`'``'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 22 Jan 1993 15:45:11 EST
Date: Fri, 22 Jan 1993 12:45:05 PST
X-Windows: Flawed beyond belief.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: 19.4 problems
Newsgroups: alt.lucid-emacs.bug
Philippe Defert wrote:
> 
> gcc   -dynamic [...]
> ld: Undefined symbol
>    _get_wmShellWidgetClass
>    _get_applicationShellWidgetClass

If you're linking dynamically, you may need to build a shared version of
lwlib.  I don't understand why different code sometimes goes into the 
dynamic and static versions of the X libraries, but it does.  Easy fix:
try linking statically.

>   2. As I want to install lemacs lisp files in a logical directory
> (/usr/local/lib/lemacs or /usr/local/lib/lemacs-19.4), I modified the
> paths.h

This is your mistake.  Never edit paths.h.  See the NEWS file for a
description of how to arrange for lemacs to find the directories it needs.

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 28 Jan 1993 21:47:37 EST
Date: Fri, 29 Jan 1993 13:46:45 EST
From: rwhitby%research.canon.oz.au@lucid.com (Rod Whitby)
Subject: Patch to font_lock.c
Newsgroups: alt.lucid-emacs.bug
When calling find_context_start with a zero end parameter, point may
be moved by the call to end_of_defun.  This means that point is not
preserved across the call to buffer-syntactic-context.

Here is a patch to font_lock.c so point is preserved when calling
buffer-syntactic-context.

*** lemacs-19.4/src/font_lock.c~	Wed Jan 20 20:42:39 1993
--- lemacs-19.4/src/font_lock.c		Fri Jan 29 13:03:19 1993
***************
*** 107,112 ****
--- 107,113 ----
  static void
  find_context_start (int pt, int end)
  {
+   int npt;
    int do_bod = (pt > context_cache.end_point ||
  		current_buffer != context_cache.buffer);
  
***************
*** 117,124 ****
      {
        /* We must start searching at the beginning of defun.
         */
!       pt = beginning_of_defun (pt);
!       context_cache.start_point = pt;
        context_cache.buffer = current_buffer;
        context_cache.context = context_none;
        context_cache.ccontext = ccontext_none;
--- 118,125 ----
      {
        /* We must start searching at the beginning of defun.
         */
!       npt = beginning_of_defun (pt);
!       context_cache.start_point = npt;
        context_cache.buffer = current_buffer;
        context_cache.context = context_none;
        context_cache.ccontext = ccontext_none;
***************
*** 127,136 ****
  #endif
        context_cache.scontext = '\000';
        context_cache.depth = 0;
!       context_cache.backslash_p = ((pt > 1) && (CHAR_AT (pt - 1) == '\\'));
        if (end)
  	{
! 	  if (end < pt) abort ();
  	  context_cache.end_point = end;
  	}
        else
--- 128,137 ----
  #endif
        context_cache.scontext = '\000';
        context_cache.depth = 0;
!       context_cache.backslash_p = ((npt > 1) && (CHAR_AT (npt - 1) == '\\'));
        if (end)
  	{
! 	  if (end < npt) abort ();
  	  context_cache.end_point = end;
  	}
        else

--------------------------------------------- _--_|\  |
Rod Whitby (rwhitby@research.canon.oz.au)    /      \ |
Canon Information Systems Research Australia \_.--._/ |
1 Thomas Holt Drive, North Ryde, N.S.W., 2113.     v  |
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 17:56:16 EST
Date: Wed, 27 Jan 1993 16:08:23 +0100
From: Guido.Bosch%loria.fr@lucid.com (Guido Bosch)
Subject: vm isearch problems
Reply-To: bosch%loria.fr@lucid.com (Guido Bosch)
Newsgroups: alt.lucid-emacs.bug
In Lucid Emacs 19.4, there is still a bug in vm-isearch-forward (on
M-s or ESC-s). However, the patches that have been posted here long
time ago have been applied correctly (seems that vm.elc hasn't been
recreated after the  patches).

I recompiled VM, and now get another error for the the same command:

	(void-variable search-exit-char)

I guess this is related to the changes of the isearch package
somewhere down in version 19.3 ...

Here are the related compiler warnings that I got on vm-search.el: 

./../src/xemacs -batch -q -l ./vm-message.el -l ./vm-misc.el -l -f batch-byte-com vm-search.el
While compiling vm-isearch in file vm-search.el:
  ** baud-rate is an obsolete function; use the baud-rate variable instead
  ** reference to free variable search-exit-char
  ** reference to free variable search-repeat-char
  ** reference to free variable search-reverse-char
  ** reference to free variable search-delete-char
  ** reference to free variable search-yank-word-char
  ** reference to free variable search-yank-line-char
  ** reference to free variable search-quote-char
While compiling vm-nonincremental-search:
  ** reference to free variable search-yank-word-char


Does anybody know how these variables are called now? 

	Guido
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Thu, 28 Jan 1993 16:06:41 EST
Date: Thu, 28 Jan 1993 15:51:25 EST
From: david@mvision.com (David Brusowankin)
Subject: mailing list
Newsgroups: alt.lucid-emacs.bug
Please add me to your mailing list
Newsgroups: alt.lucid-emacs.bug
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Subject: Re: Solution to highlight-headers problem in lemacs19.4
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Date: 25 Jan 93 15:51:30 GMT


>>>>> "David" == David Hughes <djh@CIS.Prime.COM> writes:

    David> Recompile and all your problems disappear...

Don't forget to: "make vm.elc" in lisp/vm. Its necessary, but not
sufficient to byte-compile vm-lucid.el.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 25 Jan 1993 13:49:25 EST
Date: Mon, 25 Jan 1993 13:41:02 EST
From: Tony.Bennett@East.Sun.COM (Tony E. Bennett)
Subject: 19.4 vm5.32 vm-isearch-forward
Mailed-From: GNU Emacs or Epoch (19.4.7 Lucid)
Content-Length: 510
Newsgroups: alt.lucid-emacs.bug
Vm's .elc files shipped w/ 19.4 have vm-isearch-forward broken
with the defmacro problem.

Rebuilding vm.elc from scratch fixed it.

But in order to use vm-isearch-forward, I had to add the
following to my .emacs:

(if running-lemacs		;; lemacs vm missing following vars
    (progn
      (setq search-quote-char 17)
      (setq search-yank-line-char 25)
      (setq search-yank-word-char 23)
      (setq search-delete-char 127)
      (setq search-reverse-char 18)
      (setq search-repeat-char 19)))

--tony
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 18:07:35 EST
Return-Path: <bcotton@maestro.mitre.org>
Date: Wed, 27 Jan 1993 14:06:17 EST
From: bcotton@maestro.mitre.org (Bob Cotton)
Subject: Re: Problems building/running 19.4
Newsgroups: alt.lucid-emacs.bug
I made copy of 19.4 distribution of Lucid Emacs in:

	lkbreth.foretune.co.jp:/pub/GNU/lucid	[133.123.1.1]

Above server is NOT our regular ftp archive. I will move them to our
up-to-date public server:

	ftp.foretune.co.jp:/pub/GNU/lucid	[133.123.1.2]

later (in few days) So try lkbreth first for while.

Shigeya Suzuki
Foretune Co., Ltd.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 25 Jan 1993 13:47:15 EST
Date: Mon, 25 Jan 1993 10:45:52 PST
X-Windows: A moment of convenience, a lifetime of regret.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: 19.4 vm5.32 vm-isearch-forward
Newsgroups: alt.lucid-emacs.bug
Someone should rewrite vm-isearch to use isearch-mode instead of the older,
more broken, v18-based isearch code it's using now.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 25 Jan 1993 09:20:52 EST
Return-Path: <bcotton@maestro.mitre.org>
Date: Mon, 25 Jan 1993 09:20:38 EST
From: bcotton@maestro.mitre.org (Bob Cotton)
Subject: Re: _vendorShellWidgetClass: mutiply defined?
Newsgroups: alt.lucid-emacs.bug
Henrik B}kman  CSD writes:
 > 
 > I have the same problem. If you get a solution please send
 > me it thank you.
 > 
 > -- 
 > ----------------------------------------------------------------------
 > Henrik Bakman           Adress: Box 311          Tel: +46 18 181044
 > System Manager                  751 05 UPPSALA   Fax: +46 18 521270
 > Computing Science Dep.          SWEDEN           Email: hb@csd.uu.se
 > Uppsala University

Solved half the problem..

I got rid of  _vendorShellWidgetClass: mutiply defined by
gcc -static (instead if -dynamic).. emacs linked and dumped...

But when I run it I get:

GDB 4.4, Copyright 1991 Free Software Foundation, Inc...
(gdb) run
Starting program: /tmp_mnt/home/bcotton/bcotton/lemacs-19.4/src/xemacs

Program received signal 11, Segmentation fault
0x122050 in _XmGetNavigability ()
(gdb) tb
Breakpoint 1 at 0x122050
(gdb) where
#0  0x122050 in _XmGetNavigability ()
#1  0x1235e8 in _XmNewTravGraph ()
#2  0x1237d8 in _XmNewTravGraph ()
#3  0x1233f8 in _XmNewTravGraph ()
#4  0x122fe4 in _XmTraverse ()
#5  0x120240 in _XmMgrTraversal ()
#6  0x121450 in XmProcessTraversal ()
#7  0x8f1f8 in xm_set_keyboard_focus ()
#8  0x8cb18 in lw_set_keyboard_focus ()
#9  0x227b4 in x_focus_screen ()
#10 0x6354 in select_screen ()
#11 0x23c3c in Fx_create_screen ()
#12 0x61d08 in Ffuncall ()
#13 0x7869c in Fbyte_code ()
#14 0x62240 in Ffuncall ()
#15 0x61df0 in Ffuncall ()
#16 0x7869c in Fbyte_code ()
#17 0x62240 in Ffuncall ()
#18 0x61df0 in Ffuncall ()
#19 0x7869c in Fbyte_code ()
#20 0x62240 in Ffuncall ()
#21 0x61df0 in Ffuncall ()
#22 0x61c30 in Ffuncall ()
#23 0x61920 in call1 ()
#24 0x66d64 in Fnconc ()
#25 0x66ed0 in Fmapcar ()
#26 0x61d08 in Ffuncall ()
#27 0x7869c in Fbyte_code ()
#28 0x62240 in Ffuncall ()
#29 0x61df0 in Ffuncall ()
#30 0x7869c in Fbyte_code ()
#31 0x613c4 in Feval ()
#32 0x60628 in condition_case_1 ()
#33 0x60794 in Fcondition_case_3 ()
#34 0x78a4c in Fbyte_code ()
#35 0x62240 in Ffuncall ()
#36 0x61df0 in Ffuncall ()
---Type <return> to continue---
#37 0x7869c in Fbyte_code ()
#38 0x613c4 in Feval ()
#39 0x60628 in condition_case_1 ()
#40 0x60794 in Fcondition_case_3 ()
#41 0x78a4c in Fbyte_code ()
#42 0x62240 in Ffuncall ()
#43 0x61df0 in Ffuncall ()
#44 0x7869c in Fbyte_code ()
#45 0x62240 in Ffuncall ()
#46 0x61fc4 in Ffuncall ()
#47 0x61464 in Feval ()
#48 0x353a0 in command_loop_2 ()
#49 0x60628 in condition_case_1 ()
#50 0x35410 in command_loop_2 ()
#51 0x603f4 in internal_catch ()
#52 0x35300 in Frecursive_edit ()
#53 0x34e8c in Fnoninteractive ()
#54 0x34f6c in Frecursive_edit ()
#55 0x34830 in main ()


Anyone else have this problem?

Again... gcc 2.3.3 Motif 1.2.1 Sun4 4.1.2

Thanks
Bob
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 27 Jan 1993 18:00:16 EST
Date: Wed, 27 Jan 1993 15:31:13 +0800
From: franks%ntrc.ntu.ac.sg@lucid.com (Frank Siebenlist)
Subject: copy/paste inconsistency with clipboard and active regions
Newsgroups: alt.lucid-emacs.bug