From: npostavs@users.sourceforge.net
To: Samuel Freilich <sfreilich@google.com>, 20774@debbugs.gnu.org
Subject: bug#20774: auto-fill doesn't work properly when first-line prefix differs in adaptive-fill-mode
Date: Mon, 28 Aug 2017 23:37:30 -0400 [thread overview]
Message-ID: <87pobf82o5.fsf@users.sourceforge.net> (raw)
In-Reply-To: <CACQEUgNniBhrw3XtKeVSq2kkfCbkYq+kQSd-ONTG3GxPeh7SVw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 26 bytes --]
[forwarding to bug list]
[-- Attachment #2: Type: message/rfc822, Size: 5302 bytes --]
[-- Attachment #2.1.1.1: Type: text/plain, Size: 517 bytes --]
<npostavs@users.sourceforge.net> wrote:
> Actually, it's now occuring to me that adding a position to a
> string-width isn't quite correct either
Ah right, (point) is in characters, which doesn't correspond directly to
columns at all. I think I can avoid the extra save-excursion and make it a
little cleaner as a result.
> there should be 2 spaces after the period
Heresy! :-P
But done. That does seem to be the most common style in the ChangeLog.
Please take another look. Hopefully this patch can be merged.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1.1.2: 0003-Do-not-split-line-before-width-of-fill-prefix.patch --]
[-- Type: text/x-patch; name=0003-Do-not-split-line-before-width-of-fill-prefix.patch, Size: 3440 bytes --]
From 118c8a43510a7d3020a552ce0e87e5a1b9ccec54 Mon Sep 17 00:00:00 2001
From: Samuel Freilich <sfreilich@google.com>
Date: Wed, 23 Aug 2017 13:40:45 -0400
Subject: [PATCH] Do not split line before width of fill-prefix
When auto-filling a paragraph, don't split a line before the width of the
fill-prefix, creating a subsequent line that is as long or longer (Bug#20774).
* lisp/simple.el (do-auto-fill): Only consider break-points that are later in
the line than the width of the fill-prefix. This is a more general solution
than the previous logic, which only skipped over the exact fill-prefix. The
fill-prefix doesn't necessarily match the prefix of the first line of a
paragraph in adaptive-fill-mode.
---
lisp/simple.el | 27 ++++++++++++---------------
test/lisp/simple-tests.el | 11 +++++++++++
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 13cfa3487d..27990bb661 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -7151,18 +7151,18 @@ do-auto-fill
(setq fill-prefix prefix))))
(while (and (not give-up) (> (current-column) fc))
- ;; Determine where to split the line.
- (let* (after-prefix
- (fill-point
- (save-excursion
- (beginning-of-line)
- (setq after-prefix (point))
- (and fill-prefix
- (looking-at (regexp-quote fill-prefix))
- (setq after-prefix (match-end 0)))
- (move-to-column (1+ fc))
- (fill-move-to-break-point after-prefix)
- (point))))
+ ;; Determine where to split the line.
+ (let ((fill-point
+ (save-excursion
+ (beginning-of-line)
+ ;; Don't split earlier in the line than the length of the
+ ;; fill prefix, since the resulting line would be longer.
+ (when fill-prefix
+ (move-to-column (string-width fill-prefix)))
+ (let ((after-prefix (point)))
+ (move-to-column (1+ fc))
+ (fill-move-to-break-point after-prefix)
+ (point)))))
;; See whether the place we found is any good.
(if (save-excursion
@@ -7170,9 +7170,6 @@ do-auto-fill
(or (bolp)
;; There is no use breaking at end of line.
(save-excursion (skip-chars-forward " ") (eolp))
- ;; It is futile to split at the end of the prefix
- ;; since we would just insert the prefix again.
- (and after-prefix (<= (point) after-prefix))
;; Don't split right after a comment starter
;; since we would just make another comment starter.
(and comment-start-skip
diff --git a/test/lisp/simple-tests.el b/test/lisp/simple-tests.el
index ad7aee1db1..c7330e4034 100644
--- a/test/lisp/simple-tests.el
+++ b/test/lisp/simple-tests.el
@@ -497,5 +497,16 @@ simple-test-undo-with-switched-buffer
(should (equal (line-number-at-pos 5) 3))
(should (equal (line-number-at-pos 7) 4)))))
+(ert-deftest auto-fill-mode-no-break-before-length-of-fill-prefix ()
+ (with-temp-buffer
+ (setq-local fill-prefix " ")
+ (set-fill-column 5)
+ ;; Shouldn't break after 'foo' (3 characters) when the next
+ ;; line is indented >= to that, that woudln't result in shorter
+ ;; lines.
+ (insert "foo bar")
+ (do-auto-fill)
+ (should (string-equal (buffer-string) "foo bar"))))
+
(provide 'simple-test)
;;; simple-test.el ends here
--
2.14.1.342.g6490525c54-goog
next prev parent reply other threads:[~2017-08-29 3:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 23:39 bug#20774: auto-fill doesn't work properly when first-line prefix differs in adaptive-fill-mode Samuel Freilich
2015-06-26 23:40 ` bug#20774: Typo in Patch Samuel Freilich
2017-08-22 12:49 ` bug#20774: auto-fill doesn't work properly when first-line prefix differs in adaptive-fill-mode npostavs
2017-08-22 16:00 ` Samuel Freilich
2017-08-23 3:56 ` npostavs
2017-08-23 18:20 ` Samuel Freilich
2017-08-24 2:16 ` npostavs
2017-08-24 15:11 ` Samuel Freilich
2017-08-25 1:45 ` npostavs
2017-08-29 3:37 ` npostavs [this message]
2017-08-29 3:55 ` npostavs
2017-08-31 0:51 ` npostavs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pobf82o5.fsf@users.sourceforge.net \
--to=npostavs@users.sourceforge.net \
--cc=20774@debbugs.gnu.org \
--cc=sfreilich@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).