Subject: bug#58122: 28.2; overlay before/after-string does not render more than one fringe display spec

From: Josh <[email-masked]>
Date: Wed, 28 Sep 2022 18:18:57 -0700

On Wed, Sep 28, 2022, at 6:40 AM, Eli Zaretskii wrote:
> tags 58122 wontfix
> thanks
>
>> Date: Tue, 27 Sep 2022 11:05:10 -0700
>> From: "Josh Caswell" <[email-masked]>
>> 
>> An overlay `before-string' or `after-string' property with both left and right fringe display specs only seems to render the first spec.
>> 
>> *Demonstration*:
>> - Launch GUI Emacs with the -q flag
>> - In an Elisp buffer, define these two commands
>> 
>> (defun insert-two-squares ()
>>   (interactive)
>>   (insert (propertize " " 'display [(left-fringe hollow-square)
>> 				    (right-fringe hollow-square)])))
>> 
>> (defun overlay-two-squares (right-first)
>>   (interactive "P")
>>   (remove-overlays)
>>   (let ((ov (make-overlay (point) (point)))
>> 	(specs [(left-fringe hollow-square)
>> 		 (right-fringe hollow-square)]))
>>     (overlay-put ov 'before-string
>> 		 (propertize " "
>> 			     'display
>> 			     (if right-first
>> 				 (reverse specs)
>> 			       specs)))))
>> 
>> - Switch to a new test buffer
>> - Invoke `insert-two-squares'; observe that both left and right fringes display a hollow square
>> - Delete the inserted character (fringe bitmaps disappear)
>> - Invoke `overlay-two-squares'; observe that only the left fringe displays a hollow square
>> - Invoke `overlay-two-squares' prefixed with `C-u'; observe that only the _right_ fringe displays the hollow square
>> 
>> The same behavior is seen if the overlay property is `after-string' rather than `before-string'.
>> 
>> *Expectation*:
>> Based on the display spec documentation I would expect the overlay to render fringes the same way as an inserted propertized string.
>
> Thank you for your report.
>
> This was never supported in Emacs. The reasons are subtle and very
> technical, and I will not go into them here.  Making this work as
> expected might be possible, but it would require changes on a very low
> level in the code that handles nested display properties and overlay
> strings, which is already extremely complicated.  I find changes of
> such nature unjustified for such a fringe (pun intended) use case.
>
> As an easy work-around, you can have 2 different overlay strings at
> the same position, like this:

Got it. I think this workaround should be sufficient. Thank you for the quick response!