lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Forms Word Wrap Problem with Lynx


From: Klaus Weide
Subject: Re: lynx-dev Forms Word Wrap Problem with Lynx
Date: Fri, 23 Jul 1999 09:52:01 -0500 (CDT)

On Fri, 23 Jul 1999, Kim DeVaughn wrote:

> On Fri, Jul 23, 1999, Klaus Weide (address@hidden) said:
> |
> | As an alternative, the users could be prevented from adding lines that
> | are too long.  The mechanism for that is already there: for text INPUT
> | fields lynx implements a MAXLENGTH attribute.  It is not recognized
> | for TEXTAREA (in accordance with HTML 4.0), but if you use lynx only
> | internally, modifying the source to get a version that supports it
> | anyway wouldn't be difficult (or you could just hardwire some value
> | in, but that sounds like a bad idea - no flixibility at all).  I don't
> | know how this would interact with the external editor invocation of
> | 2.8.2 though.
> 
> I do (know how doing so would interact with external editing).  Badness
> would happen (generally speaking).
> 
> The external editing code (as well as the insert file code) does no
> checking for edited lines that exceed MAX_LINE (which is the def used
> for the HTLine structs).

Different topic; MAX_LINE != "MAXLENGTH".

> Such checking *could* be added, of course, and excessively long lines

It *should*. :)

> broken/truncated/ignored/rejected/whatever, but since the define for
> MAX_LINE says:
> 
>   #define MAX_LINE 1024    /* Hope that no window is larger than this */
>                               ^^^^
> 
> and since I didn't really see HTLines being checked elsewhere for exceeding
> the MAX_LINE value, and for performance reasons, I didn't do any checking
> either.

The only way lines can grow or be added used to be HText_appendCharacter
and split_line, and the code there makes sure that lines never can grow
too long (assuming it all works, give or take a few...).

But any new way of adding lines *really* should check for MAX_LINE.
(According to what you write about not checking, I guess trying to insert
a binary file into a textarea would likely crash lynx, but haven't tried
it.)

In my reading, the "hope" is about whether the fixed value is large enough
to allow using the full width of windows, not about wehether it is big
enough to "usually" avoid crashes.

> I suspect that if the defines that control various line lengths were to
> be significantly reduced from their existing (very large) values, many
> things in lynx would break, as well.

"MAXLENGTH" for input fields is really unrelated.  (See form->maxlength
in form->getstr, I.maxlength in HTML.c).  Even if there were a way to
set maxlength for textarea lines - the external editor wouldn't have
to know about it and could exceed it. I assume the code in form_getstr
can deal with that, it just wouldn't allow adding more characters in
by normal line-editing.

   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]