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: Wed, 18 Oct 2017 03:33:52 +0300 [thread overview]
Message-ID: <bbd47b5b-3c0e-eaab-ef8a-486a0e30c750@yandex.ru> (raw)
In-Reply-To: <834lqxg2ef.fsf@gnu.org>
On 10/17/17 7:33 PM, Eli Zaretskii wrote:
> They are used for 2 different purposes, which are contradictory to
> some degree.
But that's true for all core functions with a PIXELWISE argument, isn't
it? Yet, the rest measure the same thing in both cases, AFAIK.
> The value in column units is primarily meant to be used
> for setting display-line-numbers-width (see, e.g., how
> display-line-numbers.el uses that), and also for users, so burdening
> them with anything that is not directly related to the value of the
> largest visible line number would be a nuisance.
Maybe display-line-numbers-width could include the separator columns as
well.
> OTOH, the
> column-unit value is of limited utility for layout calculations,
> because the columns are of the line-number face, which could be
> smaller or larger than the default face.
That changes little for me: overlay-based layout can't do anything with
pixels anyway. If all I can do is divine the resulting value by
frame-char-width and hope for the best, I might as well use the return
value in columns to begin with.
Furthermore, in Company, we already call similar functions (like
window-body-height) with PIXELWISE nil.
> Therefore, layout
> calculations should use the function's pixelwise variety, and convert
> into columns by dividing by the width of the font used for buffer
> text. (Which btw means my response to you earlier -- see above -- was
> incomplete: you should use the function in pixel-unit mode, if you
> need to account for the screen space eaten by line numbers, and then
> you don't have to add anything to the value it returns.)
I can't help but worry about how an off-by-one error in pixel width
(which is not strictly defined) would result in an off-by-one error in
column width after division. And again, I'm in no position to use the
pixelwise value.
>> On the other hand, the return value of the function can differ from what
>> a variable is set to.
>
> I think that'd be a nuisance; again, see what display-line-numbers.el
> does.
>
> I agree that this is not ideal, to say the least, but I hope you at
> least understand the issues now. If there's a better solution, I'm
> all ears.
display-line-numbers-update-width might look worse, I agree. But we
could have two functions, right? Both line-number-display-width and
display-line-numbers-update-width could delegate to
line-number-display-inner-width.
Just a suggestion.
>> the function's docstring needs updating.
>
> Done.
Thank you.
> P.S. I'd still like to hear your opinions on the related questions I
> asked here:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28855#8
Sorry, I haven't noticed your question, and I don't know what :align-to
is about. And to be frank, I don't understand that question now.
I'll try to re-read and respond.
next prev parent reply other threads:[~2017-10-18 0:33 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 [this message]
2017-10-18 16:35 ` Eli Zaretskii
2017-10-18 22:40 ` Dmitry Gutov
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=bbd47b5b-3c0e-eaab-ef8a-486a0e30c750@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.