[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
