magit-blame headers inherit stipple face with starting-column = 0.

[aburlot]

When I turn magit-blame on, I have some issue reading it:

Looks like some bars are introduced on every character.

[jdtsmith]

Hmm, I don't see this:

[jdtsmith]

Can you see if M-x indent-bars-reset helps?

[jdtsmith]

Otherwise, go to a line just after one of the headers, and M-: (overlay-get (car (last (overlays-at (point)))) 'before-string) and report what you get.

[aburlot]

Unfortunately, indent-bars-reset changes nothing. The command gives me this :

#("My name          2024-09-26 15:33 commentary and cleaning
" 0 20 (font-lock-face (magit-blame-name magit-blame-heading)) 20 21 (font-lock-face magit-blame-heading) 21 37 (font-lock-face (magit-blame-date magit-blame-heading)) 37 38 (font-lock-face magit-blame-heading) 38 61 (font-lock-face (magit-blame-summary magit-blame-heading)) 61 62 (font-lock-face magit-blame-heading))

Strangely, in Python, I have a mixed effect:

In C++, I notice that it starts to be messy when I am in a function, thus when the indent-bars start appearing:

But a few commits appear normally even inside the function. I tried the command on several lines, but they always show the same resultats as above.

I hope this helps!

[jdtsmith]

Do you have indent-bars-starting-column = 0. Always important to mention any non-default settings.

[shipmints]

It's nil. My config is super basic:

  (setopt indent-bars-prefer-character t)
  (setopt indent-bars-no-stipple-char ?│)
  (setopt indent-bars-depth-update-delay 0.3) ; default 0.075
  (setopt indent-bars-color-by-depth nil)
  (setopt indent-bars-color '(highlight :face-bg t :blend 0.325)) ; default '(highlight :face-bg t :blend 0.325)
  (setopt indent-bars-treesit-support t)
  (require 'indent-bars-ts)
  (setopt indent-bars-treesit-update-delay 0.3) ; default 0.125
  (setopt indent-bars-treesit-ignore-blank-lines-types '("module"))

[jdtsmith]

I meant this for @aburlot. I suspect they do. If so, this looks to me like a bug in magit-blame. It sets the font-lock-face on an overlay :before-string property, which is fine. But it should also set face=nil on that string. The reason why is that if there is any face on the first character in a line, the before-string overlay also inherits that face. Usually there is either no or simple foreground face on the first column, so the problem isn't noticed. With stipples in column 0, it's easy to notice.

Please open an issue with magit and mention the need for a face=nil property on magit-blame's before-string.

[aburlot]

Do you have indent-bars-starting-column = 0. Always important to mention any non-default settings.

Yes! When set back to nil, magit-blame is normal. Do you confirm that I should open an issue with magit?

[jdtsmith]

Yes, please do and link here. Magit should not inherit the face property of the first character on a line into its blame overlay :before-string, since it doesn't control what that is or will be (and face overrides font-lock-face).

[tarsius]

Magit should not inherit the face property of the first character on a line into its blame overlay :before-string

I cannot spot how Magit does that. It appears you do. If so, please tell me.

I did this

(defun magit-blame--update-heading-overlay (ov)
  (overlay-put
   ov 'before-string (propertize "fake heading\n" 'face nil)))

and the lines where still there.

[jdtsmith]

Oh right, a nil-face does not reset face attributes, but is instead ignored. Even switching magit's before-string property from font-lock-face to face doesn't work as you'd hope, since the overlay still inherits any unspecified attributes from the underlying text:

If the text comes from an overlay string via ‘before-string’ or
‘after-string’ properties (*note Overlay Properties::), or from a
display string (*note Other Display Specs::), and the string
doesn't contain a ‘face’ or ‘mouse-face’ property, or these
properties leave some face attributes undefined, but the buffer
text affected by the overlay/display property does define a face or
those attributes, Emacs applies the face attributes of the
"underlying" buffer text. Note that this is so even if the overlay
or display string is displayed in the display margins (*note
Display Margins::).

The best approach might be just to add default at the end of the list, so as to explicitly reset all other unmentioned attributes:

(let ((ov (make-overlay (point) (point)))
      (d (propertize "fake heading\n"
		     'font-lock-face
		     '((:foreground "red" :background "black") default))))
  (overlay-put ov 'before-string d))

This would also reset other attributes like :height that might vary in the buffer as well. Note that, oddly, font-lock-face does in fact override face specifically in this "overlay before-string inheriting underlying face" context.

[jdtsmith]

Fixed in magit.

[tarsius]

Thanks for your help!

[jdtsmith]

Thanks for the fix (and magit, used daily)!

[tarsius]

I hesitated to end the list of faces with default, but in the end I concluded that was indeed the cleanest approach, not least because that way not every theme has to be updated individually.

[jdtsmith]

I agree, it seems like there should be a better way to "negatively override" face, but IME the attribute selection system is purely additive. There is a special reset attribute property, but then you have to enumerate all of them (including future attributes that don't exist yet!).