zsh-workers
 help / color / mirror / code / Atom feed
From: Clint Adams <clint@zsh.org>
To: Peter Stephenson <pws@csr.com>
Cc: Zsh Hackers' List <zsh-workers@sunsite.dk>
Subject: Re: PATCH: curses tweaks, maybe
Date: Tue, 16 Oct 2007 23:29:55 -0400	[thread overview]
Message-ID: <20071017032955.GA25480@scowler.net> (raw)
In-Reply-To: <20071016094040.4a48a750@news01>

On Tue, Oct 16, 2007 at 09:40:40AM +0100, Peter Stephenson wrote:
> Also, a refresh() is needed after deleting a window, otherwise nothing
> works when you add a new one.  It's not clear where this should be,
> however.  If the intent is that the user can stack up commands before
> refreshing we would need that as a user command, but we might well
> need to ensure that it got called anyway before things got too hopefully
> messed up (e.g. it would probably need to be called just before, or
> presumably in place of, a wrefresh() for a new window).  So this will do
> for now.

I think we should provide refresh() as zcurses -R.  Apparently (at least
according to http://invisible-island.net/ncurses/ncurses-intro.html ;
I've not tried it) we can do an endwin() with zcurses -e, mess around with
normal shell output, then redraw with refresh() and resume where we've
left off.

> I think I've tracked it down to this: if zsh/curses gets loaded here,
> onclr is turned off; if zsh/curses was already loaded then it's OK.
> Presumably the difference is that from the command line zsh is doing it's
> sanity checks (but I don't quite understand why they don't happen after the
> above).  This is from initscr().  The functions nonl() / nl() seem to
> control this in curses, but they docs suggest the setting isn't changed
> automatically, which seems to be wrong.

I think I just read somewhere (though I can't find it now) that nl() is
the default and that nonl() provides speed benefits if you don't need
the translation.  Maybe we should unconditionally run nonl() after
initscr(), since we don't support (yet?) any curses input functionality
and anyone passing a literal newline to zcurses -s (does this work for
you either?) can probably be bothered to pass a CR too.

> Perhaps to be safe we should be requiring all use of curses to be between
> commands such as zcurses -i and zcurses -e, as below?  After all, it's
> reasonable to suppose this doesn't fit in with normal shell line-by-line
> character handling.  This fixes Bart's gripe about clearing the screen.

We could; maybe they could take arguments and initialize/delete
multiple terminals/screens if we want to support that as well (and skip
initscr() altogether).

> Even with this code I only got it to work by both saving the terminal state
> from before zcurses -i, and when I restore it on zcurses -e ensuring that
> shttyinfo is the same---this seems a bit hairy.  (I had a panic attack that
> shttyinfo.winsize would be screwed up, too, but
> settyinfo() doesn't alter that.)

I wonder why this is necessary.

> This seemed to work.   Probably zcurses -e, if it stays, should do more
> work, such as deleting any remaining windows.  (That could fix up the
> refresh() issue mentioned at the top in the case where we delete all
> windows.)

Maybe zcurses -d with no arguments could delete all, or we could have a
separate endwin()-only command for use in the endwin()/refresh() trick
described up top.


  reply	other threads:[~2007-10-17  3:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-16  8:40 Peter Stephenson
2007-10-17  3:29 ` Clint Adams [this message]
2007-10-17  8:57   ` Peter Stephenson
2007-10-17  9:14     ` Peter Stephenson
2007-10-17 13:01       ` Clint Adams
2007-10-17 14:57       ` Bart Schaefer
2007-10-17 15:05         ` Peter Stephenson
2007-10-17 15:25           ` Clint Adams
2007-10-17 15:39             ` Peter Stephenson
2007-10-17 18:58               ` Clint Adams
2007-10-17 19:19                 ` Clint Adams
2007-10-18 20:40               ` Clint Adams
2007-10-20 12:12                 ` Peter Stephenson
2007-10-20 13:37                   ` Clint Adams
2007-10-21 19:50                     ` Clint Adams
2007-10-21 21:13                     ` Clint Adams
2007-10-17 17:09             ` Bart Schaefer
2007-10-17 17:53               ` 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=20071017032955.GA25480@scowler.net \
    --to=clint@zsh.org \
    --cc=pws@csr.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).