bug#38187: 27.0.50; No mouse-wheel scaling on images

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

Tried to use a new recently added useful feature of using C-mouse-wheel to zoom.

But it seems it has no effect on images, at least its effect is not visible:
it doesn't scale images in image mode.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 12 Nov 2019 22:38:12 +0200
> 
> Tried to use a new recently added useful feature of using C-mouse-wheel to zoom.
> 
> But it seems it has no effect on images, at least its effect is not visible:
> it doesn't scale images in image mode.

  <C-wheel-up> at that spot runs the command mouse-wheel-text-scale
  (found in global-map), which is an interactive compiled Lisp function
  in ‘mwheel.el’.

  It is bound to <C-wheel-down>, <C-wheel-up>.

  (mouse-wheel-text-scale EVENT)

  Increase or decrease the height of the default face according to the EVENT.

It is documented to increase/decrease the size of _text_ of the
default face.  It isn't documented to "zoom", which is a much more
general action/effect.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It is documented to increase/decrease the size of _text_ of the
> default face.  It isn't documented to "zoom", which is a much more
> general action/effect.

But I think it would make sense to bind that event to zoom the image if
over an image.  It's a trivial change and seems natural.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  38187@debbugs.gnu.org
> Date: Sun, 17 Nov 2019 11:04:59 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is documented to increase/decrease the size of _text_ of the
> > default face.  It isn't documented to "zoom", which is a much more
> > general action/effect.
> 
> But I think it would make sense to bind that event to zoom the image if
> over an image.  It's a trivial change and seems natural.

AFAIU, that's not what the OP wanted.  He wanted to see _all_ images
be scaled proportionally to the text scaling, regardless of where the
mouse pointer is located.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, that's not what the OP wanted.  He wanted to see _all_ images
> be scaled proportionally to the text scaling, regardless of where the
> mouse pointer is located.

Ah; yes, I agree that that would be confusing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> AFAIU, that's not what the OP wanted.  He wanted to see _all_ images
>> be scaled proportionally to the text scaling, regardless of where the
>> mouse pointer is located.
>
> Ah; yes, I agree that that would be confusing.

FWIW, I think the opposite.  I think that zooming text, images and all
buffer content together should be the default.  I believe that it
would feel both natural and familiar, especially to new users, since
that's how e.g. web browsers, LibreOffice and evince, etc. works.

And if we do that, why then not call this functionality "zooming"?
That nomenclature is fairly well-established and therefore easier to
understand for new users, I think.

Of course, if we don't do such a change, it makes no sense to
introduce the word "zooming".  Then "change font size" or "change
image size" is a better description of what is going on.

