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: [RFC PATCH] Per-window face support Date: Sat, 16 Jun 2018 18:06:53 +0300 Message-ID: <83lgbezs6q.fsf@gnu.org> References: <5e08587a56ad528599ed5fb259be6335.squirrel@dancol.org> <83muw5vdtr.fsf@gnu.org> <83zhzvyqfy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1529161586 638 195.159.176.226 (16 Jun 2018 15:06:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2018 15:06:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 16 17:06:22 2018 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 1fUCmT-0008RL-Pi for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2018 17:06:21 +0200 Original-Received: from localhost ([::1]:51787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUCoZ-0008Ni-3i for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2018 11:08:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUCnB-000803-Et for emacs-devel@gnu.org; Sat, 16 Jun 2018 11:07:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUCn8-0003rQ-AY for emacs-devel@gnu.org; Sat, 16 Jun 2018 11:07:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUCn8-0003rM-6Y; Sat, 16 Jun 2018 11:07:02 -0400 Original-Received: from [176.228.60.248] (port=3731 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fUCn7-0006qY-Ma; Sat, 16 Jun 2018 11:07:02 -0400 In-reply-to: (message from Daniel Colascione on Sat, 16 Jun 2018 07:24:13 -0700) 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:226363 Archived-At: > Cc: emacs-devel@gnu.org > From: Daniel Colascione > Date: Sat, 16 Jun 2018 07:24:13 -0700 > > >>> + if (w) { > >>> + Lisp_Object found = assq_no_quit (parameter, w->window_parameters); > >>> + if (!NILP (found) && EQ (XCDR (found), value)) > >>> + match = true; > >>> + } > >> > >> [...] > >> > >> Also, I wonder whether EQ should actually be equal_no_quit, because > >> the latter would allow parameters with values that are not just > >> integers or symbols. > > > > I still wonder why we only allow EQ there, it sounds unnecessarily > > restrictive. > > Because there's no need for greater power. All you need is simple > classification. That's not the Emacs way, IMO. Being able to use only integers or symbols as filtering parameters sounds too restrictive to me, and I see no reason for such restrictions. Also, the code and the documentation were clearly written with an eye towards future extensions, which seems to contradict "no need for greater power". But if I'm the only one who's bothered by these restrictions, then so be it.