> Actually, since I am a cleartext guy, I want my texts wrapped in their > files. Those are almost always TeX files, and TeX does not like 50000 > character lines, anyway. Also, I have syntactical indentation in > AUCTeX, and this sort of display-induced wrapping would not help > much. > > So I am not really much of a customer of longlines.el, anyway. Your > display-based approach would probably have the advantage that the line > numbers in the source still correspond with the line numbers on file, > making error messages turn out correctly.
A relatively easy way to extend longlines.el is to write a function that intelligently converts a buffer full of hard newlines into a longlines buffer. The simplest (but probably not the best) heuristic is to make "\n\n" hard newlines, and single "\n" characters soft newlines. Then you can have a file full of newlines that plays well with latex, and other programs that expect newlines. When the file is loaded into Emacs, you can use this function to turn into a longlines buffer, so you get the line wrapping functionality. Error message line numbers would correspond to the line numbers in the buffer. (With the display-based approach, even though the line numbers turn out correctly, it may be hard to find the error; for example, "line 3" may be a paragraph that takes up 50 screen lines.) One thing that longlines.el is unlikely ever to accomplish is support for proportional fonts and images. That is the big advantage of Kim's approach (which makes the planned "longlines-2" obsolete, so it's a good thing I haven't done much work on it ;-) Another advantage of the display-based approach is that it will never screw up font-lock highlighting, as longlines.el often does. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
