zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Zsh Workers <zsh-workers@sunsite.auc.dk>
Subject: Re: BUG: vared in function
Date: Thu, 1 Jun 2000 04:55:33 +0000	[thread overview]
Message-ID: <1000601045533.ZM29369@candle.brasslantern.com> (raw)
In-Reply-To: <000531170017.ZM27165@candle.brasslantern.com>

On May 31,  5:00pm, Bart Schaefer wrote:
} Subject: Re: BUG: vared in function
}
} On May 31, 11:28pm, Peter Stephenson wrote:
} > Subject: Re: BUG: vared in function
} > Peter Stephenson wrote:
} > > Bernd Eggink wrote:
} > > > Argh... 
} > > > 
} > > >    # t
} > > >    vared -cp "Aha: " BLAH
} > > > 
} > > >    % t
} > > >    t:vared:2: ZLE not enabled
} > > > 
} > > > This breaks lots of my scripts! 
} 
} This is happening because of my bug report to the effect that vared was
} improperly munging the TTY settings in an interactive shell that had ZLE
} explicitly turned off (as e.g. inside and emacs shell buffer).
} 
} I don't know how that interacts with Peter's patch (I'll try it later when
} I get home).

I should have been able to tell by looking closely at the patch, but this
re-breaks things when interactive in an emacs buffer without doing anything
new and useful for vared when not interactive.

In addition to the bug I previously mentioned:

} If you're going to pull this stuff out into a function, you need three
} return states, not two.

There's also a potential too-early return from bin_vared() a few lines
after the call to openttyspecially(), where `if (zleactive)' is tested,
and several more below that.  Can't just move the place where the tty
gets opened like that.

Peter had asked:

} > I don't think there's any good reason why zle shouldn't be enabled
} > especially.
} 
} In fact, what about this?  If it works for read, shouldn't it work for
} vared?

The difference is that `read' tests specifically for emacs-ness and does
not play with the tty settings in that case.  Running `vared' inside an
emacs buffer is the moral equivalent of running `vi' in one; it simply
can't work at all when it can't drive the editing itself.

You could ALMOST make `vared -c' work, but for any variable that already
has a value emacs is going to treat the old value as part of the prompt.

Given all of this, let's NOT use 11698, and instead use this:

Index: Src/Zle/zle_main.c
===================================================================
@@ -743,7 +743,7 @@
     char *p1 = NULL, *p2 = NULL;
     FILE *oshout = NULL;
 
-    if (unset(USEZLE)) {
+    if ((interact && unset(USEZLE)) || !strcmp(term, "emacs")) {
 	zwarnnam(name, "ZLE not enabled", NULL, 0);
 	return 1;
     }

Even this is not totally satisfactory, because modern versions of emacs
export TERM=dumb and EMACS=t rather than TERM=emacs.  However, TERM=emacs
is the canonical way to tell zsh it's in an emacs buffer, so I've had this
in my .zshrc for a while now:

case ${TERM:-dumb} in
emacs|dumb)
    [[ $EMACS = t ]] || return 0
    TERM=emacs
    export EDITOR=emacs
    stty -onlcr -echo
    ttyctl -f			# Doesn't really do any good
    ;;
eterm)
    TERM=vt100
    ;;
esac

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


  reply	other threads:[~2000-06-01  4:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-31 21:06 Bernd Eggink
2000-05-31 21:55 ` Peter Stephenson
2000-05-31 22:28   ` Peter Stephenson
2000-06-01  0:00     ` Bart Schaefer
2000-06-01  4:55       ` Bart Schaefer [this message]
2000-06-01  7:58   ` BUG: vared in script (was: vared in function) Bernd Eggink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1000601045533.ZM29369@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).