(Hit reply instead of followup; apologies for the duplicate, Stefan) Stefan Monnier writes: >> I think I narrowed it down to this condition in fill-context-prefix: >> >> >> >> In the *scratch* buffer, the condition holds true, so first-line-prefix >> is returned, text properties and all: that's why the first two >> semicolons are fontified. >> >> In a diff buffer, >> >> 1. for removed lines, the condition is false, so we make a new, >> unfontified string, without the diff-removed face, > > We should be able to make this work by trying to preserve > `first-line-prefix`s text properties somehow. I wonder if we shouldn't go the other direction? As in, why should fill-context-prefix bother returning text properties? From a quick glance at other users of this function in the Emacs source tree, AFAICT most of them actually insert (something based on) the return value, so fontification is updated after insertion; these users do not care about the returned text properties. So a conclusion could be that adaptive-wrap-f-c-p should make no assumptions about what text properties f-c-p returns, and determine the face… some other way (see below). > I guess we could try and fix it in `adaptive-wrap-fill-context-prefix` > by trying to preserve any face that covers the whole line (including the > final newline). Mmm… I think that won't DTRT in some cases. In diff buffers, typically: - the first character in a removed line has the diff-indicator-removed face, which some themes[1] might customize to have no background, - the rest of the line has the diff-removed face. > I'm glad I'm not the one who'll write the code ;-) I certainly wouldn't mind anyone beating me to it ;D Here's a proof-of-concept patch (which only handles the positive extra-indent case) and some before/after screenshots. Again, not suggesting to apply this patch as-is; this is just to show in which direction I'm thinking of going: 1. if (substring fcp -1) has text properties, grab that, 2. else grab some text properties from the current line, 3. slap whatever we grabbed on the whole wrap-prefix. Step 2 is not very well-defined yet, even though the "current implementation" works well enough for the sales-pitch screenshots. The rationale behind propertizing the whole prefix in step 3, as mentioned a few paragraphs above, is to stop relying on fill-context-prefix returning text properties.