Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 May 2000 18:20:24 -0400 (EDT)
From:      Brian Fundakowski Feldman <green@FreeBSD.org>
To:        Tim Vanderhoek <vanderh@ecf.utoronto.ca>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/usr.bin/more prim.c
Message-ID:  <Pine.BSF.4.21.0005211805270.54798-100000@green.dyndns.org>
In-Reply-To: <20000521174623.A10303@mad>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005211805270.54798-100000>