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: Wed, 26 Jul 2017 17:42:20 +0300 Message-ID: <83mv7r5kfn.fsf@gnu.org> References: <83y3s9pm2a.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> <83y3rsgwkk.fsf@gnu.org> <87vamfg8kc.fsf@lylat> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1501080975 2722 195.159.176.226 (26 Jul 2017 14:56:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Jul 2017 14:56:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 26 16:56:07 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 1daNjA-0008Ey-Pi for ged-emacs-devel@m.gmane.org; Wed, 26 Jul 2017 16:55:56 +0200 Original-Received: from localhost ([::1]:38636 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1daNjG-0004aL-He for ged-emacs-devel@m.gmane.org; Wed, 26 Jul 2017 10:56:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1daNWI-0008Um-Ow for emacs-devel@gnu.org; Wed, 26 Jul 2017 10:42:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1daNWF-00062V-L8 for emacs-devel@gnu.org; Wed, 26 Jul 2017 10:42:38 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1daNWF-00062R-I6; Wed, 26 Jul 2017 10:42:35 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1435 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1daNWF-0003Nw-06; Wed, 26 Jul 2017 10:42:35 -0400 In-reply-to: <87vamfg8kc.fsf@lylat> (message from Alex on Tue, 25 Jul 2017 21:50:59 -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:217041 Archived-At: > From: Alex > Cc: emacs-devel@gnu.org > Date: Tue, 25 Jul 2017 21:50:59 -0600 > > Hopefully the fixed-pitch issue is behind us now. Seems so. > > 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. > > That makes sense, but I still don't understand why explicitly inheriting > from default makes a difference for face remapping. Is it just a > hardcoded workaround? The inheriting face references its parent, so when the parent is remapped, that affects the inheriting face through the attributes that are inherited. What is "hardcoded" here is that text-scale-adjust affects the 'default' face, so faces unrelated to it will not be affected. > > face-remapping-alist is only handled where we decided to handle it, > > and I think I at least partially understand why, see above. > > Would it make sense to handle it in the line-number area? I don't know. Why should it? It didn't affect linum and nlinum faces. What we have now allows users to customize the face both if they want it to be sensitive to scaling, and if they don't. Why should we take that freedom from them?