Re: lynx-dev Re: Final dev15 patch for TEXTAREA edit feature (I hope)

[Leonid Pauzner]

5-Feb-99 05:22 Kim DeVaughn wrote:
> On Fri, Feb 05, 1999, Leonid Pauzner (address@hidden) said:
> |
> | Thanks for your work, looks very nice.
> |
> | But:

> There is *always* a "but", isn't there ... :-) ...
Well, yes :-)

| >>  3. Hitting the reset buton is now handled properly WRT the "old"
| >>     text in expansion lines (now *always* empty).
> | The same thing when I remove several lines with the editor:
> | I got a bunck of blank lines at the bottom of textarea.
> | Think the textarea #lines should be restored properly
> | (decrease #lines the same way as it was increased
> | according the text received from the editor).

> Yeah ... currently, TEXTAREA expansion is a one way street, with no
> provision to shrink it back down to the original size, nor to remove
> any trailing blank lines/anchors as a result of subsequent editor
> invocations.

> I considered doing that, but the one thing I need to solve before it
> could be implemented, is that of cursor movement to a specific line
> within the TEXTAREA.  That functionality isn't *required* for expansion,
> since the cursor can quite happily be left on the original line, but
> for shrinking, the cursor *must* be moved to some line within the area
                            ^^^^^^
but only when it became matched out of new textarea, which is not always.
So you may implement a way back for a "good" cases, leaving "bad" cases
as is until the cursor movement will be solved (it may be derived
from mainloop() scrolling code, I will look in).
And yes, singly linked list should be tweaked (I haven't thought on it).


> that remains after shrinking (when the cursor's anchor was quite likely
> yanked out from under it).

> It will also be a bit more of a PITA to update [tag] position offsets,
> since the anchor struct is (currently) a singly linked-list, and can
> only be naturally traversed in the expansion direction.

> Anyway, I'll keep it in mind, but the cursor repositioning problem is
> the one thing that *must* be solved first.