unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: 38187@debbugs.gnu.org, juri@linkov.net
Subject: bug#38187: 27.0.50; No mouse-wheel scaling on images
Date: Sun, 17 Nov 2019 15:01:01 -0800 (PST)	[thread overview]
Message-ID: <c6a48cf0-5c93-4f79-a269-bf6b7b348445@default> (raw)
In-Reply-To: <878soemc79.fsf@marxist.se>

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





  parent reply	other threads:[~2019-11-17 23:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 20:38 bug#38187: 27.0.50; No mouse-wheel scaling on images Juri Linkov
2019-11-14 12:48 ` Eli Zaretskii
2019-11-17 10:04   ` Lars Ingebrigtsen
2019-11-17 16:05     ` Eli Zaretskii
2019-11-17 16:07       ` Lars Ingebrigtsen
2019-11-17 21:20         ` Stefan Kangas
2019-11-17 22:42           ` Juri Linkov
2019-11-18  9:10             ` Lars Ingebrigtsen
2019-11-18 21:37               ` Juri Linkov
2019-11-19  3:31                 ` Eli Zaretskii
2019-11-20 23:00                   ` Juri Linkov
2019-11-21  3:35                     ` Eli Zaretskii
2019-11-21 21:18                     ` Alan Third
2019-11-21 22:51                       ` Juri Linkov
2019-11-22  7:47                         ` Eli Zaretskii
2019-11-21 21:26                     ` Lars Ingebrigtsen
2019-11-21 22:57                       ` Juri Linkov
2019-11-21 23:10                         ` Lars Ingebrigtsen
2019-11-22  7:58                           ` Eli Zaretskii
2019-11-22  7:51                         ` Eli Zaretskii
2019-11-22  7:31                       ` Eli Zaretskii
2019-11-22 12:41                         ` Lars Ingebrigtsen
2019-11-22  9:50                       ` Alan Third
2019-11-22 10:04                         ` Eli Zaretskii
2019-11-22 10:33                           ` Alan Third
2019-11-22 13:26                             ` Eli Zaretskii
2019-11-19  8:09                 ` Lars Ingebrigtsen
2019-11-20 23:12                   ` Juri Linkov
2019-11-21 12:11                     ` Lars Ingebrigtsen
2019-11-21 14:25                       ` Eli Zaretskii
2019-11-21 22:45                         ` Juri Linkov
2019-11-23 22:23                       ` Juri Linkov
2019-11-27 11:58                         ` Lars Ingebrigtsen
2019-11-17 23:01           ` Drew Adams [this message]
2019-11-18  9:08           ` Lars Ingebrigtsen
2019-11-19 14:49             ` Stefan Kangas
2019-11-19 15:27               ` Drew Adams
2019-11-19 16:07                 ` Stefan Kangas
2019-11-19 16:12                   ` Stefan Kangas
2019-11-19 16:27                   ` Drew Adams
2019-11-21  0:01                     ` Stefan Kangas
2019-11-21  0:41                       ` Drew Adams
2019-11-19 16:31                   ` Eli Zaretskii
2019-11-19 16:54                     ` Stefan Kangas
2019-11-19 22:50                       ` Juri Linkov
2019-11-19 17:27                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6a48cf0-5c93-4f79-a269-bf6b7b348445@default \
    --to=drew.adams@oracle.com \
    --cc=38187@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=larsi@gnus.org \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).