zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: Zsh Hackers' List <zsh-workers@sunsite.dk>
Subject: Re: read -s doesn't work with -t?
Date: Sun, 17 Feb 2008 17:22:25 +0000	[thread overview]
Message-ID: <20080217172225.1d8a8e4e@pws-pc> (raw)
In-Reply-To: <080216093755.ZM17001@torch.brasslantern.com>

(I've moved this to zsh-workers since this is involved enough
even for developers.)

On Sat, 16 Feb 2008 09:37:53 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> It also seems to me that canonical input mode should be set and the
> prompt should be printed before the read-timeout poll is done, so -d
> should come before -t as well.  However, I'm not really sure what's
> going on with shttyinfo versus saveti, so I'm not going to commit the
> following until somebody else checks it over.

It's not obvious to me quite what the difference is, and I suspect that
if bin_read() hadn't grown quite so organically (this is not a term of
approbation) it would me more obvious that they could be combined.

I suspect it's just the fact that the -s and -d code has been written
differently from the -k code.  The latter assumes it's a good idea to
keep the normal shell state (shttyinfo) in sync; this is complicated by
the fact that in non-interactive usage we have to set up shttyinfo if it
wasn't already.  The former assumes it should just alter the current
settings and restore them to what they were afterwards.  The whole thing
is further complicated by the fact that we (I've certainly mucked
around with it, too) do different things depending on additional options
to -k.  This is just a hypothesis.

To be honest, I can't really follow all the ins and outs and if your
patch works (checking -k in combination with other options is probably
the key) it's probably good enough and we can see if problems turn up as
time passes.

It would be nice to have tests but they're particularly difficult to
write for this.

> And of course there may be some kind of bad interaction between changing
> the tty state and reading typeahead that I'm not aware of that makes all
> this impossible, in which case it should just be documented that you
> can't use a prompt or -s or -d in combination with -t.

With a bit of luck, weird interactions of this kind may be just a bad
memory now... I've a vague memory Ultrix came into it.  I don't think we
ever deliberately attempted to handle this outside zle, in any case, but
I could be wrong.  Certainly the word "typeahead", with or without
a hyphen, only seems to occur in Zle (and input.c where we're about
to call Zle.)

> That thread just sort of died without resolution because PWS can't
> reproduce the problem.

I suspect that was more to do with the fact that the xterm stuff wasn't
doing the right thing for me rather than that the shell *was* doing the
right thing, but I never really got to the bottom of it.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/


       reply	other threads:[~2008-02-17 17:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <237967ef0802151327q1c6d3a19oa67a977b82c52f67@mail.gmail.com>
     [not found] ` <080215191216.ZM29994@torch.brasslantern.com>
     [not found]   ` <237967ef0802152333g7f759674r806f61f9f76f86f2@mail.gmail.com>
     [not found]     ` <237967ef0802152350i1fec3369oba9268400a209b2e@mail.gmail.com>
     [not found]       ` <080216093755.ZM17001@torch.brasslantern.com>
2008-02-17 17:22         ` Peter Stephenson [this message]
2008-02-18  2:16           ` Bart Schaefer
2008-02-18  9:55             ` Peter Stephenson

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=20080217172225.1d8a8e4e@pws-pc \
    --to=p.w.stephenson@ntlworld.com \
    --cc=zsh-workers@sunsite.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).