From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: steve@sanityinc.com, 28248@debbugs.gnu.org
Subject: bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
Date: Thu, 19 Oct 2017 01:40:15 +0300 [thread overview]
Message-ID: <c129eb7e-2f4c-05b4-3b77-58a80d383e42@yandex.ru> (raw)
In-Reply-To: <83infce7ni.fsf@gnu.org>
On 10/18/17 7:35 PM, Eli Zaretskii wrote:
> It's not uncommon in Emacs to have optional arguments that modify the
> behavior of a function and thus affect their results. It could be
> that this is the first such function whose optional argument happens
> to be called PIXELWISE, but if thats the problem, we can easily change
> the name, and I will probably do so.
The other functions with PIXELWISE argument just have it change the
return value to be pixelwise, that's all. So I'm for consistency here.
With the changed name, it will be the first function to have an argument
that controls pixelwise-ness, that is named something else :)
> I think I will add a 3rd value of the PIXELWISE argument, which will
> report the full width, but in units of the frame's canonical character
> (such a result will have to be a float, though). I think this will
> satisfy your needs, and the needs of other applications. Do you
> agree?
Sure. Although I'd rather the third value made it return the "inner"
width, and nil and t meant to measure the same thing (at the cost in
some backward incompatibility with the pre-release Emacs versions). But,
again, I'm not saying this issue is critical.
> Are we miscommunicating? The value returned by the function when its
> optional argument is nil or omitted is in columns of the line-number
> face, not of the frame's default face. E.g., if someone customizes
> line-number to use a font that is twice as large as that used for
> 'default', the result will be half of what you'd expect. So dividing
> by frame-char-face is exactly the wrong thing.
All right, that's a good point, thank you. I'll look into this again
when I revisit the code.
> The division should be done with floats, then the accuracy loss due to
> off-by-one errors will not be that catastrophic.
Hmm, maybe so. But then we'll have to switch to floats everywhere, for
this to have a meaningful benefit.
> I think it's better to keep the number of similar functions to a
> minimum, otherwise it's hard top remember which does what. I see no
> problem to have a single function serve 2 or 3 different purposes,
> controlled by optional arguments. We do this elsewhere.
Sounds GTM.
next prev parent reply other threads:[~2017-10-18 22:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-27 5:40 bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width Steve Purcell
2017-08-27 9:15 ` Stephen Berman
2017-08-27 14:37 ` Eli Zaretskii
2017-08-27 14:32 ` Eli Zaretskii
2017-10-16 21:56 ` Dmitry Gutov
2017-10-17 2:34 ` Eli Zaretskii
2017-10-17 6:19 ` Steve Purcell
2017-10-17 7:01 ` Eli Zaretskii
2017-10-17 7:31 ` Steve Purcell
2017-10-17 8:15 ` Eli Zaretskii
2017-10-17 8:23 ` Dmitry Gutov
2017-10-17 16:33 ` Eli Zaretskii
2017-10-18 0:33 ` Dmitry Gutov
2017-10-18 16:35 ` Eli Zaretskii
2017-10-18 22:40 ` Dmitry Gutov [this message]
2017-10-19 3:15 ` Eli Zaretskii
2017-10-20 9:44 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c129eb7e-2f4c-05b4-3b77-58a80d383e42@yandex.ru \
--to=dgutov@yandex.ru \
--cc=28248@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=steve@sanityinc.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.