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

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Juri Linkov <[hidden email]>
> 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.




Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: Juri Linkov <[hidden email]>,  [hidden email]
> Date: Sun, 17 Nov 2019 11:04:59 +0100
>
> Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Stefan Kangas
Lars Ingebrigtsen <[hidden email]> writes:

> Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>>> 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?



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Stefan Kangas
> >> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Stefan Kangas
Stefan Kangas <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> 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:


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."
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Juri Linkov <[hidden email]>
> Cc: Stefan Kangas <[hidden email]>,  Eli Zaretskii <[hidden email]>,
>   [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Stefan Kangas
In reply to this post by Lars Ingebrigtsen
Lars Ingebrigtsen <[hidden email]> 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

0001-Add-aliases-font-size-increase-decrease.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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.)



Reply | Threaded
Open this post in threaded view
|

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

Stefan Kangas
Drew Adams <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Stefan Kangas
Stefan Kangas <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Stefan Kangas
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Stefan Kangas
> From: Stefan Kangas <[hidden email]>
> Date: Tue, 19 Nov 2019 17:07:56 +0100
> Cc: Lars Ingebrigtsen <[hidden email]>, [hidden email],
>  Juri Linkov <[hidden email]>
>
> > 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?



Reply | Threaded
Open this post in threaded view
|

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

Stefan Kangas
Eli Zaretskii <[hidden email]> 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



123