[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: line/wrap-prefix patch
From: |
Miles Bader |
Subject: |
Re: line/wrap-prefix patch |
Date: |
Sat, 05 Jul 2008 09:52:17 +0900 |
Stephen Berman <address@hidden> writes:
>> To get varying prefixes, you can use the `wrap-prefix' text property.
>
> Yes, I see this when I evaluate e.g. (put-text-property (point) (1+
> (point)) 'wrap-prefix " ") with the cursor on the first character of
> a wrapped word. Is this the right way to use this text property?
You can put the property over the entire region of text that the
wrap-prefix applies to; there's no need to know which words will
actually get wrapped.
>> To do so automatically and dynamically would be interesting, but is
>> obviously more work.
>
> If my usage above is correct, I think this approach would effectively
> need to be augmented by something like longlines.el
No.
>> I wonder what ways of specifying the prefix would
>> be practical (e.g., a text-property covering the "header" text at the
>> beginning of the physical line, which would be replaced by spaces to get
>> the wrap prefix, or a regexp used to match the header)?
>
> I don't see how any "static" text property assignment will insure the
> right indentation when the preceding text changes and forces new word
> wrapping.
The "right" indendation depends only on the text following the
preceding _hard_ line-start, i.e, the preceding "non-wrap prefix".
E.g., if you have the following long line:
- This is a long-line-aka-paragraph blah blah blah blah blah blah blah
and you want to have it wrapped (at display-time) like:
- This is a long-line-aka-paragraph blah
blah blah blah blah blah blah
The tricky part is getting the wrap-prefix " " by examining the
current non-wrap prefix, " - " in this case. Currently there's no
way of having the display engine do it, so one could alternatively have
a font-lock-like mechanism that turned hard paragraph prefixes into
wrap-prefix text properties. One could also try to come up with a
mechanism to have the display engine do it dynamically (as I talked
about a bit in my previous message).
> *********
> I was really hoping you would respond to the display problem at
> window-start. I find it very dissatisfying to regard this as a
> "misfeature" of Emacs redisplay and leave it that, as RMS seemed to
> conclude was the only course to take.
I haven't been able the reproduce it so far, so I need to try to do so
more thoroughly. I'll try to do so this weekend.
-Miles
--
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.