[EMAIL PROTECTED] (Kim F. Storm) writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> Another thing worth mentioning is that in the presence of images, >> font locking with different font sizes, proportional fonts and >> similar, the wrapped column should certainly be the visual column >> instead of anything else. This means, for example, that it is >> completely useless to insert a newline in the middle of an image: >> it only makes sense to replace such spaces that have a different >> visual column. Unfortunately, current-column does not take images >> into account. > > > Perhaps you would like to experiment a little with the following > patch which implements non-destructive line-wrapping during > redisplay, i.e. it automatically breaks _displayed_ lines at > suitable spaces and tabs.
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. Personally, I think one should "just" be able to place something like '(display (when (> (+ current-goal-pixel current-space-width) current-frame-pixel-width) "\n")) into the display table at the position of space, and that's that. Oh wait. This would always break too late. Well, but the idea is fun. For preview-latex+AUCTeX, one would want preferably want to wrap such that a) the file does not contain lines longer than fill-width b) the screen does not contain material wider than the frame edge Since AUCTeX should usually provide source-text WYSIWYG (namely: you should retain full control over the formatting of your source file, including the newlines), this means a combination of wrapping at unadorned text columns and screen positions. So a solution completely encapsulated in the display engine would not be sufficiently lovable. There might be a market for largely decoupled file and display wrapping, but I don't feel too comfortable about the idea. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel