zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Mario Lang <mlang@home.delysid.org>, zsh-workers@sunsite.dk
Subject: Re: ZSpeak! Only Zsh can do this!
Date: Fri, 16 Mar 2001 18:23:17 +0000	[thread overview]
Message-ID: <1010316182317.ZM5902@candle.brasslantern.com> (raw)
In-Reply-To: <874rwtzteq.fsf@home.delysid.org>

On Mar 16,  3:21pm, Mario Lang wrote:
} Subject: ZSpeak! Only Zsh can do this!
} 
} OK, here we go. Please mail me with every (minor|major) suggestion.
} I can use everything. Especially to learn nice Zsh techniques.
} 
} # * Find a nice way to add/remove keybindings in speech-(on|off)

Finding a nice way to remove keybindings is sort of a general topic of
discussion right now.

For the rebindings of forward-char and backward-char, look at the way
it's done in Functions/Zle/predict-on (in the predict-off function).

} # * Find a way to make the prefix key-sequence configurable (^[v)

That should be as easy as stashing it in a parameter.  Or you could use
the zstyle mechanism.

} # * Modify the completion system so that menu-completion inserted
} #   text gets spoken.

Hrm, that one probably requires C source code changes.

} # * Find a way to read stdout/stderr of commands too! is exec my friend?

Yes, of course!

Let me jump ahead a bit, though:

} speak-string () {
}     # Here goes the compatibility code. All synth specific
}     # decissions when outputting text should be done here.
}     case $ZSPEAK_SYNTH in
} 	festival)
} 	    [[ -x `which festival` ]] && print "$@"|festival --tts
} 	    ;;
}         speechd)
} 	    [[ -e "/dev/speech" ]] && print "$@">/dev/speech
} 	    ;;
} 	*)
}     esac
} }

I'm not familiar with how "festival" works, but if it can accept a series
of lines and speak each one as it sees the newline, you can use a feature
of zsh's coproc mechanism to emulate /dev/speech.

Rather than test for the existence of festival every time speak-string is
called, you set it up in advance like this:

    if [[ $ZSPEAK_SYNTH == festival && -x `which festival` ]]
    then
      coproc festival --tts
      speak-string () {
        print -p "$@"
      }
    elif [[ [[ $ZSPEAK_SYNTH == speechd && -e /dev/speech ]]
      speak-string () {
        print "$@" > /dev/speech
      }
    else
      speak-string () { }
    fi

Now "print -p" sends its output to the speech synthesizer, as does any
command whose output is redirected with ">&p".  Unlike ksh coprocesses,
zsh holds open the coproc descriptors even when redirection has been
done, so as long as festival doesn't exit, you can redirect the output
of every command through it.

Of course this may have unwanted side-effects if festival holds open a
sound device, thereby preventing other sound processes from using it.
However, I'll proceed on the assumption that's not the case.  Also, it
means you can't use "coproc" for anything else, but in my experience
hardly anyone ever uses zsh coprocesses in the first place.

With the coproc in place, if you want to, you can take advantage of
"multios" like so:

    setopt multios
    exec 2>&1 2>&p	# Send stderr to both stdout and synthesizer
    exec >&2		# Send stdout to the two places stderr goes

Now everything output by any command that isn't explicitly redirected
somewhere else, will be both written to the terminal (or wherever fd 1
was originally pointing) and spoken.

Replace >&p with >/dev/speech in the first exec if using speechd, but
again the caveat about holding the device open may apply.

Note that some commands, such as "less", may attempt to use fd 2 for
interactive input when their standard input is a pipe.  In that case
the above trick of multi-redirecting stderr works very badly.

-- 
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   


  parent reply	other threads:[~2001-03-16 18:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-16 14:21 Mario Lang
2001-03-16 14:39 ` Peter Stephenson
2001-03-16 18:23 ` Bart Schaefer [this message]
2001-03-19 10:07 Sven Wischnowsky
2001-03-21 17:18 ` Mario Lang
2001-03-22  6:52   ` Bart Schaefer
2001-03-23  8:42     ` Bart Schaefer

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=1010316182317.ZM5902@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=mlang@home.delysid.org \
    --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).