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

[Josh]

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" <emacs@woolsweater.net>
>> 
>> 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!