From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width Date: Wed, 18 Oct 2017 19:35:13 +0300 Message-ID: <83infce7ni.fsf@gnu.org> References: <834lst5bep.fsf@gnu.org> <83d15mfqoj.fsf@gnu.org> <785ae770-ea0a-ec74-c986-fde32a48ab0f@yandex.ru> <834lqxg2ef.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1508344585 9284 195.159.176.226 (18 Oct 2017 16:36:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 18 Oct 2017 16:36:25 +0000 (UTC) Cc: steve@sanityinc.com, 28248@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 18 18:36:18 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4rKA-00008f-Cl for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Oct 2017 18:36:06 +0200 Original-Received: from localhost ([::1]:45563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4rKH-0001ug-OA for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Oct 2017 12:36:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4rK7-0001sC-4h for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2017 12:36:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e4rK6-0001ul-42 for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2017 12:36:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39839) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e4rK6-0001uY-0l for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2017 12:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e4rK5-0007th-NS for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2017 12:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Oct 2017 16:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28248 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28248-submit@debbugs.gnu.org id=B28248.150834454830332 (code B ref 28248); Wed, 18 Oct 2017 16:36:01 +0000 Original-Received: (at 28248) by debbugs.gnu.org; 18 Oct 2017 16:35:48 +0000 Original-Received: from localhost ([127.0.0.1]:48520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4rJs-0007tA-4s for submit@debbugs.gnu.org; Wed, 18 Oct 2017 12:35:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52043) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4rJq-0007st-0d for 28248@debbugs.gnu.org; Wed, 18 Oct 2017 12:35:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e4rJh-0001ex-Ey for 28248@debbugs.gnu.org; Wed, 18 Oct 2017 12:35:40 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44158) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4rJh-0001et-BA; Wed, 18 Oct 2017 12:35:37 -0400 Original-Received: from [176.228.60.248] (port=3754 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e4rJf-00051Z-Pa; Wed, 18 Oct 2017 12:35:37 -0400 In-reply-to: (message from Dmitry Gutov on Wed, 18 Oct 2017 03:33:52 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138674 Archived-At: > Cc: steve@sanityinc.com, 28248@debbugs.gnu.org > From: Dmitry Gutov > Date: Wed, 18 Oct 2017 03:33:52 +0300 > > 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. 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 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. 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? > > 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. 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. In a nutshell, when the optional arg is nil, the return value is the number of digits allocated/used for displaying the numbers, not the number of columns it takes. I hope I've succeeded in explaining the issue now. > Furthermore, in Company, we already call similar functions (like > window-body-height) with PIXELWISE nil. That function returns its value in units of frame's canonical character width, so it suits your needs much better. > 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. The division should be done with floats, then the accuracy loss due to off-by-one errors will not be that catastrophic. > > 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. 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.