From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers, final testing Date: Sat, 29 Jul 2017 00:12:42 -0600 Message-ID: <87k22r3h5x.fsf@lylat> References: <83y3s9pm2a.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> <83mv7r5kfn.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1501308797 26856 195.159.176.226 (29 Jul 2017 06:13:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Jul 2017 06:13:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 29 08:13:10 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 1dbKzm-0006FT-PD for ged-emacs-devel@m.gmane.org; Sat, 29 Jul 2017 08:13:02 +0200 Original-Received: from localhost ([::1]:51278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dbKzs-0004BM-JL for ged-emacs-devel@m.gmane.org; Sat, 29 Jul 2017 02:13:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dbKze-0004AR-5A for emacs-devel@gnu.org; Sat, 29 Jul 2017 02:12:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dbKza-0002Yj-0c for emacs-devel@gnu.org; Sat, 29 Jul 2017 02:12:54 -0400 Original-Received: from mail-it0-x22b.google.com ([2607:f8b0:4001:c0b::22b]:35862) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dbKzZ-0002Y9-RE; Sat, 29 Jul 2017 02:12:49 -0400 Original-Received: by mail-it0-x22b.google.com with SMTP id v205so89494234itf.1; Fri, 28 Jul 2017 23:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=otxxmiEH6sJPoWPtxFurOKA0qBwEXctwANBvnNUa5Yw=; b=ck9d2DUE39XfGpKcaaFsL0WwbaPFbA/bR1cRfa/sDmGKWiKfOI/k4+07mcxdC4Tvsl QN3hbcChJLC0t1Fhwh7Vzon8o4LeEFTYOiEKYUqESs4bATay+NMdwwX8f4+aoH08fFNT LETotWfLP5weFd1zoCawylSdlDqjurhXvWnbmVqb8LOxxQxGLy3Hr3fS4MNa1mqA6sMp 5uju3Hj0zIAYX9vjaIViJjIns4Ngkzr9eDFu63a75iX6HVm3QFyUP/SDb/ajfam9e+4e 85XWXSi0J7fU8rOHmNB9hFxhmxi5YewhML1pghx4G3tTk4dh7vOk2YG4ZnCcFazHBJeQ Y1Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=otxxmiEH6sJPoWPtxFurOKA0qBwEXctwANBvnNUa5Yw=; b=GmhnjQLmupjO+UJuDnk8As/WR5HDGjq0CSHugJAP58B1moHwTAtg93JFLsl6aD8uRW pVSkuiLyFA9YJuu8j3CuIfEYibJPbkN4z9ekt9j8ii7QNk0ZNMu+i80Rxz0/jr3wx5XQ ej50O1mMuIM33YGGsPJUc1rNmLRX5dQu6uu2YHC4L2LVxwKC2SLoVBih+xQDSTtRP/J+ X8zGbNOYk9bwTEx3gL5Ay269qANeh6r5+3Tcymv3LFVXNXRmmrKL0sWXGIYUELl6kr9B sN05NGKgfzcBY+W/EpLy8YARSYJRI0ecrbfEmRJkvzC+xdRhvpqYYbErbVHHJArtQYN/ EptQ== X-Gm-Message-State: AIVw112wdyB9fUrTgKNWMjRyjoVl0tDn+J9h4cYJ9huYYRcrqcSZMcpI PccguiEinbMV+frX X-Received: by 10.36.246.204 with SMTP id u195mr11110987ith.116.1501308768824; Fri, 28 Jul 2017 23:12:48 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id r186sm2340574iod.6.2017.07.28.23.12.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 28 Jul 2017 23:12:47 -0700 (PDT) In-Reply-To: <83mv7r5kfn.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Jul 2017 17:42:20 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::22b 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:217117 Archived-At: Eli Zaretskii writes: >> From: Alex >> Cc: emacs-devel@gnu.org >> Date: Tue, 25 Jul 2017 21:50:59 -0600 >>=20 >> > 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. >>=20 >> 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. Right, but it's not clear to me why explicitly inheriting from default is treated differently from an :inherit value of 'unspecified. From the manual: An =E2=80=98unspecified=E2=80=99 attribute tells Emacs to refer instead t= o a parent face >> > face-remapping-alist is only handled where we decided to handle it, >> > and I think I at least partially understand why, see above. >>=20 >> Would it make sense to handle it in the line-number area?=20 > > 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? I don't think the ability to customize it should go away, but the system in place that allows for the customization just seems odd to me. Instead of using an ostensibly redundant :inherit value, why not make a customizable list of faces that face remapping also affects? Perhaps it's too much work for too little gain. In that case, then at least documenting the current behaviour would be nice.