With #2014 (and a hotfix to that, #2066), we have the replaced text in bold after using s/find/replace/ 🥳 …unless the replacement is already inside a bolded substring, including if the replacement ran against an already-edited line.
A riff on the "not your buddy, guy" meme using find today showed that, if one does s/replace/again/, the replaced output of again won't appear bold (but it will waste 4 bytes with two ^B control characters on either side of the replaced text).
My first instinct is to just skip formatting the replacement at all if the line contains any formatting control codes. That's likely the simplest approach; anything more (e.g. determining whether the specific substring being replaced is inside a formatted range) gets into fairly complicated string analysis with diminishing returns.
Maybe no one will even want to think about this until find is extracted from core into its own plugin package, but for now this is the only reasonably relevant issue tracker for such an idea.
With #2014 (and a hotfix to that, #2066), we have the replaced text in bold after using
s/find/replace/
🥳 …unless the replacement is already inside a bolded substring, including if the replacement ran against an already-edited line.A riff on the "not your buddy, guy" meme using
find
today showed that, if one doess/replace/again/
, the replaced output ofagain
won't appear bold (but it will waste 4 bytes with two^B
control characters on either side of the replaced text).My first instinct is to just skip formatting the replacement at all if the line contains any formatting control codes. That's likely the simplest approach; anything more (e.g. determining whether the specific substring being replaced is inside a formatted range) gets into fairly complicated string analysis with diminishing returns.
Maybe no one will even want to think about this until
find
is extracted from core into its own plugin package, but for now this is the only reasonably relevant issue tracker for such an idea.