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
next prev parent 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).