Re: lynx-dev screen widths

[Bela Lubkin]

Philip Webb wrote:

> some people have claimed -- recently & earlier --
> that preformatting documentation with <br> or <pre>...</pre>
> causes problems for screens wider/narrower than the traditional 79 chars:
> BL displayed text 12 (rather far-fetched) & 50 (more realistic) chars wide,
> the latter causing awkward line-wrapping with <br>'s at c 65 chars.

Do you disagree that such "awkward" line wrapping actually occurs when
the length of each "line" is artificially supplied?

> anything wider than c 80 chars is likely to be hard on R -> L eye movement,

You may think so.  Obviously, however, anyone who has deliberately
chosen to use a wider screen does *not* think so and will not appreciate
your beliefs being imposed.

> so i have a question & a (repeat) suggestion:
> how many lynx-devers regularly use Lynx with a screen width
> noticeably more/less than 79 chars & in what contexts?

Depending on the capabilities of the video board & monitor, I typically
use 100x45 or 120x45 displays.  Lynx works beautifully in those sizes.
I occasionally also pop up a small-font-small-grid window in which to
browse documentation -- making it as small as possible to consume less
screen real estate.  I've used Lynx in 45 or 50 column windows, though
not frequently.

Text which is forcibly wrapped to ~60 columns, as your <BR>-laden
documentation patches, looks vaguely wrong on an 80-column display.  It
looks as disturbingly wrong on a 120-column display as my 12-column
example did to you.

> how difficult would it be to add an Option to vary the screen width,
> incl using the whole of cols 1 - 79 available on a regular screen?

You already have the option of running Lynx within a window of
previously varied size.  Lynx ought to also reach sanely when the size
of the window it's in is changed out from under it.  I haven't tried
that in a while; last I remember, there were patches supplied which made
it work "ok" on some combinations of curses library & OS, but which
still left screen glitches even on those.

I do agree that the normal margins Lynx uses are wasteful and represent
just that sort of imposed preference that I object to above.  They
should be tunable user preferences -- left_margin_cols and
right_margin_cols.

> there might also be an Option to suppress <br>, if it's causing problems.

But <BR> has a perfectly useful and important role elsewhere.  We only
want to suppress *abuse* of <BR>.

You pointed out a number of places in the existing Lynx doc which use
<pre>.  I looked at them.  All but one were carefully laid out visual
tables -- things like keystroke maps.  Some of those could probably have
been better expressed as ordered lists, allowing Lynx to do the
formatting.  One was an image of the "new" HTML options page -- that
would work better as the actual HTML, modified so that the various popup
options and other fields are represented by inactive text showing a
"normal" choice.  Then the example options page would look as much as
possible like the real one that the reader would see if he hit O.

But not a single one was just someone's plain text which he insisted be
wrapped Just So.

>Bela<