From owner-cvs-all Sun May 21 15:20:32 2000 Delivered-To: cvs-all@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id AD32237B6E2; Sun, 21 May 2000 15:20:25 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 21 May 2000 18:20:24 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Tim Vanderhoek Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/more prim.c In-Reply-To: <20000521174623.A10303@mad> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 May 2000, Tim Vanderhoek wrote: > On Sun, May 21, 2000 at 11:35:28AM -0700, Brian Feldman wrote: > > > Log: > > In the modern world, things are much faster than when more(1) was created. > > Scrolling sideways is fast, and a "...skipping..." message making everything > > blink does much more harm than good. > > I agree, but this commit kinda breaks reading short files when -e is > specified. It probably also breaks tags and searches in some > instances, but I didn't bother testing. It needs to be done differently. I don't see any differences here, actually. > My plans, short-term, have been to keep the "...skipping..." for the > sake of short files, and also modify more(1) to pretend -c was > specified if the user redraws the screen with ^L. That would probably do a good job of hiding it :) > Under syscons I never see the "...skipping...". Does the message > actually harm output on some terminals? If so, the correct fix is to > add a heuristic to guess when the output will fill a full screen or > not. Such a heuristic would have a very low failure rate. It happens all the time in X terminals, and is extremely distracting when scrolling around since it makes everything jump up and down. I think this is a good idea (the heuristic), as it would solve the problem pretty well. > I am not the maintainer of more, but, I suggest that you either > implement such a heuristic, encourage someone else to implement such a > heuristic, or leave it with the previous behaviour. > > By "kinda breaks" I mean that you cannot see where the top of the file > is without either a line-by-line analysis or, in some cases, probably > a semantical analysis would be required to determine the top of the > file. > > Actually, semantical analysis is always potentially necessary, since > there's no reason "...skipping..." can't occur within the file being > viewed, but this makes it more likely to be needed (think tags and > searchs). I think it's a pretty big red herring to have anything at all not the text itself printed on the screen. It's one thing to regard one line as the status line, but it's a pretty bad idea in general to do anything which adulterates the text. I think the feature itself really needs to be thought out again, because as it is now it can hurt plenty of cases that it doesn't help. It's also undocumented... maybe we should look at what some of the other pagers do? > > -- > Signature withheld by request of author. > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message