[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37770: [PATCH] Expose scale factor through the redisplay interface
From: |
Robert Pluim |
Subject: |
bug#37770: [PATCH] Expose scale factor through the redisplay interface |
Date: |
Thu, 17 Oct 2019 10:01:40 +0200 |
>>>>> On Wed, 16 Oct 2019 16:08:47 -0300, Carlos Pita
>>>>> <carlosjosepita@gmail.com> said:
Carlos> I've capitalized changelog entries in the message and also added a
Carlos> reference to the bug number.
Carlos> Eli told me that you prefer code comments to long commit messages
but
Carlos> in this case I think the rationale would be lost in fragmentary
Carlos> comments here and there. It's true that there is still the reference
Carlos> to this discussion in the commit message, but I believe it's
Carlos> convenient to quickly get a description of the change using git
blame
Carlos> when browsing the code. If you disagree I will remove the notes from
Carlos> the commit message and copy them here.
If by 'you' you mean 'Emacs', then yes, putting stuff in the code
is preferred, I think. Of course nothing stops us from doing both.
Carlos> From 01e52de9ce49bc0b3490492891f066d2f9306cf4 Mon Sep 17 00:00:00 2001
Carlos> From: memeplex <carlosjosepita@gmail.com>
Carlos> Date: Tue, 15 Oct 2019 19:14:03 -0300
Carlos> Subject: [PATCH] Expose scale factor through the redisplay interface
Carlos> (Bug#37770)
Carlos> * src/dispextern.h (redisplay_interface): Add get_scale_factor API.
Carlos> * src/xterm.c (x_get_scale_factor): Consolidate with xg_get_scale
(see
Carlos> bug#37752) and export through the rif. Simplify scale inferring
Carlos> logic (see note 1 below).
2 spaces after '.'
Carlos> Note 1: both x_get_scale_factor and w32_get_scale_factor computed
Carlos> distinct scales for x and y by taking the ratio between effective
Carlos> resolution in each direction and a standard 96 dpi resolution.
Since
Carlos> this ratio is then truncated to an integer (the floor) it seems to
me
Carlos> that there is no sensible possibility that these two numbers
Carlos> diverge. Moreover, modern toolkits report one number as scale factor
Carlos> and we need a common interface here. For those reasons I'm
arbitrarily
Carlos> picking the horizontal scale factor as THE scale factor.
Carlos> Note 2: I decided to let get_scale_factor return a double, even
tough
Carlos> factors currently in use are all integers AFAIK. This is in
Carlos> anticipation of fractional scaling. I believe it's prudent to keep
Carlos> the interface general in this regard.
I tend to lean towards putting this sort of rationale at the beginning
of the commit message, and let the ChangeLog message explain the
mechanics of the change.
Robert
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/15
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/15
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Robert Pluim, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface,
Robert Pluim <=
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Eli Zaretskii, 2019/10/20
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/20
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/22
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Robert Pluim, 2019/10/24
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/24