Re: LYNX-DEV WRAPPING

[Foteos Macrides]

Walter Skorski <address@hidden> wrote:
>Foteos Macrides writes:
>
>> address@hidden (Paul Gilmartin) wrote:
>> > In a recent note, Foteos Macrides said:
>> >
>> > >  No.  Lynx reserves the right-most column of the screen for
>> > > positioning the cursor without risk of invoking an unintended newline
>> > > under any circumstances.
>
>PMJI (again), but isn't the point of termcap/terminfo and the
>curses/ncurses libraries to account for and deal with these sort of
>idiosyncrasies, so that the application programmer doesn't have to
>think about them?  And hasn't this particular idiosyncrasy been
>adequately addressed in this way?

        No.  This issue normally comes up when Lynx is being used to
display text/plain.  For text/html, the rendering normally collapses
spaces, tabs, and newlines, wherever they appear physically, so that
the formatting reflects the parsing rules for the markup, and the left
and right margins for the style associated with each block in the markup.
No style has a right margin beyond the screen width minus one, because
the display process can include directives for positioning the cursor
in the column beyond the last character (including spaces) in the line,
and if that last character is in the right-most column of the screen,
such a directive for the cursor (to a position beyond the right-most
column of the screen), for many curses implementations causes a newline
that wasn't intended, and won't be know to the HText translation and
display functions in Lynx.  Spaces are not collapsed, and tabs are
expanded, for PRE, PLAINTEXT and XMP, and the styles for those blocks
have a left margin of zero and a right margin of one, i.e., text is
restricted to columns 0-78 for an 80 column screen, and any character
(or space) which would extend to the right-most column (79) is wrapped,
and a new line entry is started in the HText structure, when parsing
the input stream and constructing an HText structure.  In those cases,
if you stick an IBM text file which has 80 character records with
trailing space padding into a PRE, PLAINTEXT or XMP block, you'd
similarly get the last character (or space) of each record wrapped to
the start of another HText structure line.

        The important point, which needs to be, and is, explained
regularly to new people on the list (is an FAQ), but should be
understood by now for the *regulars* on this list like you and Paul,
is that Lynx is *not* a file viewer.  EVERYTHING it displays is
"rendered" into a complex HText structure and handled as HTML,
*including* text/plain documents (The latter are treated as if they
were text/html with an implied BODY containing an implied XMP block
that encompasses the entire input stream.).  The regulars should by
now (shouldn't they?) be giving the newcomers the oft given advice
to include most, or less, or whatever is their favorite, feature rich,
file viewer, as options in the 'p'rint and 'd'ownload menus for
viewing any text/plain files that can't be handled adequately with
the "fake HTML" strategy in Lynx.  And it doesn't make any sense,
IMHO, to add fancy text file viewing features to Lynx, when it's
become so large already and still needs more to keep up with its
primary purpose of handling "real" HTML and the internally
generated HTML for its network gateway functions.  Concentrate
on developing the things that really matter, and cannot be
accomplished via helper apps that are already designed to do
the other things well (of course, one *could* make Netscape or
MSIE Lynx's helper app for text/html 8-).

        
>>      There is no obligation for you to use Lynx if it is too irritating
>> for you, and you obtained it free of charge, with sources, should you
>> wish to redesign it.
>
>There are many things about Lynx that I'd like to redesign, but I
>don't consider myself to be well versed enough in Lynx's internals or
>C to do them myself; rather, I (and others) pick these nits publicly,
>here in lynx-dev, in hopes that those more experienced will say "yeah,
>that's a good idea" and make it a reality.  Expecting everyone with a
>good idea to produce a patch from it, however, isn't realistic, and
>encouraging poorly thought out patches may be counterproductive.

        I was not recommending to Paul that he generate a patch for
inclusion in the general distribution.  I had answered the FAQ from
a newcomer, and then Paul -- who has read many previous explanations
of the screen-width-minus-one rendering issue, and is using an Xterm
with Lynx which he can set to a screen width of 81 for viewing IBM
padded text files -- took this as an opportunity to express his
"irritation" at a "bug" in Lynx.  So I in turn took that as an
opportunity to express my own irritation at the mentality and 
communication style he brought to the discussion (but perhaps what's
good for the goose is not good for the gander 8-).

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;