Subject: Re: bug#71666: 30.0.50; [PATCH] Fix zooming images with SHR

From: Jim Porter <[email-masked]>
Date: Sat, 22 Jun 2024 23:14:16 -0700

On 6/22/2024 9:44 PM, Eli Zaretskii wrote:
> OK, then feel free to install, and thanks.

Thanks. Merged to the master branch as 5f9b5803bea.

I made one small improvement to the code to use overlays for preventing 
image slices from being underlined. That makes the code a bit cleaner, 
and should make future improvements in this area easier.

> I must say this kind of dwim-ish operation that looks like no-op in
> too many "normal" cases looks very strange to me.  How does it make
> sense to have features that only appear to do something in rare cases?
> Doesn't that cause user bewilderment (like I was surprised above), and
> cause users to think we have a bug?  Should we perhaps adjust the
> heuristics and its parameters to make this not no-op in more cases?
> Or at least show a message in echo area explaining why the image was
> not zoomed-in when we decide not to?  For example, in the case above,
> why would it not make sense to enlarge the image when the user presses
> 'z' even if it was not scaled down initially?  Doesn't principle of
> least surprise count anymore?

I agree completely, and I'm working on a patch to that effect. :)

I think the problem you mention is a combination of some bugs I'm 
working on fixing now, and like you say, 'shr-zoom-image' not providing 
enough feedback about what's happening. It just says it's fetching the 
image (this is also probably a bug; why fetch the image from the web 
when we're just resizing it?).

Since I'm most of the way done with this additional patch, I'll leave 
this bug open for now.