GNU bug report logs -
#999
23.0.60; left/right-margin property is not honored on word-wrapped lines
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 999 in the body.
You can then email your comments to 999 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#999
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
When a line is wrapped the `left-margin' text property is honored only
on the first visual line. This seems ok to me unless word-wrap is true.
In that case I think that `left-margin' and `right-margin' should be
honored on all visual lines.
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
of 2008-09-18
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#999
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #10 received at 999 <at> emacsbugs.donarmstrong.com (full text, mbox):
> When a line is wrapped the `left-margin' text property is honored only
> on the first visual line. This seems ok to me unless word-wrap is
> true. In that case I think that `left-margin' and `right-margin'
> should be honored on all visual lines.
A word-wrapped line is essentially the same as a continued line; it's
just that the line is continued at a word boundary rather than a window
edge. In terms of the buffer contents, it's all one long line, so
there's no reason for margin properties to have any effect on the
subsequent *screen* lines in the wrapped line.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#999
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #15 received at 999 <at> emacsbugs.donarmstrong.com (full text, mbox):
Chong Yidong wrote:
>> When a line is wrapped the `left-margin' text property is honored only
>> on the first visual line. This seems ok to me unless word-wrap is
>> true. In that case I think that `left-margin' and `right-margin'
>> should be honored on all visual lines.
>
> A word-wrapped line is essentially the same as a continued line; it's
> just that the line is continued at a word boundary rather than a window
> edge. In terms of the buffer contents, it's all one long line, so
> there's no reason for margin properties to have any effect on the
> subsequent *screen* lines in the wrapped line.
But the reason for wrapping at words is to enhance readability for the
user. For precisely this reason I think that the left margin property
should be used indent the wrapped line too.
After all that is how fill-paragraph works. I think we should think the
same about wrapped lines.
Reply sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
You have taken responsibility.
Full text and
rfc822 format available.
Notification sent to
"Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com>
:
bug acknowledged by developer.
Full text and
rfc822 format available.
Message #20 received at 999-done <at> emacsbugs.donarmstrong.com (full text, mbox):
"Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com> writes:
> But the reason for wrapping at words is to enhance readability for the
> user. For precisely this reason I think that the left margin property
> should be used indent the wrapped line too.
>
> After all that is how fill-paragraph works. I think we should think the
> same about wrapped lines.
The variable wrap-prefix can be used for this.
It would not be consistent to make the left/right margin affect
continued lines.
Message #21 received at 999-done <at> emacsbugs.donarmstrong.com (full text, mbox):
Chong Yidong wrote:
> "Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com> writes:
>
>> But the reason for wrapping at words is to enhance readability for the
>> user. For precisely this reason I think that the left margin property
>> should be used indent the wrapped line too.
>>
>> After all that is how fill-paragraph works. I think we should think the
>> same about wrapped lines.
>
> The variable wrap-prefix can be used for this.
>
> It would not be consistent to make the left/right margin affect
> continued lines.
That is no good replacement. It does not solve the problem at the user
level.
You are in effect saying that this should not work as fill paragraph.
Can you please give the reason for this. And please reopen this bug!
Message #22 received at 999-done <at> emacsbugs.donarmstrong.com (full text, mbox):
"Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com> writes:
>> The variable wrap-prefix can be used for this.
>
> That is no good replacement. It does not solve the problem at the user
> level.
>
> You are in effect saying that this should not work as fill paragraph.
> Can you please give the reason for this.
The situation is not at all similar. Fill paragraph inserts real
whitespace in front of the filled line; you can undo this by using the
usual deletion commands. If word wrap were to make continued lines
begin anywhere other than the left window edge, that would be "fake"
whitespace that cannot be removed by the user. That's not acceptable
behavior.
Message #23 received at 999-done <at> emacsbugs.donarmstrong.com (full text, mbox):
Chong Yidong wrote:
> "Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com> writes:
>
>>> The variable wrap-prefix can be used for this.
>> That is no good replacement. It does not solve the problem at the user
>> level.
>>
>> You are in effect saying that this should not work as fill paragraph.
>> Can you please give the reason for this.
>
> The situation is not at all similar. Fill paragraph inserts real
> whitespace in front of the filled line; you can undo this by using the
> usual deletion commands. If word wrap were to make continued lines
> begin anywhere other than the left window edge, that would be "fake"
> whitespace that cannot be removed by the user. That's not acceptable
> behavior.
We are talking about the visual representation. Are you saying that the
user will be fooled by the "faked" whitespace?
I do not think that will be the case here. Or, not more than the "faked"
new lines.
I just think that a visual representation where the continuation lines
are (visually aka faked) indented as the first line is a more useful
visual representation. We have already made that conclusion in fill
paragraph.
Typical use cases I can see is for example in org-mode or when editing
text parts of XHTML files.
Message #24 received at 999-done <at> emacsbugs.donarmstrong.com (full text, mbox):
"Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com> writes:
> We are talking about the visual representation. Are you saying that the
> user will be fooled by the "faked" whitespace?
>
> I do not think that will be the case here. Or, not more than the "faked"
> new lines.
Plenty of computer programs "fake" whitespace at the end of the line,
but none fake it at the beginning. Users will be fooled for this
reason.
> I just think that a visual representation where the continuation lines
> are (visually aka faked) indented as the first line is a more useful
> visual representation. We have already made that conclusion in fill
> paragraph.
>
> Typical use cases I can see is for example in org-mode or when editing
> text parts of XHTML files.
This can be left to the discretion of individual major modes, by setting
wrap-prefix or some other method. I don't think it's desireable to do
it in general, and left-margin/right-margin is almost certainly the
wrong variable for this.
Message #25 received at 999-done <at> emacsbugs.donarmstrong.com (full text, mbox):
Chong Yidong wrote:
> "Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com> writes:
>
>> We are talking about the visual representation. Are you saying that the
>> user will be fooled by the "faked" whitespace?
>>
>> I do not think that will be the case here. Or, not more than the "faked"
>> new lines.
>
> Plenty of computer programs "fake" whitespace at the end of the line,
> but none fake it at the beginning. Users will be fooled for this
> reason.
I think that depends on the type of program. Applications for writing
text (like Word or OpenOffice) have concepts like indenting of
paragraphs. It is something like that I want to achieve here.
>> I just think that a visual representation where the continuation lines
>> are (visually aka faked) indented as the first line is a more useful
>> visual representation. We have already made that conclusion in fill
>> paragraph.
>>
>> Typical use cases I can see is for example in org-mode or when editing
>> text parts of XHTML files.
>
> This can be left to the discretion of individual major modes, by setting
> wrap-prefix or some other method. I don't think it's desireable to do
> it in general, and left-margin/right-margin is almost certainly the
> wrong variable for this.
Yes, left-margin/right-margin might be a bad and clumsy idea. Using the
actual indentation seems more easy.
I tried to implement something like I suggested here in elisp instead.
It seems usable (to my surprise, I thought it would be too slow). Note
that the mumamo-* macro below is just a copy from jit-lock (if I
remember correctly).
When indenting a line the continuation lines will get the same visual
indentation.
;; Fix-me: There is a confusion between buffer and window margins
;; here. Also the doc says that left-margin-width and dito right may
;; be nil. However they seem to be 0 by default, but when displaying a
;; buffer in a window then window-margins returns (nil).
(defun wrap-to-fill-set-values ()
"Use `fill-column' display columns in buffer windows."
(let ((buf-windows (get-buffer-window-list (current-buffer))))
(dolist (win buf-windows)
(if wrap-to-fill-mode
(let* ((edges (window-edges win))
(win-width (- (nth 2 edges) (nth 0 edges)))
(extra-width (- win-width fill-column))
(left-marg (if wrap-to-fill-left-marg-use
wrap-to-fill-left-marg-use
(- (/ extra-width 2) 1)))
(right-marg (- win-width fill-column left-marg))
(win-margs (window-margins win))
(old-left (or (car win-margs) 0))
(old-right (or (cdr win-margs) 0)))
(unless (> left-marg 0) (setq left-marg 0))
(unless (> right-marg 0) (setq right-marg 0))
(unless (and (= old-left left-marg)
(= old-right right-marg))
(set-window-margins win left-marg right-marg)))
(set-window-buffer win (current-buffer))))))
(defcustom wrap-to-fill-left-marg nil
"Left margin handling for `wrap-to-fill-mode'.
Used by `wrap-to-fill-mode'. If nil then center the display
columns. Otherwise it should be a number which will be the left
margin."
:type '(choice (const :tag "Center" nil)
(integer :tag "Left margin"))
:group 'convenience)
(make-variable-buffer-local 'wrap-to-fill-left-marg)
(defvar wrap-to-fill-left-marg-use 0)
(make-variable-buffer-local 'wrap-to-fill-left-marg-use)
(defcustom wrap-to-fill-left-marg-modes
'(text-mode
fundamental-mode)
"Major modes where `wrap-to-fill-left-margin' may be nil."
:type '(repeat commandp)
:group 'convenience)
(defun wrap-to-fill-set-prefix (min max)
"Set `wrap-prefix' text property from point MIN to MAX."
(let ((here (point))
beg-pos
end-pos
ind-str
(inhibit-field-text-motion t)
)
(goto-char min)
(forward-line 0)
(when (< (point) min) (forward-line))
(mumamo-with-buffer-prepared-for-jit-lock
(while (and (<= (point) max)
(< (point) (point-max)))
(setq beg-pos (point))
(setq end-pos (line-end-position))
(when (equal (get-text-property beg-pos 'wrap-prefix)
(get-text-property beg-pos 'wrap-to-fill-prefix))
(skip-chars-forward "[:blank:]")
(setq ind-str (buffer-substring-no-properties beg-pos (point)))
(put-text-property beg-pos end-pos 'wrap-prefix ind-str)
(put-text-property beg-pos end-pos 'wrap-to-fill-prefix ind-str))
(forward-line)))
(goto-char here)))
(defun wrap-to-fill-after-change (min max old-len)
"For `after-change-functions'.
See the hook for MIN, MAX and OLD-LEN."
(let ((here (point))
(inhibit-field-text-motion t))
(goto-char min)
(setq min (line-beginning-position))
(goto-char max)
(setq max (line-end-position))
(wrap-to-fill-set-prefix min max)))
(defun wrap-to-fill-scroll-fun (window start-pos)
"For `window-scroll-functions'.
See the hook for WINDOW and START-POS."
(let ((min (or start-pos (window-start window)))
(max (window-end window t)))
(wrap-to-fill-set-prefix min max)))
(define-minor-mode wrap-to-fill-mode
"Use `fill-column' display columns in buffer windows.
By default the display columns are centered, but see the option
`wrap-to-fill-left-marg'.
Note 1: When turning this on `visual-line-mode' is also turned on. This
is not reset when turning off this mode.
Note 2: The text property `wrap-prefix' is set by this mode to
indent continuation lines. This is not recorded in the undo
list."
:lighter " WrapFill"
:group 'convenience
(if wrap-to-fill-mode
(progn
(setq wrap-to-fill-left-marg-use wrap-to-fill-left-marg)
(unless (or wrap-to-fill-left-marg-use
(memq major-mode wrap-to-fill-left-marg-modes))
(setq wrap-to-fill-left-marg-use
(default-value 'wrap-to-fill-left-marg-use)))
(add-hook 'window-configuration-change-hook
'wrap-to-fill-set-values nil t)
(add-hook 'after-change-functions 'wrap-to-fill-after-change nil t)
(add-hook 'window-scroll-functions 'wrap-to-fill-scroll-fun nil t)
(visual-line-mode 1)
(dolist (window (get-buffer-window-list (current-buffer)))
(wrap-to-fill-scroll-fun window nil)))
(remove-hook 'window-configuration-change-hook
'wrap-to-fill-set-values t)
(remove-hook 'after-change-functions 'wrap-to-fill-after-change t)
(remove-hook 'window-scroll-functions 'wrap-to-fill-scroll-fun t)
(let ((here (point))
(inhibit-field-text-motion t)
beg-pos
end-pos)
(mumamo-with-buffer-prepared-for-jit-lock
(save-restriction
(widen)
(goto-char (point-min))
(while (< (point) (point-max))
(setq beg-pos (point))
(setq end-pos (line-end-position))
(when (equal (get-text-property beg-pos 'wrap-prefix)
(get-text-property beg-pos 'wrap-to-fill-prefix))
(remove-list-of-text-properties
beg-pos end-pos
'(wrap-prefix)))
(forward-line))
(remove-list-of-text-properties
(point-min) (point-max)
'(wrap-to-fill-prefix)))
(goto-char here))))
(wrap-to-fill-set-values))
bug archived.
Request was from
Debbugs Internal Request <don <at> donarmstrong.com>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Sun, 19 Oct 2008 14:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 years and 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.