bug#37770: [PATCH] Expose scale factor through the redisplay interface

[Robert Pluim]

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