public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: David Sastre Medina <d.sastre.medina@gmail.com>
To: cygwin@cygwin.com
Subject: Re: mintty scroll to bottom
Date: Tue, 06 Mar 2012 19:46:00 -0000	[thread overview]
Message-ID: <20120306194622.GA6006@jethro.local.lan> (raw)
In-Reply-To: <CC0D9E8456BA41488A76AFE4E8F3A3690330FD5F@de011305.de.ina.com>

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]

On Mon, Mar 05, 2012 at 07:57:29PM +0100, Lemke, Michael  SZ/HZA-ZSW wrote:
> On March 05, 2012 6:26 PM Ryan Johnson wrote:
> >On 05/03/2012 5:05 AM, Lemke, Michael SZ/HZA-ZSW wrote:
> >> On March 04, 2012 12:51 PM, Corinna Vinschen wrote:
> >>> On Mar  2 20:20, Andy Koppe wrote:
> >>>> On 2 March 2012 08:41, Corinna Vinschen wrote:
> >>>>> On Mar  1 20:43, Andy Koppe wrote:
> >>>>>> On 29 February 2012 12:46, Lemke, Michael  SZ/HZA-ZSW wrote:
> >>>>>>> What is the mintty equivalent to rxvt/xterm's
> >>>>>>>
> >>>>>>> -si|+si
> >>>>>>>               Turn on/off scroll-to-bottom on TTY output inhibit;
> >>>>>>>               resource scrollTtyOutput has opposite effect.
> >>>>>> There's no such option. Shift+End will get you back to the current
> >>>>>> output after looking at something in the scrollback, as will any
> >>>>>> keypress that sends something to the terminal.
> >>>>> Any chance to implement this?  Automatic scroll-to-bottom is a useful
> >>>>> feature, IMHO.
> >>>> I disagree. The point of being able to scroll back to earlier output
> >>>> is to read and perhaps copy something. When doing that, having the
> >>>> scrollback jump back to the bottom without the user asking for it is
> >>>> rather unhelpful. The Windows console does this, and I always found it
> >>>> really frustrating.
> >>> THat's why this is an option in xterm.  Every use has another idea how
> >>> the terminal should behave in this regard, I guess.
> >> I'd also appreciate very much implementing that option.  mintty is
> >> promoted here as a replacement for rxvt but obviously lacks a functionality
> >> I've come to depend on.  My use case is a terminal window in which I don't
> >> do much but where a lot of background jobs regularly produce output.
> >> A quick glance at the window tells me the current status of those jobs.
> >> Not with mintty anymore.  Same with the classic use case tail -f logfile.
> >What you describe above sounds more like mintty allowing a visible "end 
> >of output" to scroll off the bottom without following it, a behavior 
> >I've never observed and which would arguably be a bug.
> 
> That's not what I said.
> 
> >
> >When I fire up something that produces copious output (gcc bootstrap, 
> >compile emacs, etc.) mintty scrolls to track end-of-output unless I 
> >purposefully scroll upward 
> 
> Right, same here.  Turning on scroll-to-bottom would change that.  It
> scrolls to bottom immediately.
> 
> >(in which case I'd prefer it to stay put long 
> >enough to read/copy the text rather than immediately jumping me back to 
> >end-of-output). 
> 
> That depends on what I am doing in such a terminal.  I might have a
> tail -f /var/log/messages & in that session on a system with low 
> syslog activity.  I want to be notified immediately if there is 
> output and don't mind being interrupted.
> 
> >Once the scrollbar is set back to bottom, it again 
> >tracks end-of-output. 
> 
> Correct.  And that's the step I want to skip.  The si-option does
> exactly that.
> 
> >
> >Am I missing something? Or do your background jobs just produce output 
> >really infrequently compared to 'make all'?
> 
> In this case yes, but I also like scroll-to-bottom if there's more output.
> 
> >The latter is the only way I 
> >can see "reading stuff from the past" and "scroll-to-bottom" coexisting 
> >peacefully 
> 
> They usually won't.  That’s why this should be an option and not the 
> default.

Most of the behaviour discussed in this thread can be achieved or
emulated using screen (notification on activity, scroll and output
logging at will, etc). Might be useful to take a look at it.

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

      reply	other threads:[~2012-03-06 19:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-29 12:49 Lemke, Michael  SZ/HZA-ZSW
2012-03-01 10:19 ` Corinna Vinschen
2012-03-01 20:45   ` Andy Koppe
2012-03-01 20:43 ` Andy Koppe
2012-03-02  8:42   ` Corinna Vinschen
2012-03-02 20:21     ` Andy Koppe
2012-03-02 20:40       ` Ryan Johnson
2012-03-03  9:24         ` Andy Koppe
2012-03-04 11:51       ` Corinna Vinschen
2012-03-05 10:05         ` Lemke, Michael  SZ/HZA-ZSW
2012-03-05 17:25           ` Ryan Johnson
2012-03-05 18:35             ` Andrey Repin
2012-03-05 18:57             ` Lemke, Michael  SZ/HZA-ZSW
2012-03-06 19:46               ` David Sastre Medina [this message]

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=20120306194622.GA6006@jethro.local.lan \
    --to=d.sastre.medina@gmail.com \
    --cc=cygwin@cygwin.com \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).