[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2 Echolines Bug

    Return-path: <Zubkoff%TARTAN@CMU-CS-C>
    Received: from TARTAN by CMU-CS-C with TLnet; 21 Jul 83 01:47:59-EDT
    Received: ID <ZUBKOFF@TARTAN-20.TL>; Thu 21 Jul 83 01:49:09-EDT
    Date: Thu, 21 Jul 1983  01:49 EDT
    From: Leonard N. Zubkoff <Zubkoff%TARTAN@CMU-CS-C>
    To:   Charles Rich <RICH%MIT-OZ@MIT-MC>
    Subject: ** New ZEmacs **


    It seems strange to me that such a well-known Emacs-Twenex screw
    has never hit me in over three years of almost exclusively using
    local terminals with two echo lines on CMUC and TARTAN.  Let me
    see if we agree on exactly what's happening.  At some point, one
    executes a command such as C-X C-W that does a Comnd% parse of a
    file name from the echo area.  The entire prompt plus file name
    fits on one line (right below the mode line), as in

    Write File (Default PS:<ZUBKOFF>MAIL.TEMP.0): Foo.bar.5

With echolines set to 2.

    and yet the CR somehow echoes in a manner that causes the top line
    of the screen to (1) disappear entirely or (2) be cleared.

I think the problem is that a second CR is getting generated
by the system call prompt in addition to the one that I type to
end the command in Emacs.

I am not sure of the distinction you mean.  It becomes blank.  The
rest of the screen is unchanged

    this problem only manifests itself on local terminals (not Chaos,
    for example).

No, I can repeat the problem on C108 through dialup into hardwire
port, and on AAA through our Chaosnet terminal concentrator, and
on local hardwire AAA.

    Has this problem actually happened to you with the new ZEmacs and
    if so, is it repeatable on demand? If not on demand, does it
    happen at all consistently?

It is repeatable on demand with both standard Emacs, the old ZEmacs
and the new ZEmacs.

    Have you ever seen the problem on
    other than a Concept-LNZ terminal?  Concept-HDS terminal?

See above.

    this only happen on MIT Twenices, or have you seen it occur
    elsewhere as well?

I don't know.

    Does it only happen with WRAP mode, or with
    SCROLL as well?  My suspicion is that MIT's WRAP mode, which is an
    extension to Tops-20, is causing a CR or LF to automatically WRAP
    and clear the top line of the screen when it shouldn't (that's why
    I need to know if the top line is really cleared, deleted, or
    merely scrolled off the top but still present in the terminal).

**** Yes, I think you are right.  If I set TERM NO WRAP before I start
up the Emacs, then the problem goes away.  It also seems that if I
turn WRAP back on afterward, the problem does not come back, i.e.
Emacs caches this terminal parameters.  This suggests that the
solution might be just to fix this parameters in Emacs to always be No
Wrap, regardless of what the external environment is.  (P.S. I can't
stand scrolling in my exec.)

    If you can give me a good idea what the conditions are that make
    this happen, perhaps I will be able to find the problem, or come
    up with a way around it.  

Thanks, very much for your effort.  It would be nice to have the extra
line of editing space.

    As a last resort, there's going back to
    3 echo lines, but to do that right I'd have to re-build special
    versions of the screen managers with that knowledge built in.

Strange.  I reset echolines to 3 in my init file using the new
Zemacs on my C108 dialup, and it seems to work perfectly.