(That also reminds me that, IMO, text-scale-increase/decrease should
be renamed to font-size-increase/decrease.  The current names are not
very discoverable; when one wants to change the font size, and says:
`M-x font TAB'.  At the very least, we should have such defaliases.)

Best regards,
Stefan Kangas

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

>>> AFAIU, that's not what the OP wanted.  He wanted to see _all_ images
>>> be scaled proportionally to the text scaling, regardless of where the
>>> mouse pointer is located.
>>
>> Ah; yes, I agree that that would be confusing.
>
> FWIW, I think the opposite.  I think that zooming text, images and all
> buffer content together should be the default.  I believe that it
> would feel both natural and familiar, especially to new users, since
> that's how e.g. web browsers, LibreOffice and evince, etc. works.

Zooming text and images together would be nice too, but I meant
something much simpler - zooming images in image-mode with mouse-wheel.

In image-mode currently ‘+’ is bound to the command ‘image-increase-size’,
the same command could be bound to ‘<C-mouse-4>’ (C-wheel-up) as well.
Same for ‘-’ (image-decrease-size) and ‘<C-mouse-5>’ (C-wheel-down).

> (That also reminds me that, IMO, text-scale-increase/decrease should
> be renamed to font-size-increase/decrease.  The current names are not
> very discoverable; when one wants to change the font size, and says:
> `M-x font TAB'.  At the very least, we should have such defaliases.)

Maybe, “text-zoom” is more discoverable?

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Zooming text and images together would be nice too, but I meant
> something much simpler - zooming images in image-mode with mouse-wheel.
>
> In image-mode currently ‘+’ is bound to the command ‘image-increase-size’,
> the same command could be bound to ‘<C-mouse-4>’ (C-wheel-up) as well.
> Same for ‘-’ (image-decrease-size) and ‘<C-mouse-5>’ (C-wheel-down).

Right.  I think that's an obvious thing to put in `image-map' to make it
easier to change the size of a single image.

(It's not just in image-mode -- that map is on all images inserted by
`insert-image'.)

I don't have a mouse myself, so it'd be nice if somebody with one
created a patch so that they could test it.  image-map is in image.el.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

>> In image-mode currently ‘+’ is bound to the command ‘image-increase-size’,
>> the same command could be bound to ‘<C-mouse-4>’ (C-wheel-up) as well.
>> Same for ‘-’ (image-decrease-size) and ‘<C-mouse-5>’ (C-wheel-down).
>
> Right.  I think that's an obvious thing to put in `image-map' to make it
> easier to change the size of a single image.
>
> (It's not just in image-mode -- that map is on all images inserted by
> `insert-image'.)
>
> I don't have a mouse myself, so it'd be nice if somebody with one
> created a patch so that they could test it.  image-map is in image.el.

I tested this patch, and it works well:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mouse-wheel-image-size.patch --]
[-- Type: text/x-diff, Size: 2170 bytes --]

diff --git a/lisp/image.el b/lisp/image.el
index ad2ee6c607..8e8e477865 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -158,6 +158,10 @@ image-map
   (let ((map (make-sparse-keymap)))
     (define-key map "-" 'image-decrease-size)
     (define-key map "+" 'image-increase-size)
+    (define-key map [C-wheel-down] 'image-decrease-size)
+    (define-key map [C-mouse-5]    'image-decrease-size)
+    (define-key map [C-wheel-up]   'image-increase-size)
+    (define-key map [C-mouse-4]    'image-increase-size)
     (define-key map "r" 'image-rotate)
     (define-key map "o" 'image-save)
     map))
@@ -993,23 +997,33 @@ imagemagick-enabled-types
 
 (imagemagick-register-types)
 
-(defun image-increase-size (n)
+(defun image-increase-size (&optional n event)
   "Increase the image size by a factor of N.
 If N is 3, then the image size will be increased by 30%.  The
 default is 20%."
-  (interactive "P")
-  (image--change-size (if n
-                          (1+ (/ n 10.0))
-                        1.2)))
+  (interactive (list current-prefix-arg last-nonmenu-event))
+  (let ((e (and (listp event) (event-start event))))
+    (save-window-excursion
+      (when e
+        (select-window (posn-window e))
+        (goto-char (posn-point e)))
+      (image--change-size (if n
+                              (1+ (/ (prefix-numeric-value n) 10.0))
+                            1.2)))))
 
-(defun image-decrease-size (n)
+(defun image-decrease-size (&optional n event)
   "Decrease the image size by a factor of N.
 If N is 3, then the image size will be decreased by 30%.  The
 default is 20%."
-  (interactive "P")
-  (image--change-size (if n
-                          (- 1 (/ n 10.0))
-                        0.8)))
+  (interactive (list current-prefix-arg last-nonmenu-event))
+  (let ((e (and (listp event) (event-start event))))
+    (save-window-excursion
+      (when e
+        (select-window (posn-window e))
+        (goto-char (posn-point e)))
+      (image--change-size (if n
+                              (- 1 (/ (prefix-numeric-value n) 10.0))
+                            0.8)))))
 
 (defun image--get-image ()
   "Return the image at point."

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Stefan Kangas <stefan@marxist.se>,  Eli Zaretskii <eliz@gnu.org>,
>   38187@debbugs.gnu.org
> Date: Mon, 18 Nov 2019 23:37:15 +0200
> 
> -(defun image-increase-size (n)
> +(defun image-increase-size (&optional n event)

Can we avoid mixing numerical argument with a mouse event?  It looks
unclean to me.  How about a simple wrapper that accepts a mouse event
and calls image-increase/decrease-size with a suitable arg?

Thanks.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

>> -(defun image-increase-size (n)
>> +(defun image-increase-size (&optional n event)
>
> Can we avoid mixing numerical argument with a mouse event?  It looks
> unclean to me.  How about a simple wrapper that accepts a mouse event
> and calls image-increase/decrease-size with a suitable arg?

So I installed a new patch with wrappers.

BTW, while testing it for image scaling on a quite small image file,
Emacs consumed several GB of all available memory and almost all swap,
before I noticed and evaluated M-: (clear-image-cache) that freed memory.

Memory leak?

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  stefan@marxist.se,  38187@debbugs.gnu.org
> Date: Thu, 21 Nov 2019 01:00:53 +0200
> 
> BTW, while testing it for image scaling on a quite small image file,
> Emacs consumed several GB of all available memory and almost all swap,
> before I noticed and evaluated M-: (clear-image-cache) that freed memory.
> 
> Memory leak?

Can you show a recipe for reproducing this and report is as a separate
bug?

Thanks.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Alan Third]

On Thu, Nov 21, 2019 at 01:00:53AM +0200, Juri Linkov wrote:
> >> -(defun image-increase-size (n)
> >> +(defun image-increase-size (&optional n event)
> >
> > Can we avoid mixing numerical argument with a mouse event?  It looks
> > unclean to me.  How about a simple wrapper that accepts a mouse event
> > and calls image-increase/decrease-size with a suitable arg?
> 
> So I installed a new patch with wrappers.
> 
> BTW, while testing it for image scaling on a quite small image file,
> Emacs consumed several GB of all available memory and almost all swap,
> before I noticed and evaluated M-: (clear-image-cache) that freed memory.
> 
> Memory leak?

Was this on X?

Emacs probably keeps a copy of the image in memory for each size until
the image cache is cleared or pruned.

I’m a little unsure exactly how the image cache works because there
appears to be a second level pixmap cache that I think should avoid
that, but I’m not sure.

-- 
Alan Third

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

>> BTW, while testing it for image scaling on a quite small image file,
>> Emacs consumed several GB of all available memory and almost all swap,
>> before I noticed and evaluated M-: (clear-image-cache) that freed memory.
>> 
>> Memory leak?
>
> Was this on X?

Yes, on X.  

> Emacs probably keeps a copy of the image in memory for each size until
> the image cache is cleared or pruned.

Could it clear the image cache automatically when it grows
over some memory limit?

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  stefan@marxist.se,
>   38187@debbugs.gnu.org
> Date: Fri, 22 Nov 2019 00:51:22 +0200
> 
> > Emacs probably keeps a copy of the image in memory for each size until
> > the image cache is cleared or pruned.
> 
> Could it clear the image cache automatically when it grows
> over some memory limit?

How would you do that without knowing what each image is used for and
whether it is still on display?

I don't think we can make the image cache smarter about eviction
without adding more information about each cached image.  So it isn't
just about tuning the current constants or counting the bytes.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> BTW, while testing it for image scaling on a quite small image file,
> Emacs consumed several GB of all available memory and almost all swap,
> before I noticed and evaluated M-: (clear-image-cache) that freed memory.
>
> Memory leak?

No, it's just that Emacs' image cache is very primitive.  You can easily
get Emacs to go out-of-memory by just doing a

(dolist (file (directory-files dir-with-lots-of-images))
  (erase-buffer)
  (insert-image (create-image file)))

You get the same effect by altering the scaling factor, I think?  Each
scaled image is cached?  So by rolling the wheel ten clicks you get ten
cached copies of the image.

A better eviction algorithm would be nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

>> BTW, while testing it for image scaling on a quite small image file,
>> Emacs consumed several GB of all available memory and almost all swap,
>> before I noticed and evaluated M-: (clear-image-cache) that freed memory.
>>
>> Memory leak?
>
> No, it's just that Emacs' image cache is very primitive.  You can easily
> get Emacs to go out-of-memory by just doing a
>
> (dolist (file (directory-files dir-with-lots-of-images))
>   (erase-buffer)
>   (insert-image (create-image file)))
>
> You get the same effect by altering the scaling factor, I think?  Each
> scaled image is cached?  So by rolling the wheel ten clicks you get ten
> cached copies of the image.
>
> A better eviction algorithm would be nice.

Currently the default value of image-cache-eviction-delay is
300 seconds.

But the documentation also says:

  "If the cache contains a large number of images,
   the actual eviction time may be shorter."

And code has this comment:

  /* If the number of cached images has grown unusually large,
     decrease the cache eviction delay (Bug#6230).  */

Does this mean the number of cached images was not large enough?

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>   /* If the number of cached images has grown unusually large,
>      decrease the cache eviction delay (Bug#6230).  */
>
> Does this mean the number of cached images was not large enough?

I've successfully (ahem) made Linux kill Emacs by looping over images
(out of memory killer), so I don't think whatever it does is well-tuned.
I haven't looked at the code now, but doesn't it just count images/time
and not take image size into account?  I may be misremembering.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  38187@debbugs.gnu.org
> Date: Fri, 22 Nov 2019 00:10:48 +0100
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> >   /* If the number of cached images has grown unusually large,
> >      decrease the cache eviction delay (Bug#6230).  */
> >
> > Does this mean the number of cached images was not large enough?
> 
> I've successfully (ahem) made Linux kill Emacs by looping over images
> (out of memory killer), so I don't think whatever it does is well-tuned.
> I haven't looked at the code now, but doesn't it just count images/time
> and not take image size into account?  I may be misremembering.

You are misremembering.  The code counts _redisplay_ cycles, and
clears the image cache when that exceeds 101.  Any additional cache
clearing can only come from Lisp that calls clear-image-cache
explicitly.  What exactly clearing the cache does depends on the value
of image-cache-eviction-delay and on how many images are in the
frame's image cache.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  38187@debbugs.gnu.org
> Date: Fri, 22 Nov 2019 00:57:24 +0200
> 
> Currently the default value of image-cache-eviction-delay is
> 300 seconds.
> 
> But the documentation also says:
> 
>   "If the cache contains a large number of images,
>    the actual eviction time may be shorter."
> 
> And code has this comment:
> 
>   /* If the number of cached images has grown unusually large,
>      decrease the cache eviction delay (Bug#6230).  */
> 
> Does this mean the number of cached images was not large enough?

Maybe.  the only way to answer that is to run the recipe under a
debugger with a breakpoint at that place, and have the breakpoint
print the number of images in the cache.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  38187@debbugs.gnu.org
> Date: Thu, 21 Nov 2019 22:26:30 +0100
> 
> (dolist (file (directory-files dir-with-lots-of-images))
>   (erase-buffer)
>   (insert-image (create-image file)))
> 
> You get the same effect by altering the scaling factor, I think?  Each
> scaled image is cached?  So by rolling the wheel ten clicks you get ten
> cached copies of the image.

Again, does binding redisplay-dont-pause to nil help in any way here?

> A better eviction algorithm would be nice.

Such an algorithm would need to detect these "useless" cached images
to be effective.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Again, does binding redisplay-dont-pause to nil help in any way here?

I haven't tested.

>> A better eviction algorithm would be nice.
>
> Such an algorithm would need to detect these "useless" cached images
> to be effective.

Yup.  If there's no reference to the image, that should be communicated
back to the image cache, which would require some support from the
garbage collection somehow.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Alan Third]

On Thu, Nov 21, 2019 at 10:26:30PM +0100, Lars Ingebrigtsen wrote:
> 
> You get the same effect by altering the scaling factor, I think?  Each
> scaled image is cached?  So by rolling the wheel ten clicks you get ten
> cached copies of the image.
> 
> A better eviction algorithm would be nice.

It would be nice if Emacs was able to reuse the actual image data
where the only difference is scaling or rotation.

A simple ‘solution’ to the mousewheel scaling issue would be to
explicitly flush the old image from the cache on each change. I think
that’s what image mode does when you zoom.
-- 
Alan Third

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> Date: Fri, 22 Nov 2019 09:50:08 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 38187@debbugs.gnu.org, stefan@marxist.se, Juri Linkov <juri@linkov.net>
> 
> It would be nice if Emacs was able to reuse the actual image data
> where the only difference is scaling or rotation.

I think we found that too complicated at the time.

> A simple ‘solution’ to the mousewheel scaling issue would be to
> explicitly flush the old image from the cache on each change. I think
> that’s what image mode does when you zoom.

image-mode can do that when it knows the scaled image will replace the
previous one, yes.  (We will need to add an API for that, I think.)
But that's not cache eviction, that's application being smarter about
the "garbage" it produces.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Alan Third]

On Fri, Nov 22, 2019 at 12:04:49PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 22 Nov 2019 09:50:08 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: 38187@debbugs.gnu.org, stefan@marxist.se, Juri Linkov <juri@linkov.net>
> > 
> > It would be nice if Emacs was able to reuse the actual image data
> > where the only difference is scaling or rotation.
> 
> I think we found that too complicated at the time.

Yes, and I’m not sure the pay‐off would be worth it as it really only
makes a big difference in situations like these where an image is
being scaled repeatedly.

But we can consider it a wishlist item. ;)

> > A simple ‘solution’ to the mousewheel scaling issue would be to
> > explicitly flush the old image from the cache on each change. I think
> > that’s what image mode does when you zoom.
> 
> image-mode can do that when it knows the scaled image will replace the
> previous one, yes.  (We will need to add an API for that, I think.)
> But that's not cache eviction, that's application being smarter about
> the "garbage" it produces.

Actually, now I look at the code, when an image is resized using the
mousewheel the previous image should already be flushed.

In image.el we have this function:

(defun image--get-imagemagick-and-warn ()
  (unless (or (fboundp 'imagemagick-types) (image-transforms-p))
    (error "Cannot rescale images on this terminal"))
  (let ((image (image--get-image)))
    (image-flush image)    ;;; <<---------------
    (when (and (fboundp 'imagemagick-types)
               (not (image-transforms-p)))
      (plist-put (cdr image) :type 'imagemagick))
    image))

which is called every time an image is resized. So perhaps I
misunderstand what image-flush does, or we do have a memory leak?
-- 
Alan Third

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> Date: Fri, 22 Nov 2019 10:33:00 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: larsi@gnus.org, 38187@debbugs.gnu.org, stefan@marxist.se,
> 	juri@linkov.net
> 
> > > A simple ‘solution’ to the mousewheel scaling issue would be to
> > > explicitly flush the old image from the cache on each change. I think
> > > that’s what image mode does when you zoom.
> > 
> > image-mode can do that when it knows the scaled image will replace the
> > previous one, yes.  (We will need to add an API for that, I think.)
> > But that's not cache eviction, that's application being smarter about
> > the "garbage" it produces.
> 
> Actually, now I look at the code, when an image is resized using the
> mousewheel the previous image should already be flushed.
> 
> In image.el we have this function:
> 
> (defun image--get-imagemagick-and-warn ()
>   (unless (or (fboundp 'imagemagick-types) (image-transforms-p))
>     (error "Cannot rescale images on this terminal"))
>   (let ((image (image--get-image)))
>     (image-flush image)    ;;; <<---------------
>     (when (and (fboundp 'imagemagick-types)
>                (not (image-transforms-p)))
>       (plist-put (cdr image) :type 'imagemagick))
>     image))
> 
> which is called every time an image is resized. So perhaps I
> misunderstand what image-flush does, or we do have a memory leak?

Strange indeed.  I suggest to step in a debugger through this and
other relevant code in this scenario, and see what happens there.  I'd
be surprised to know that we have a memory leak in this area.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I tested this patch, and it works well:

Great!  And I agree with Eli's comment -- a separate wrapper command
that just takes an event would be a clearer interface.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

>> I tested this patch, and it works well:
>
> Great!  And I agree with Eli's comment -- a separate wrapper command
> that just takes an event would be a clearer interface.

I noticed that using the mouse-wheel on images is not responsive enough.
It takes too much time when every step of the mouse scrolling wheel
needs to scale the image separately for every consecutive rescaling.

So I experimented with debouncing - a new macro 'debounce' swallows
all intermediate calls in quick succession to 'image--change-size',
and executes only the last call in sequence.

But actually it requires another better macro 'debounce-reduce'
that accumulates the state from all calls by multiplying all
intermediate scaling factors, and using the result on the final call:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: debounce-reduce.patch --]
[-- Type: text/x-diff, Size: 4245 bytes --]

diff --git a/lisp/emacs-lisp/timer.el b/lisp/emacs-lisp/timer.el
index 561cc70078..48301fd4fd 100644
--- a/lisp/emacs-lisp/timer.el
+++ b/lisp/emacs-lisp/timer.el
@@ -488,6 +488,48 @@ y-or-n-p-with-timeout
 If the user does not answer after SECONDS seconds, return DEFAULT-VALUE."
   (with-timeout (seconds default-value)
     (y-or-n-p prompt)))
+
+(defmacro debounce (secs function)
+  "Call FUNCTION after SECS seconds have elapsed.
+Postpone FUNCTION call until after SECS seconds have elapsed since the
+last time it was invoked.  On consecutive calls within the interval of
+SECS seconds, cancel all previous calls and in quick succession execute
+only the last call."
+  (declare (indent 1) (debug t))
+  (let ((timer-sym (make-symbol "timer")))
+    `(let (,timer-sym)
+       (lambda (&rest args)
+         (when (timerp ,timer-sym)
+           (cancel-timer ,timer-sym))
+         (setq ,timer-sym
+               (run-with-timer
+                ,secs nil (lambda ()
+                            (apply ,function args))))))))
+
+(defmacro debounce-reduce (secs state-function function)
+  "Call FUNCTION after SECS seconds have elapsed.
+Postpone FUNCTION call until after SECS seconds have elapsed since the
+last time it was invoked.  On consecutive calls within the interval of
+SECS seconds, cancel all previous calls and in quick succession execute
+only the last call.
+STATE-FUNCTION can be used to calculate the state on consecutive calls,
+and execute the last call with the collected state."
+  (declare (indent 1) (debug t))
+  (let ((timer-sym (make-symbol "timer"))
+        (state-sym (make-symbol "state")))
+    `(let (,timer-sym ,state-sym)
+       (lambda (&rest args)
+         (setq ,state-sym (apply ,state-function ,state-sym args))
+         (when (timerp ,timer-sym)
+           (cancel-timer ,timer-sym))
+         (setq ,timer-sym
+               (run-with-timer
+                ,secs nil (lambda ()
+                            (apply ,function (if (listp ,state-sym)
+                                                 ,state-sym
+                                               (list ,state-sym)))
+                            (setq ,state-sym nil))))))))
+
 \f
 (defconst timer-duration-words
   (list (cons "microsec" 0.000001)
diff --git a/lisp/image.el b/lisp/image.el
index e0965c1091..d57ae3a720 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -1016,18 +1016,20 @@ image-increase-size
 If N is 3, then the image size will be increased by 30%.  The
 default is 20%."
   (interactive "P")
-  (image--change-size (if n
-                          (1+ (/ (prefix-numeric-value n) 10.0))
-                        1.2)))
+  (funcall image--change-size
+           (if n
+               (1+ (/ (prefix-numeric-value n) 10.0))
+             1.2)))
 
 (defun image-decrease-size (&optional n)
   "Decrease the image size by a factor of N.
 If N is 3, then the image size will be decreased by 30%.  The
 default is 20%."
   (interactive "P")
-  (image--change-size (if n
-                          (- 1 (/ (prefix-numeric-value n) 10.0))
-                        0.8)))
+  (funcall image--change-size
+           (if n
+               (- 1 (/ (prefix-numeric-value n) 10.0))
+             0.8)))
 
 (defun image-mouse-increase-size (&optional event)
   "Increase the image size using the mouse."
@@ -1062,12 +1064,16 @@ image--get-imagemagick-and-warn
       (plist-put (cdr image) :type 'imagemagick))
     image))
 
-(defun image--change-size (factor)
-  (let* ((image (image--get-imagemagick-and-warn))
-         (new-image (image--image-without-parameters image))
-         (scale (image--current-scaling image new-image)))
-    (setcdr image (cdr new-image))
-    (plist-put (cdr image) :scale (* scale factor))))
+(defvar image--change-size
+  (debounce-reduce 0.3
+    (lambda (state factor)
+      (* (or state 1) factor))
+    (lambda (factor)
+      (let* ((image (image--get-imagemagick-and-warn))
+             (new-image (image--image-without-parameters image))
+             (scale (image--current-scaling image new-image)))
+        (setcdr image (cdr new-image))
+        (plist-put (cdr image) :scale (* scale factor))))))
 
 (defun image--image-without-parameters (image)
   (cons (pop image)

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I noticed that using the mouse-wheel on images is not responsive enough.
> It takes too much time when every step of the mouse scrolling wheel
> needs to scale the image separately for every consecutive rescaling.

Yeah, users are more likely to issue a bunch of scroll wheel events
rapidly than hitting `+' at the same rate, I guess.

> So I experimented with debouncing - a new macro 'debounce' swallows
> all intermediate calls in quick succession to 'image--change-size',
> and executes only the last call in sequence.
>
> But actually it requires another better macro 'debounce-reduce'
> that accumulates the state from all calls by multiplying all
> intermediate scaling factors, and using the result on the final call:

Makes sense to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefan@marxist.se>,  Eli Zaretskii <eliz@gnu.org>,
>   38187@debbugs.gnu.org
> Date: Thu, 21 Nov 2019 13:11:02 +0100
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > So I experimented with debouncing - a new macro 'debounce' swallows
> > all intermediate calls in quick succession to 'image--change-size',
> > and executes only the last call in sequence.
> >
> > But actually it requires another better macro 'debounce-reduce'
> > that accumulates the state from all calls by multiplying all
> > intermediate scaling factors, and using the result on the final call:
> 
> Makes sense to me.

Does it help to bind redisplay-dont-pause to a nil value inside
image--change-size?

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

> Does it help to bind redisplay-dont-pause to a nil value inside
> image--change-size?

I tried let-bind '(redisplay-dont-pause nil)' in image--change-size,
compilation said

  Warning: `redisplay-dont-pause' is an obsolete variable (as of 24.5).

but it still has no effect.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

>> I noticed that using the mouse-wheel on images is not responsive enough.
>> It takes too much time when every step of the mouse scrolling wheel
>> needs to scale the image separately for every consecutive rescaling.
>
> Yeah, users are more likely to issue a bunch of scroll wheel events
> rapidly than hitting `+' at the same rate, I guess.
>
>> So I experimented with debouncing - a new macro 'debounce' swallows
>> all intermediate calls in quick succession to 'image--change-size',
>> and executes only the last call in sequence.
>>
>> But actually it requires another better macro 'debounce-reduce'
>> that accumulates the state from all calls by multiplying all
>> intermediate scaling factors, and using the result on the final call:
>
> Makes sense to me.

This is installed now.

Not sure if this report can be closed, since the discussion
on image memory caching moved to bug#38345.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Not sure if this report can be closed, since the discussion
> on image memory caching moved to bug#38345.

Yeah, I think we can close this one (and I'm now doing so).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Drew Adams]

> >> AFAIU, that's not what the OP wanted.  He wanted to see _all_ images
> >> be scaled proportionally to the text scaling, regardless of where
> >> the mouse pointer is located.
> >
> > Ah; yes, I agree that that would be confusing.
> 
> FWIW, I think the opposite.  I think that zooming text, images and all
> buffer content together should be the default.  I believe that it
> would feel both natural and familiar, especially to new users, since
> that's how e.g. web browsers, LibreOffice and evince, etc. works.

I'm not speaking to that question, of whether the
default behavior should be to zoom everything in
the buffer or just the text in the buffer or
whatever other buffer content there may be.

I want to raise a different point, since you pose
the question of terminology and "zooming".

> And if we do that, why then not call this functionality "zooming"?
> That nomenclature is fairly well-established and therefore easier to
> understand for new users, I think.
> 
> Of course, if we don't do such a change, it makes no sense to
> introduce the word "zooming".  Then "change font size" or "change
> image size" is a better description of what is going on.
> 
> (That also reminds me that, IMO, text-scale-increase/decrease should
> be renamed to font-size-increase/decrease.  The current names are not
> very discoverable; when one wants to change the font size, and says:
> `M-x font TAB'.  At the very least, we should have such defaliases.)

I didn't coin the verb "zoom", of course, but I did
introduce it in the context of Emacs, AFAIK - in
3rd-party code, 15 years ago.  I agree that "zoom"
is a good way to talk about such behavior.

However, what's important here is that the thing you
are talking about zooming is the displayed _buffer_
content.  When talking about font-size change, it is
the (apparent) font size in the _buffer_ that you're
talking about.

Why do I mention this?  Because there are other ways
to zoom, and so change font size.  In particular,
you can zoom a _frame_, as opposed to a _buffer_, by
changing the value of the `font' frame parameter.

Each is useful: (1) zoom a frame, which means each
of its windows, regardless of which buffers are shown
there, and (2) zoom a buffer, which means across all
windows in all frames.

So I'd prefer that names used for the behavior you're
referring to make clear that it is about zooming the
displayed content of a _buffer_ (whether you mean only
text or text+images).  It's not about zooming a frame
(its font size, scroll-bar, images, etc.).

If you do that - make clear just what is being zoomed
(text in a buffer, text+images in a buffer, etc.) -
then there will be room for talking about zooming
other things, with no risk of confusion of terms.

Zooming doesn't apply only to a single buffer every
place it's displayed.

---

FWIW, my library `zoom-frm.el' provides commands
that let you zoom either the current buffer or the
selected frame (a single command does either).

For example, command `zoom-in/out' is a more general
replacement for `text-scale-adjust'.  I recommend
binding it to the keys bound by default to that
command: `C-x C-+', `C-x C-=', `C-x C--', `C-x C-0'.

How is it "more general"?  Option `zoom-frame/buffer'
says which kind of zooming (frame or buffer) to use
by default.  Why "by default"?  Because you can use
a prefix arg with `zoom-in/out' to toggle between
zooming the other (frame or buffer) from then on.

Besides `zoom-in/out', there are `zoom-in' and
`zoom-out', which I recommend binding to `C-wheel-up'
and `C-wheel-down' (as for web browsers).

`zoom-frm.el' doesn't zoom images.  But I agree
that an ability to zoom both text and images would
be useful - as well as an ability to zoom only text
or only images, and zoom a single image as well as
all images, whether for a buffer or a frame.

https://www.emacswiki.org/emacs/download/zoom-frm.el

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> FWIW, I think the opposite.  I think that zooming text, images and all
> buffer content together should be the default.  I believe that it
> would feel both natural and familiar, especially to new users, since
> that's how e.g. web browsers, LibreOffice and evince, etc. works.

That's true.  I guess the scroll button could change both
image-scaling-factor and text-scale-mode-amount...  But, on the other
hand, I could definitely see people preferring to change just one or the
other.  So perhaps there should be separate commands that people can
bind according to their preference?

> (That also reminds me that, IMO, text-scale-increase/decrease should
> be renamed to font-size-increase/decrease.  The current names are not
> very discoverable; when one wants to change the font size, and says:
> `M-x font TAB'.  At the very least, we should have such defaliases.)

Makes sense to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> FWIW, I think the opposite.  I think that zooming text, images and all
>> buffer content together should be the default.  I believe that it
>> would feel both natural and familiar, especially to new users, since
>> that's how e.g. web browsers, LibreOffice and evince, etc. works.
>
> That's true.  I guess the scroll button could change both
> image-scaling-factor and text-scale-mode-amount...

Perhaps we should open a separate issue for that?

> But, on the other hand, I could definitely see people preferring to
> change just one or the other.  So perhaps there should be separate
> commands that people can bind according to their preference?

100 % agree.

>> (That also reminds me that, IMO, text-scale-increase/decrease should
>> be renamed to font-size-increase/decrease.  The current names are not
>> very discoverable; when one wants to change the font size, and says:
>> `M-x font TAB'.  At the very least, we should have such defaliases.)
>
> Makes sense to me.

How does the attached patch look?  I took the minimal route of just
adding convenience aliases.

Best regards,
Stefan Kangas

[-- Attachment #2: 0001-Add-aliases-font-size-increase-decrease.patch --]
[-- Type: application/octet-stream, Size: 1022 bytes --]

From 98a7e30feaccc887354b05fcddb72c9bd715b95b Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Tue, 19 Nov 2019 15:45:15 +0100
Subject: [PATCH] Add aliases font-size-{increase,decrease}

* lisp/face-remap.el (font-size-increase, font-size-decrease): New
convenience aliases for 'text-scale-increase' and
'text-scale-decrease'.
---
 lisp/face-remap.el | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lisp/face-remap.el b/lisp/face-remap.el
index f2ff2ec6f1..08ef911d1f 100644
--- a/lisp/face-remap.el
+++ b/lisp/face-remap.el
@@ -312,6 +312,10 @@ text-scale-decrease
   (interactive "p")
   (text-scale-increase (- dec)))
 
+;; Convenience aliases.
+(defalias 'font-size-increase 'text-scale-increase)
+(defalias 'font-size-decrease 'text-scale-decrease)
+
 ;;;###autoload (define-key ctl-x-map [(control ?+)] 'text-scale-adjust)
 ;;;###autoload (define-key ctl-x-map [(control ?-)] 'text-scale-adjust)
 ;;;###autoload (define-key ctl-x-map [(control ?=)] 'text-scale-adjust)
-- 
2.23.0

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Drew Adams]

> How does the attached patch look?  I took the minimal route of just
> adding convenience aliases.

I repeat my objection.  `font-size-*' does not make
clear that this is about text scaling, which applies
to a single _buffer, wherever it is displayed_.

"Text scaling" is not a term that suggests changing
the font size.  OK, that's a disadvantage.  But the
advantage is that it is an Emacs-specific term, which,
when consulted, tells you that it changes the apparent
size of the text shown in the buffer, wherever it's
shown.

The important thing about this is that it is
buffer-specific - affects only a single buffer, and
it affects all displays of the buffer - in all windows.

I contrasted buffer-text scaling with frame zooming,
which affects all buffers shown in all windows of a
single frame.  (It does not affect any of those
buffers shown in another frame.)

IMO, "buffer" should be in the alias name somewhere.

This is not about the default font for a frame; it's
about the default face for a buffer.  Default font vs
default face, frame vs buffer.  Big difference.  Both
kinds of zooming are useful, each in its way.

Please add "buffer" to the aliases you're adding.
For example: `buffer-font-size-increase'.

(And it's not actually "font"; it's "face".  But
that's OK.)

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> I repeat my objection.  `font-size-*' does not make
> clear that this is about text scaling, which applies
> to a single _buffer, wherever it is displayed_.

Do you agree that it makes it more clear than "increase-text-scale"?

> The important thing about this is that it is
> buffer-specific - affects only a single buffer, and
> it affects all displays of the buffer - in all windows.

AFAIK, we currently have no other way of changing the font size in
Emacs.  I believe that this feature will quickly be obvious to anyone
who tries using "text-scale-increase" or "text-scale-decrease".

> Please add "buffer" to the aliases you're adding.
> For example: `buffer-font-size-increase'.

I don't object in principle.  But again, we don't have
"frame-font-size-increase" or "window-font-size-increase", so I'm not
sure if it makes things much better.  And to make it discoverable,
perhaps it's better if it starts with "font"?

> (And it's not actually "font"; it's "face".  But
> that's OK.)

Yes, there is that added confusion.  The terminology here seems to be
less than great, since the same thing can interchangeably be called
"increase font size", "increase text size", or "zoom".  See for
example this page from Firefox which manages to use all three of these
in one page:

https://support.mozilla.org/en-US/kb/font-size-and-zoom-increase-size-of-web-pages

(IME, it is never called "increase text scale" outside of Emacs.)

Best regards,
Stefan Kangas

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> AFAIK, we currently have no other way of changing the font size in
> Emacs.  I believe that this feature will quickly be obvious to anyone
> who tries using "text-scale-increase" or "text-scale-decrease".

For clarity, I should probably say "changing the font size in a
running Emacs", and also excluding things like customizing faces,
using menus or dialogs (I never use them), etc.

I'm specifically talking about the "temporarily change the font size
in this buffer/window/frame" kind of thing.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Drew Adams]

> > I repeat my objection.  `font-size-*' does not make
> > clear that this is about text scaling, which applies
> > to a single _buffer, wherever it is displayed_.
> 
> Do you agree that it makes it more clear than "increase-text-scale"?

Uh, no.  Why would `font-size-*' make it more clear
that it's about text scaling?

> > The important thing about this is that it is
> > buffer-specific - affects only a single buffer, and
> > it affects all displays of the buffer - in all windows.
> 
> AFAIK, we currently have no other way of changing the font size in
> Emacs.  I believe that this feature will quickly be obvious to anyone
> who tries using "text-scale-increase" or "text-scale-decrease".

But we do.  I mentioned library `zoom-frm.el'.  And
any of that code or similar could be added to vanilla
Emacs.  I encourage its addition.  Letting C-x C-+,
C-x C-=, C-x C--, C-x C-0 zoom either a frame or a
buffer is a plus, with no minus.

The point is that text scaling is _one_ way to change
the apparent size of text.  That way affects a single
_buffer_, in all its windows.  (And it does that by
face remapping.)

There are other ways to change displayed text size.

The name for this particular feature should, IMO,
reflect what it does specifically, especially since
we know that there are other possibilities.

> > Please add "buffer" to the aliases you're adding.
> > For example: `buffer-font-size-increase'.
> 
> I don't object in principle.  But again, we don't have
> "frame-font-size-increase" or "window-font-size-increase",
> so I'm not sure if it makes things much better.  And to
> make it discoverable, perhaps it's better if it starts
> with "font"?
> 
> > (And it's not actually "font"; it's "face".  But
> > that's OK.)
> 
> Yes, there is that added confusion.  The terminology here seems to be
> less than great, since the same thing can interchangeably be called
> "increase font size", "increase text size", or "zoom".  See for
> example this page from Firefox which manages to use all three of these
> in one page: ...

Interchangeably outside Emacs, perhaps.  Those are
different, non-interchangeable things inside Emacs.

> (IME, it is never called "increase text scale" outside of Emacs.)

What are faces called outside Emacs?  (Trick question)

Emacs has face remapping.  Does outside Emacs?  Emacs
has buffers and windows (and frames) as separate kinds
of objects that can be, but need not be, used together.

Such distinctions don't make sense (at least in most
cases) outside Emacs.  Inside Emacs, they do.  And we
are talking about inside Emacs.

There are ways to make things discoverable without
losing distinctions that are important to Emacs.

And adding "buffer" to the alias name doesn't in any
way detract from discoverability.

Quite the contrary.  If and when we do have other
ways to zoom (and I hope we do use that term "zoom",
including for discoverability), finding _this_ way
using the keyword "buffer" will be important for
discoverability.

(I didn't object to the use of "font" instead of
"face" in order to help with discoverability.)

Just one opinion.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> But we do.  I mentioned library `zoom-frm.el'.  And
> any of that code or similar could be added to vanilla
> Emacs.  I encourage its addition.  Letting C-x C-+,
> C-x C-=, C-x C--, C-x C-0 zoom either a frame or a
> buffer is a plus, with no minus.

It would be useful if you could rework that into a patch.  I think
there would be interest for having such a feature in Emacs.

Best regards,
Stefan Kangas

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Drew Adams]

> > But we do.  I mentioned library `zoom-frm.el'.  And
> > any of that code or similar could be added to vanilla
> > Emacs.  I encourage its addition.  Letting C-x C-+,
> > C-x C-=, C-x C--, C-x C-0 zoom either a frame or a
> > buffer is a plus, with no minus.
> 
> It would be useful if you could rework that into a patch.  I think
> there would be interest for having such a feature in Emacs.

I could.  But frankly I've pretty much had it
with spending time on patches, just to have
them ignored or dismissed summarily.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37417#11

I'm afraid I'd now have to have some indication
that a patch would be applied, before I'd waste
more time preparing one.

___

FYI: A patch for what zoom-frm.el offers would
need to include functions `enlarge-font' and
its helper function `frcmds-enlarged-font-name',
both from my library `frame-cmds.el'.  Or just
the alternative version of `enlarge-font' there
(in a comment), which uses `set-face-attribute'.

https://www.emacswiki.org/emacs/download/frame-cmds.el

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 19 Nov 2019 17:07:56 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 38187@debbugs.gnu.org,
>  Juri Linkov <juri@linkov.net>
> 
> > Please add "buffer" to the aliases you're adding.
> > For example: `buffer-font-size-increase'.
> 
> I don't object in principle.  But again, we don't have
> "frame-font-size-increase" or "window-font-size-increase", so I'm not
> sure if it makes things much better.

buffer-font-size-increase indeed is inaccurate, since buffers have no
fonts.

> And to make it discoverable, perhaps it's better if it starts with
> "font"?

But which font?  The feature doesn't change fonts, it remaps faces.

If you think there could be a problem with discoverability, we could
add some index entries to the manual, and maybe mention "font" in the
doc string of the command.

Other than that, I really don't see how this could be hard to
discover: we have just added a binding of C-wheel-up and C-wheel-down,
something that every application out there supports, haven't we?  So
what kind of discoverability problems we envision with that binding in
place?

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> If you think there could be a problem with discoverability, we could
> add some index entries to the manual, and maybe mention "font" in the
> doc string of the command.
>
> Other than that, I really don't see how this could be hard to
> discover: we have just added a binding of C-wheel-up and C-wheel-down,
> something that every application out there supports, haven't we?  So
> what kind of discoverability problems we envision with that binding in
> place?

That's a very good point.  I might be living in the past when we
didn't have these key bindings.

Since we also can't seem to be able to find a much better command
name, I'll retract my defalias proposal and look into your suggestion
to add an entry to the index instead.

Best regards,
Stefan Kangas

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Juri Linkov]

> Since we also can't seem to be able to find a much better command
> name, I'll retract my defalias proposal and look into your suggestion
> to add an entry to the index instead.

Yes, adding aliases doesn't help much in discoverability,
but adds more confusion because then users might think
that these are different commands for different features,
and it takes more time to check that these are aliases.

Adding an entry to the index helps in discoverability
without adding more confusion.

bug#38187: 27.0.50; No mouse-wheel scaling on images

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 19 Nov 2019 17:07:56 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 38187@debbugs.gnu.org,
>  Juri Linkov <juri@linkov.net>
> 
> AFAIK, we currently have no other way of changing the font size in
> Emacs.

Btw, this is inaccurate: we have at least 2 other ways:

  . S-mouse-1->"Change buffer font...", pops up the font selection
    dialog, where you can change the size of the font used in the
    current buffer.

  . Options->"Set Default Font..." pops up the same font selection
    dialog, but the selected font size will become the default face's
    font size.