>> But IMHO \n's themselves are outdated. They are a thing of 80x25 text
>> terminals era.
>
> Not true. Visually, yes, in today's WYSIWYG world \n is not a
>good indicator of when to linewrap. However, this is a text widget, not a
>word processor.
>
> When a program compile fails, gcc (or perl, or wish, etc.) tells
>you what line number the error occured on. When you debug a program with
>gdb, you set the breakpoints by line number. 'wc' reports lines based on
>\n, and some companies use lines of code as a productivity indicator.
>diff, RCS, CVS, all these things depend heavily on the good ol' \n.
>
> I want my application to be able to display the current line
>number (by \n count), and to be able to create diffs, etc. All that
>requires an easy system to handle a "line".
Certainly. But this has nothing to do with the visual display. The
fact that an error occured on line N doesn't mean that it occurs on
"line N" of the text widget. What you're wanting is a method to (1)
easily find the text corresponding to line N and (2) easily find the
location in a window of the text. These are two different tasks, and
they are not necessarily complementary.
--p
--
To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null