No hat spacing on continuation or truncated lines

[mdbridge]

The space between the characters and their hats get smaller on continuation lines, which I believe will cause them to overlap the characters.

This is most obvious on high DPI with my high DPI fix:

without the fix, the hats are too small but you can still see the distance changing:

(compare the hat spacing of the leftmost '('s)

[mdbridge]

Maybe I'm missing some subtle corner case, but simply commenting out the following line seems to fix things:

mdl@foil [11]$ svn diff
Index: hatty.el
===================================================================
--- hatty.el    (revision 3315)
+++ hatty.el    (working copy)
@@ -595,7 +595,7 @@
             (cond
              ;; Lines that are wrapped do not profit of the additional
              ;; line height of the final newline
-             ((not (hatty--hat-on-final-visual-line hat)) default-char-height)
+             ;; ((not (hatty--hat-on-final-visual-line hat)) default-char-height)
              ((integerp line-height) (max default-char-height line-height))
              ((floatp line-height) (* default-char-height line-height))
              (t default-char-height)))

[ErikPrantare]

This is a problem of Emacs line-height rendering. When deciding the height of a line, Emacs checks the line-height text property of the newline character of the same /rendered/ line. This means that on continuation and truncated lines, the line-height property is not applied, as there is no newline character on that rendered line. The reason for smushing the hats instead of giving them the full space is that this may cause jittering on hat reallocation. You can check it for yourself with your edit: Try scrolling up and down with continuation lines present. This jittering in turn may put point outside the visible portion of the buffer, triggering Emacs to scroll a large portion.

…

On Mon, Apr 20, 2026, 00:18 Mark ***@***.***> wrote: *mdbridge* left a comment (ErikPrantare/hatty.el#5) <#5 (comment)> Maybe I'm missing some subtle corner case, but simply commenting out the following line seems to fix things: ***@***.*** [11]$ svn diff Index: hatty.el =================================================================== --- hatty.el (revision 3315) +++ hatty.el (working copy) @@ -595,7 +595,7 @@ (cond ;; Lines that are wrapped do not profit of the additional ;; line height of the final newline - ((not (hatty--hat-on-final-visual-line hat)) default-char-height) + ;; ((not (hatty--hat-on-final-visual-line hat)) default-char-height) ((integerp line-height) (max default-char-height line-height)) ((floatp line-height) (* default-char-height line-height)) (t default-char-height))) — Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=AF3JD4BKXSNENSF7G76V2AT4WVGD3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGY4TIMBVGAZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4276940503>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF3JD4ECCYMZVR5KVFWM7ND4WVGD3AVCNFSM6AAAAACX62Z5M6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZWHE2DANJQGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mdbridge]

it took a lot of experimentation, but I believe I have a solution for this problem; TLDR: use {line,wrap}-prefix instead of line-height

[mdbridge]

Here are the changes I made to the version I downloaded both for high DPI and for handling the continuation lines correctly.

Mark@mdl [15]# diff hatty.orig.el hatty.el |& more
138a139,146
> (defcustom hatty-hat-height-ratio 0.3
>   "Hat height as a fraction of character height.
>
> Also determines the extra line-height reserved above each line
> for hats to occupy."
>   :type 'number
>   :group 'hatty)
>
588,590d595
<              ;; Lines that are wrapped do not profit of the additional
<              ;; line height of the final newline
<              ((not (hatty--hat-on-final-visual-line hat)) default-char-height)
611a617
>        :char-height char-height
625a632
>          (char-height (plist-get parameters :char-height))
647c654
<                                  (/ (face-attribute 'default :height) 100.0)
---
>                                  (/ (* char-height hatty-hat-height-ratio) 9.0)
686,687c693,710
<   (let ((modify-line-height (make-overlay (point-min) (point-max) nil nil t)))
<     (overlay-put modify-line-height 'line-height  1.2)
---
>   (let* ((font (if (< (point-min) (point-max))
>                    (font-at (point-min))
>                  (face-attribute 'default :font)))
>          (font-metrics (query-font font))
>          (ascent (elt font-metrics 4))
>          (descent (elt font-metrics 5))
>          (char-height (+ ascent descent))
>          (target-height (ceiling (* char-height
>                                     (+ 1.0 hatty-hat-height-ratio 0.05))))
>          (svg-ascent-pct (ceiling (* 100 (- target-height descent))
>                                   target-height))
>          (prefix-image (svg-image (svg-create 1 target-height)
>                                   :ascent svg-ascent-pct
>                                   :scale 1.0))
>          (modify-line-height (make-overlay (point-min) (point-max) nil nil t)))
>     (overlay-put modify-line-height 'line-height target-height)
>     (overlay-put modify-line-height 'line-prefix prefix-image)
>     (overlay-put modify-line-height 'wrap-prefix prefix-image)

[mdbridge]

probably needs some more polishing and obviously merging with your changes.

in essence, we are adding a one pixel-wide SVG to beginning of each visual line (including the continuation lines and the normal lines). This SVG is high enough to ensure that there is adequate spacing between the visual lines.

This makes doing a page up when there are continuation lines not because recentering.

I tried turning on truncation it didn't see any obvious issues.

let me know if there's something else you like me to try in the way of testing

[mdbridge]

truncation seems to work as far as I can tell

[mdbridge]

hmmm. if I increase the buffer font size a few times, I am not getting jitter but if I decrease it a couple times I do. Probably another off by one bug :-(

[mdbridge]

( commented elsewhere, but this is still present on master release 2.0.0)

[ErikPrantare]

Very clever, I will try this out for a while to see if there are any unintended consequences. Thank you, this has been bugging me.

[ErikPrantare]

Some initial comments

• The approach of having the image prefixes seems more robust. It automatically handles the case where the last line has no newline.
• There needs to be an additional check (get-buffer-window (current-buffer)) before trying font-at (otherwise Emacs will error when the given buffer is not visible)
• If you create a PR, feel free to remove the space-deprivation computation functions. They should be superfluous now.
• 'line-height should not be needed after this, right? And the svg height computation can just use the same value computed in target-height.
• svg-ascent-pct: Where possible, avoid abbreviations; Full words are easier to utter.

[ErikPrantare]

Another thing I found:

dashboard.el makes use of these prefixes to center the splash screen.
This approach overrides this, causing it to not be centered anymore.
Perhaps we want to fall back on the line-height method if the buffer
contains {line,wrap}-prefix properties. Or, we accept in those cases
that hats will be smushed (or accept jitter). We'd have to consider
how often the situation occurs. The space deprivation calculation is
quite chunky and it would be nice to remove.

I should fix the current tests so they run properly again. Then we
could set up some more tests for expected rendering behaviour.

[ErikPrantare]

I have pushed changes to develop fixing the test suite. It should help with iteration, it tries to capture some invariants.

[mdbridge]

ARGH. it looks like my approach breaks visual-line-mode with adaptive-wrap-prefix-mode and visual-fill-column-mode, which is my main use case :-(

I will have to investigate more when I get a chance

[mdbridge]

I think I can fix this with some advice