From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers, final testing Date: Thu, 13 Jul 2017 18:56:11 +0300 Message-ID: <83y3rsgwkk.fsf@gnu.org> References: <83y3s9pm2a.fsf@gnu.org> <874luuyuqy.fsf@lylat> <83wp7po86m.fsf@gnu.org> <87fuecc7vg.fsf@lylat> <83y3s2n5pa.fsf@gnu.org> <878tk1rmjx.fsf@lylat> <83a84gn4z9.fsf@gnu.org> <837ezkmwfg.fsf@gnu.org> <874lumps82.fsf@lylat> <8337a5ja4p.fsf@gnu.org> <83van0i5wl.fsf@gnu.org> <87iniy7ksy.fsf@lylat> <83pod6idqp.fsf@gnu.org> <87zical61u.fsf@lylat> <83mv89ivms.fsf@gnu.org> <87zic9a7tg.fsf@lylat> <8360exijpe.fsf@gnu.org> <87r2xla0e4.fsf@lylat> <8337a1hxhb.fsf@gnu.org> <87d1959dsv.fsf@lylat> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499961972 20667 195.159.176.226 (13 Jul 2017 16:06:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Jul 2017 16:06:12 +0000 (UTC) Cc: cloos@jhcloos.com, emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 13 18:06:08 2017 Return-path: Envelope-to: ged-emacs-devel@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 1dVgco-0004je-PB for ged-emacs-devel@m.gmane.org; Thu, 13 Jul 2017 18:05:58 +0200 Original-Received: from localhost ([::1]:60919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVgcu-0006ip-7v for ged-emacs-devel@m.gmane.org; Thu, 13 Jul 2017 12:06:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVgTS-0006Ks-RU for emacs-devel@gnu.org; Thu, 13 Jul 2017 11:56:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVgTP-0001rD-Q5 for emacs-devel@gnu.org; Thu, 13 Jul 2017 11:56:18 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVgTP-0001r3-Mg; Thu, 13 Jul 2017 11:56:15 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3476 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dVgTO-0008Jo-J7; Thu, 13 Jul 2017 11:56:15 -0400 In-reply-to: <87d1959dsv.fsf@lylat> (message from Alex on Wed, 12 Jul 2017 22:11:12 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216583 Archived-At: > From: Alex > Cc: cloos@jhcloos.com, emacs-devel@gnu.org > Date: Wed, 12 Jul 2017 22:11:12 -0600 > > >> I don't see a single reason to make it different. > > > > It's for when the default face uses a variable-pitch font, as I > > believe I already explained. > > I wasn't referring to the fixed-pitch part, just the serif part. The > addition of serifs is orthogonal to fixing the case of a > variable-pitched default font. In your patch, you injected an unrelated > property into the face that has nothing to do with fixing the > variable-pitch issue. I tried using fixed-pitch first, and it on my system it picked up a bad font, that's why I switched to fixed-pitch-serif. We should now see if that gives satisfactory results, before using something more elaborate, like different definitions for different platforms. > Just to make myself extra clear: I am in favour of forcing line numbers > to be fixed-pitch by default. However, I'm not in favour of using > "Monospace Serif" instead of "Monospace" considering that the default is > the latter. But "Monospace" is not guaranteed to yield the same font as the default face has in "emacs -Q". It perhaps does that on your system, but not on mine, and I don't expect it to do that for everyone. The "standard" font used by the default face in "emacs -Q" is determined by the standard fontset, whose spec is window-system specific. Moreover, "Monospace" etc. specifies a family, not a specific font; what font will that produce depends on the OS (see comments to face-font-family-alternatives) and on the fonts installed on the particular user's system. So if your expectation is that the line-number face by default uses the same font as the one picked up via the standard fontset, it will not be achieved by using fixed-pitch, except by sheer luck. IOW, this is a complex issue, because the specific font used for the face depends on factors some of which are OS-dependent and others depend on the installed fonts. At least some of these factors are unpredictable, so choosing a good default that will work for everyone is not easy. The solution we seek needs IMO to satisfy the following requirements: . it should always use a fixed-pitch font, even if the default face or the standard fontset are customized to use a variable-pitch font . it should obey text-scale-adjust . it should be defined by defface, so it's easily customizable . it should yield the same visual appearance on all frames (unless the user explicitly customizes it differently for different frames) . it shouldn't change during an Emacs session, except if the user explicitly customizes it during that session If you can come up with a way to satisfy these requirements while producing the same font as the default face in "emacs -Q", please show your solution. I couldn't think of a way of doing that for all the supported platforms, but I don't consider myself an expert on faces. In any case, using fixed-pitch does NOT guarantee the same font as you get by default, not on all platforms anyway, so doing that is not the solution we seek. It's possible that fixed-pitch-serif will produce unsatisfactory results on some systems. ("Unsatisfactory" here means that the numbers look ugly or not easily legible, or we pick up a font of low quality, like some raster font. "Unsatisfactory" does NOT necessarily mean identical to the default font in "emacs -Q".) In that case, we will have to look for better solutions. But we are not there yet, IMO. > I find it disappointing that you ignored the rest of my email. I didn't ignore it, I just didn't see any constructive responses that would advance the discussion. All I see is a fundamental disagreement where you repeatedly insist on getting the same font as in the default case, which I think is a relatively weak requirement, and I don't know how to achieve that universally without violating the stronger requirements listed above. Disagreements about defaults are frequently like that, they can only be resolved by collecting enough opinions and experiences; 2 opposite experiences are definitely not enough. > > I don't think I understood what you consider a bug here. Face > > attributes are calculated when the face is created, they are not > > updated whenever the default face changes. > > Not in the case of 'unspecified, right? Evaluating (set-face-bold > 'default t) changes every face with an 'unspecified bold attribute to > bold. Yes, but face remapping is not implemented by setting attributes of existing faces. It (internally) produces new faces and redirects existing faces to those new ones. And I think there's a good reason for that: we definitely do NOT want _all_ the faces to change their sizes to follow the remapping of 'default'. For starters, we only want the faces to change in the current buffer, and we don't want faces like 'tooltip' and 'mode-line' to change even for the current buffer. > So if I'm understanding this correctly, then you shouldn't have to > inherit from 'default since any unspecified attributes already fallback > to 'default. The behaviour in this case is different, therefore this is > a bug (something isn't handling face-remapping-alist correctly). face-remapping-alist is only handled where we decided to handle it, and I think I at least partially understand why, see above.