HDTenEightyP/NetNews huggingface dataset:
lemacs 19.3 wasn't able to find either the doc file or the emacsserver
program on my system.  I didn't have this problem with 19.2. I have
lemacs in /local/bin; this is a symlink to
/local/lemacs-19.3/src/emacs-19.3.1-Lucid.  There's also a directory
/local/etc. The problem was that (find-default-load-path-internal
"etc") returned /local/etc rather than /local/lemacs-19.3/etc.  I
fixed it like this:

*** lisp/prim/startup.el.~1~	Sun Aug 30 03:36:02 1992
--- lisp/prim/startup.el	Thu Sep 10 10:42:47 1992
***************
*** 542,548 ****
            ;; If in .../src/ or ../bin/, look for subdirs of this directory's
  	  ;; parent.
            ;;
!           ((and (string-match "/\\(src\\|etc\\|lisp\\|lock\\|bin\\)/$"
  			      invocation-directory)
  		(file-directory-p
  		 (setq tmp (concat (substring invocation-directory 0
--- 542,548 ----
            ;; If in .../src/ or ../bin/, look for subdirs of this directory's
  	  ;; parent.
            ;;
!           ((and (string-match "/\\(src\\|etc\\|lisp\\|lock\\)/$"
  			      invocation-directory)
  		(file-directory-p
  		 (setq tmp (concat (substring invocation-directory 0

James Clark
jjc@jclark.com
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 8 Sep 1992 09:07:40 EDT
From: matis!amir@lucid.com (Amir Katz)
Subject: Sound on SunOS 4.1.3
Organization: SEE Technologies Ltd.
Reply-To: matis!matis.ingr.COM!amir@lucid.com
X-Reply-To: amir@matis.ingr.COM
X-Mailer: ELM [version 2.3 PL11]
Date: Tue, 8 Sep 1992 13:07:41 GMT
Newsgroups: alt.lucid-emacs.bug
Lucidites, take notice.

Today I installed SunOs 4.1.3 on my machine (always the pioneer (sucker?) here).
The sound stuff stopped working, so I had to tweak the file libsst.c in the
'src' directory and to rebuild.

My configuration is:
  SparcStation 1+ w/GX
  SunOS 4.1.3
  MIT X11R5, patch 17
  gcc 2.2.2

Audio Device Changes
====================
In SunOS 4.1.3, the audio device stuff has been changed (in order to support
the better audio devices on the SPARC*10 boxes). It seems like the literal
AUDIOSETQSIZE does no longer exist and there is no equivalent function to 
change the audio device queue size, as far as I can tell from the man pages. 
I'm sure the audio device can be better utilized, but what the hell, it works
now, so who cares...

*** libsst.c.orig	Tue Apr 14 03:25:53 1992
--- libsst.c		Mon Sep  7 15:30:44 1992
***************
*** 34,39 ****
--- 34,40 ----
  	return( fd );
  	}
  
+ #ifdef AUDIO_4_1_2   /* AJK */
      /* Shrink audio device's queue size, to cut down time delay. */
      i = AUDBUF;
      if ( ioctl( fd, AUDIOSETQSIZE, &i ) < 0 )
***************
*** 41,46 ****
--- 42,48 ----
  	perror( "sst_open: SETQSIZE" );
  	return( fd );
  	}
+ #endif /* AUDIO_4_1_2 */
  
      /* Set gains.  -10 <= ger <= 18,  -18 <= gr <= 12,  -18 <= gx <= 12. */
      if (!play_level) 

-- 
/* ----------------------------------------------------------- */
/*  Amir J. Katz             |   amir@matis.ingr.COM           */
/*  System Specialist        |   Voice:  +972 52-584684        */
/*  SEE Technologies Ltd.    |   Fax:    +972 52-543917        */
/* ............ Solaris 2.0 - The Final Frontier ? ........... */
From: Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald)
Newsgroups: alt.lucid-emacs.bug
Subject: Why does lemacs (currently) care about your terminal type (TERM)
Date: 10 Sep 92 04:13:15 GMT
Organization: Bell Northern Research

This is with Lucid Emacs 19.3.

If I startup lemacs from an xterm, it starts up fine.

If I start it up from an emacs shell buffer, I get:

    emacs: Terminal type emacs is not defined.

This is under HPUX 7.05 on an HP9000/425.  This machine fakes termcap
with terminfo, I think, so it doesn't use the fake "TERMCAP=emacs..."
that emacs puts into the environment.

Since lemacs is using the X-windows interface, it shouldn't care
*what* value TERM has.

If I unset TERM, It starts up fine.

i.e. the code in term_init which does:

  if (egetenv ("DISPLAY") && !inhibit_window_system)
    return;

could probably be moved a lot nearer the beginning of term_init, no?

I've tried moving it to just before the call to "tgetent" in
term_init, and it seems to work so far.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 9 Sep 1992 20:48:16 EDT
Date: Wed, 9 Sep 1992 15:01:24 PDT
X-Windows: More than enough rope.
From: jwz@lucid.com (Jamie Zawinski)
Subject: YP/DNS problem
Newsgroups: alt.lucid-emacs.bug
The new mouse completion is really nice!

There is only a problem with "."-files,

just try to complete with  ~/.<tab>
and you will see that the files are not or wrongly recognized.

x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 11 Sep 1992 06:42:36 EDT
Date: Thu, 10 Sep 1992 19:50:49 PDT
X-Windows: Flakey and built to stay that way.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: 19.3: Info-directory-list and .../etc path
Newsgroups: alt.lucid-emacs.bug
In message <9209101859.AA06023@sun006> Maximilian Ott wrote:
>
> I experience the problem that lemacs 19.3 doesn't set the
> Info-directory-list variable correctly. My ../bin/lemacs is a symbolic
> link to the binary in .../lemacs-19.3/src/lemacs. The load-path
> is set correctly.

Sigh...  The heuristics that emacs is using to find the etc and lisp
directories seems to have gotten worse, primarily as a result of the
fact that it now starts at the name of the emacs program that was run
(even if that was a symbolic link) instead of at the `truename' of the
emacs executable.

If you make symlinks to the etc and lisp dirs in the same directory in
which your "frontmost" emacs executable resides, things should work.
(I realize that some of you don't want to do this.)

> Has anyone tried out "font-lock"? Should the colors (faces) change
> while I type. This was my understanding, but I only see them right
> after I save the file.

Odd; it works for me with the 19.3 started with -q.  I visited a new
file (foo.el) did M-x font-lock-mode, and typed

	; testing
	(defun foo ()

The word "testing" was in italic and the word "foo" was in bold-italic.

> (Besides, how do I change the colors - does this tell you that I've no
> idea?)

`C-h a face'

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Wed, 9 Sep 1992 20:55:16 EDT
Date: Wed, 9 Sep 1992 17:49:34 PDT
X-Windows: It could happen to you.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Two problems with 19.3
Newsgroups: alt.lucid-emacs.bug
In message <9209100009.AA05753@sun006> Maximilian Ott wrote:
>
> 1) Missing lib file
> 
> I just installed 19.3 and tried to run it "out of the box" using the
> provided binaries. However "emacsserver" is looking for 
> 
> 	ld.so: liblucidx.so.2: not found
> 
> which I can't find anywhere.

Sorry about that.  I should have known better than to ever compile anything
without saying "please link statically so that I don't lose horribly if
someone sneezes."

I compiled with Lucid C, and it's trying to dynamically link against its
runtime library, which exists because Sun's libraries are buggy.  I'll make
a new set of static binaries this evening.  (This should only be a problem
for the things in the etc directory, not emacs itself, and those are easy to
compile, so you might want to just do that instead of re-FTPing the whole
package.)

> I even got lemacs to core dump on one occasion:
> 
> #0  0x4a14 in pixel_to_glyph_translation () at dispnew.c:1758

Aaah, redisplay.  Bane of the modern world.  The binaries I distributed were
compiled with optimization, so I can't really do much unless you can come up
with a script to reproduce this, or recompile your emacs with debug info and
have it happen again.  It's related to the position of the mouse, the position
of the extents, and timing is probably a factor as well.

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 14 Sep 1992 05:26:11 EDT
From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen)
Subject: Lucid Emacs 19.3 under IRIX 4.0.5 (Silicon Graphics)
Date: Mon, 14 Sep 1992 09:26:12 GMT
Newsgroups: alt.lucid-emacs.bug
Basically, Lemacs compiles without much hassle under IRIX 4 (using
GCC).  The linker that comes with the new (3.10) compilers generates
slightly different output files, which causes unexec() to break.  The
patch below (posted to the Epoch newsgroup by Shankar Unni of SGI)
makes unexmips.c cope with the new format.

The resulting lemacs works (I am using it now) but has some problems:

* if you start it in the background, it stops with

[1]+  Stopped (tty output)    lemacs

* tabs are sometimes displayed incorrectly (as single spaces even at
  the beginning of a line).  The Sun version (compiled by me using
  GCC) has the same problem.
-- 
Simon.

============================== snip snip ==============================
*** unexmips.c.orig	Fri Aug  7 14:36:00 1992
--- unexmips.c	Thu Aug 27 19:10:46 1992
***************
*** 152,158 ****
--- 152,164 ----
        exit(1);
      }
  
+ /*
+  * The headers are no longer in text-init-rdata-data order. Therefore we 
+  * have to do a linear search for each section in the section list.
+  */
  #define CHECK_SCNHDR(ptr, name, flags) \
+   i = 0; ptr = NULL; \
+   while(i < hdr.fhdr.f_nscns && !ptr) { \
    if (strcmp(hdr.section[i].s_name, name) == 0) { \
      if (hdr.section[i].s_flags != flags) { \
        fprintf(stderr, "unexec: %x flags where %x expected in %s section.\n", \
***************
*** 159,171 ****
  	      hdr.section[i].s_flags, flags, name); \
      } \
      ptr = hdr.section + i; \
-     i += 1; \
    } \
!   else { \
!     ptr = NULL; \
!     }
  
-   i = 0;
    CHECK_SCNHDR(text_section,  _TEXT,  STYP_TEXT);
    CHECK_SCNHDR(init_section,  _INIT,  STYP_INIT);
    CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA);
--- 165,174 ----
  	      hdr.section[i].s_flags, flags, name); \
      } \
      ptr = hdr.section + i; \
    } \
!   i += 1; \
!   }
  
    CHECK_SCNHDR(text_section,  _TEXT,  STYP_TEXT);
    CHECK_SCNHDR(init_section,  _INIT,  STYP_INIT);
    CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA);
***************
*** 198,203 ****
--- 201,212 ----
  
    hdr.aout.bss_start = hdr.aout.data_start + hdr.aout.dsize;
    rdata_section->s_size = data_start - DATA_START;
+ 
+   /* adjust start and virtual addresses of rdata_section, too */
+   rdata_section->s_vaddr = DATA_START;
+   rdata_section->s_paddr = DATA_START;
+   rdata_section->s_scnptr = text_section->s_scnptr + hdr.aout.tsize;
+ 
    data_section->s_vaddr = data_start;
    data_section->s_paddr = data_start;
    data_section->s_size = brk - data_start;
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 15 Sep 1992 17:48:58 EDT
Date: Tue, 15 Sep 1992 14:47:21 PDT
X-Windows: It could be worse, but it'll take time.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: SUGGESTION: Permit help strings in menu items.
Newsgroups: alt.lucid-emacs.bug
> I'd like to suggest that an optional 4th field be permitted in Lucid Emacs
> menu items (or GNU Emacs V19 menus if it has them) which would be a one line
> description providing help on the menu item.  The string would be
> appropriate for display in the echo area and could be accessed by a user
> prior to selecting a menu item, for those cases where the item name is not
> descriptive enough.

I thought about implementing it as an additional slot in the menu description,
but I think it might be better to have the modeline simply display the first
line of the documentation string of the command which they invoke, as the
mouse moves over the menu items.  It is already customary that the first line
be a single sentence which summarizes the command's behavior for the benefit
of apropos.

> I've designed menu-based frontends to systems for a number of years now
> and this is one feature which most menu systems lack that I find
> indispensible.

Needless to say, the lispms had it fifteen years ago.

	-- Jamie
From: steve@gabriela.tymnet.com (Steve Sandke)
Newsgroups: alt.lucid-emacs.bug
Subject: Bug in lhilit
Date: 11 Sep 92 18:14:42 GMT
Organization: BT North America, San Jose, CA

Want to send Lemacs into contortions?  Load lihilit, put this code into a buffer in c-mode, then
[try to] save it.

***************
/* This is a test case */

int main()
{
}

/*  This unterminated comment really messes things up...

int fn1()
{
}

***************

Apparently, the highlighting code goes into a really tight loop trying to find the other end of
the comment.  If you hit control-G, you at least get your prompt back, but emacs keeps 
running at full speed, taking up most of the CPU.

I'm not an elisp expert at all, so I have no idea how to fix this.  

-- 
-------------------
Steve Sandke
steve@orchid.tymnet.com
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 15 Sep 1992 12:37:56 EDT
Date: Tue, 15 Sep 1992 10:37:36 -0600
From: eeide@asylum.cs.utah.edu (Eric Eide)
Subject: Non-robust X Processing
Newsgroups: alt.lucid-emacs.bug
I erroneously added the following line to my ".Xresources" file:

  ! 68 is the glyph for the left pointer.
  Emacs*XlwMenu.cursor: 68

Lucid GNU Emacs couldn't turn "68" into a Cursor, and this resulted in a long
line of X errors.  I could no longer pull down any of the menus, and when I
exited Emacs it dumped core.  Changing the resource specification to:

  Emacs*XlwMenu.curosr: left_ptr

cleared up all of the problems.

It appears that Lucid GNU Emacs doesn't handle some X errors very well.  It
wouldn't take much for Lucid to provide its own default cursor in the case
above, for example.

I guess this falls into the category of "robust" behavior, and perhaps Lucid
GNU Emacs is too young to be expected to be wholly robust.  I am, however,
pleased to report that this is the only crash I've experienced with Lucid GNU
Emacs.  And 19.3 was easy to install on my system -- much easier than 19.1!
Thank you, Lucid, for your excellent work!

PS -- I love "blink-paren".  One of my coworkers said that "blink-paren" alone
is reason enough to switch to Lucid.

-------------------------------------------------------------------------------
Eric Eide          |          University of Utah Department of Computer Science
eeide@cs.utah.edu  | Buddhist to hot dog vendor: "Make me one with everything."
From: frain@cis.ksu.edu (Jerry Frain)
Newsgroups: alt.lucid-emacs.bug
Subject: Re: lemacs 19.3 & VM
Date: 15 Sep 92 15:23:55 GMT
Organization: Kansas State University
NNTP-Posting-Host: depot.cis.ksu.edu

lamour@maestro.mitre.org (Michael Lamoureux) writes:

> 	I haven't really had any trouble with any other part of emacs
> (but then, I do tend to use VM more than any other mode ;-)

I, too, ran into these problems.  One of the errors I saw mentioned
"byte-code", so I re-compiled vm-mode from the distribution.

However, vm-mode uses a several constants (the first one it misses is
search-exit-char) previously defined in loaddefs.el, and used for the
incremental search, but now removed because they are unnecessary due
to the new isearch-mode.

If you want to re-compile vm, you'll need to put these constants back
in somewhere, I put them in isearch-mode though there is probably a
better place for them (see my patch a couple of articles back, or mail
me and I'll be glad to ship you a new one).

Anyway, after adding that patch and recompiling vm, it works fine for
me.

------------------------------------------------------------------------------
Jerry Frain, Systems Programmer         |  "Back off man, I'm a scientist."
Kansas State University                 |  frain@cis.ksu.edu
Department of Computer & Info Sciences  |  ...!rutgers!depot!frain
From: frain@cis.ksu.edu (Jerry Frain)
Newsgroups: alt.lucid-emacs.bug
Subject: patch for vm Makefile
Date: 11 Sep 1992 18:37:29 GMT
Organization: Kansas State University, Dept. of Computing and Information Sciences
Distribution: world
NNTP-Posting-Host: depot.cis.ksu.edu


With the addition of vm-lucid.el in the lisp/vm directory, it doesn't
look like the Makefile was modified correctly to compile vm from
scratch.

The vm-lucid.el looks like it is to be loaded separate from vm.el,
which is obvious due to the "(require 'vm)" at the top of vm-lucid.el.

However, vm-lucid.elc was added to the list of BINS in the Makefile to
be cat'd together to make vm.elc.  So, vm-lucid.el doesn't
byte-compile because vm.elc hasn't been made yet.

Here's my patch to the vm Makefile, to make a vm-lucid.elc separate
from (and following) vm.elc:

*** Makefile.~1~        Mon Aug  3 03:04:56 1992
--- Makefile    Thu Sep 10 20:49:47 1992
***************
*** 6,15 ****
  BINS= vm-delete.elc vm-digest.elc vm-edit.elc vm-folder.elc vm-group.elc  \
        vm-license.elc vm-mark.elc vm-message.elc vm-misc.elc vm-motion.elc \
        vm-page.elc vm-reply.elc vm-save.elc vm-search.elc vm-summary.elc   \
!       vm-undo.elc vm-vars.elc vm-version.elc vm-virtual.elc vm-window.elc \
!       vm-lucid.elc
  
! VM:   vm.elc
  
  .el.elc:
        $(EMACS) -batch -q -l ./vm-message.el -l ./vm-misc.el -f batch-byte-compile $(@:.elc=.el)
--- 6,14 ----
  BINS= vm-delete.elc vm-digest.elc vm-edit.elc vm-folder.elc vm-group.elc  \
        vm-license.elc vm-mark.elc vm-message.elc vm-misc.elc vm-motion.elc \
        vm-page.elc vm-reply.elc vm-save.elc vm-search.elc vm-summary.elc   \
!       vm-undo.elc vm-vars.elc vm-version.elc vm-virtual.elc vm-window.elc
  
! VM:   vm.elc vm-lucid.elc
  
  .el.elc:
        $(EMACS) -batch -q -l ./vm-message.el -l ./vm-misc.el -f batch-byte-compile $(@:.elc=.el)
***************
*** 16,21 ****
--- 15,23 ----
  
  vm.elc: $(BINS)
        cat $(BINS) > $@
+ 
+ vm-lucid.elc: vm-lucid.el
+       $(EMACS) -batch -q -f batch-byte-compile vm-lucid.el
  
  vm:   vm.texinfo
        $(EMACS) -batch -q vm.texinfo -f texinfo-format-buffer -f save-buffer
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 15 Sep 1992 19:34:38 EDT
Date: Tue, 15 Sep 1992 16:33:04 PDT
X-Windows: You'll envy the dead.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: SUGGESTION: Permit help strings in menu items.
	<9209152315.AA22975@pts4.pts.mot.com>
Newsgroups: alt.lucid-emacs.bug
It's not distracting.  Trust me.
Newsgroups: alt.lucid-emacs.bug
From: skip@eco.twg.com (Skip Koppenhaver)
Subject: 19.3 coredump
Keywords: coredump
Organization: The Wollongong Group (East Coast Operations)
Date: Thu, 10 Sep 92 16:53:32 GMT

Environment:
============

SunOs 4.1.1
X11R5, patchlevel 17
xemacs built locally using GCC 2.2.2

Description:
============

If xemacs is started without both the TERM and DISPLAY environment
variables set it immediately coredumps. I discovered this when trying
to run it remotely. For example, all the following will coredump:

    rsh <remote> -n xemacs -display <local>:0.0
    rsh <remote> -n 'setenv DISPLAY <local>:0.0; xemacs'
    rsh <remote> -n 'setenv TERM xterm; xemacs -display <local>:0.0'

However, the following will work:

    rsh <remote> -n 'setenv TERM xterm; setenv DISPLAY <local>:0.0; xemacs'

If you start it with just DISPLAY set, it complains about TERM not
being set and then coredumps. In an X environment why is TERM needed
at all?

-- 
Skip Koppenhaver
skip@eco.twg.com
Newsgroups: alt.lucid-emacs.bug
From: Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald)
Subject: How to crash Lucid emacs 19.3 
Organization: Bell Northern Research
Date: Sat, 12 Sep 92 03:16:37 GMT

This came up while using ange-ftp to copy some files.

In the *scratch* buffer, enter the following:

(progn
  (message "%%")
  (garbage-collect))

Then execute it.

emacs should get a fatal error (6).  This is due to an abort deep down
in the bowels of emacs.

The cause is that at some point during the execution of this code,
garbage collection takes place.

In Fgarbage_collect, there is some code that looks like this:

  if (!noninteractive)
    {
#ifdef HAVE_X_WINDOWS
      extern int x_show_normal_cursor (struct screen* s);
      if (!x_show_normal_cursor (s))
#endif
	{
	  if (omessage)
	    message (omessage);
	  else 
	    message ("Garbage collecting...done");
	}
    }

  gc_in_progress = 0;


omessage has been set to the value of the variable "echo_area_glyphs",
which appears to contain the string the echo area was displaying.  I
guess the intent is to redisplay the string which was being displayed
when garbage collecting started.

If the message the echo area was displaying ended in %, then a string
ending in % is passed to message().

doprnt (called by message) dislikes being given a format indication
(%) followed by a null.  It signals an error (using Fsignal).

Unfortunately, Fsignal calls abort if it is called during garbage
collection. 

Fgarbage_collect needs to be fixed to process the "echo_area_glyph"
string so that '%' is converted to '%%' before it passes it to
message.

Also, it seems that the "gc_in_process = 0;" line could be moved above
the message call.  This would allow Fsignal to signal without
aborting.  At this point garbage collection (the meat of it) is
effectively over.

Comments?

Hamish.
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Mon, 14 Sep 1992 10:25:41 EDT
Date: 14 Sep 1992 10:24:52 -0500
From: "Eric L. Schott" <ELS@icf.hrb.com>
Subject: (setq selective-display t)
X-Vms-To: IN%"bug-lucid-emacs@lucid.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Newsgroups: alt.lucid-emacs.bug
With both Lemacs 19.2 and 19.3, the dired-hide-... functions did not work
correctly:  rather than one short line with "...", there was one line
with "^M" where every new line should have been.  I traced the problem
to (setq selective-display t) was not working correctly.  It seems the
code in xdisp.c for this is commented out with "This doesn't work."
Why is this commented out?  Is there a fix?

---
Eric L. Schott,    HRB Systems, Inc.    814/238-4311     els@icf.hrb.com
  "As we acquire more knowledge, things do not become more comprehensible
   but more mysterious."                  Albert Schweitzer, "Paris Notes"
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 15 Sep 1992 16:36:52 EDT
Date: Tue, 15 Sep 1992 15:44:06 EDT
From: bvk%hhb@Princeton.EDU (Brett Kuehner)
Subject: Re: Ange-ftp failures under 19.3
Newsgroups: alt.lucid-emacs.bug
I've noticed that the ftp log buffer seems to have ^M (control-m) characters at the end of every line. Shell mode has this problem as well, which makes some sense as ange-ftp seems to be somewhat built on top of shell-mode. Perhaps this is what is screwing up ange-ftp?

Doing a "stty -echo nl" in a shell-mode buffer fixes the problem for a shell, but I can't figure out how to add this to ange-ftp's startup for local ftp.

I've tried mucking around with setting the ange-ftp gateway to be my machine, just so that it would do call the setup-term-command, but it doesn't seem to work (or, more likely, I've set thing up incorrectly).

Does anyone have a fix to set the terminal mode of shell subprocesses to be equivalent to "stty -echo nl"?

		Brett
--
Brett Kuehner, Racal-Redac, Mahwah, NJ
..!princeton!hhb!bvk
bvk%hhb@princeton.EDU