bug#20774: auto-fill doesn't work properly when first-line prefix differs in adaptive-fill-mode

[Samuel Freilich]

tab-width = 4 seems consistent with how the rest of the file is formatted. I didn't want to change the spacing in lines not touched by my diff.

I added tests and a change description, and formatted the patch according to the current instructions. I made the patch a bit more minimal. I pruned the part that dealt with adaptive-fill-first-line-regexp didn't work as well as expected, since that didn't work as well as expected (it didn't deal with all the complexity possible with adaptive-fill-function). The updated version at least handles cases where the fill-prefix isn't shorter than the first-line prefix. That allowed me to simplify the code quite a bit, since that makes the previous logic for skipping the exact fill-prefix redundant, fill-move-to-break-point already handles the logic of trying to skip at least one word after the start position passed to it. Please take another look.

You're correct about copyright. I'm doing this for work, copyright is covered by whatever agreements Google has made.

On Tue, Aug 22, 2017 at 11:56 PM, <npostavs@users.sourceforge.net> wrote:

Samuel Freilich <sfreilich@google.com> writes:

> Yes, that's correct. Sorry for getting that wrong in my initial
> description of the bug. That's the same as the indentation behavior
> with auto-fill-mode disabled. A hanging indent is not assumed with
> only one line.

Ah okay.  The patch looks fine (apart from the indentation being off, I
assume because you had tab-width = 4).  Would you mind adding a commit
message?  (See CONTRIBUTE for the format.)

If you're feeling up to it, a test would be nice too.

Since you're sending from a google.com address, I understand the
copyright assignment is covered under Google's blanket agreement, is
that right?

0001-Do-not-split-line-before-length-of-fill-prefix.patch
Description: Text Data