From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: [RFC PATCH] Per-window face support Date: Sat, 16 Jun 2018 08:30:52 -0700 Message-ID: References: <5e08587a56ad528599ed5fb259be6335.squirrel@dancol.org> <83muw5vdtr.fsf@gnu.org> <83zhzvyqfy.fsf@gnu.org> <83lgbezs6q.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1529162986 22253 195.159.176.226 (16 Jun 2018 15:29:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2018 15:29:46 +0000 (UTC) User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Daniel Colascione , emacs-devel@gnu.org To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 16 17:29:42 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 1fUD94-0005im-3x for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2018 17:29:42 +0200 Original-Received: from localhost ([::1]:51853 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUDBB-0004nH-07 for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2018 11:31:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUDAG-0004n7-VI for emacs-devel@gnu.org; Sat, 16 Jun 2018 11:30:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUDAF-0002vC-VK for emacs-devel@gnu.org; Sat, 16 Jun 2018 11:30:56 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:47730) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fUDAD-0002t1-Vq; Sat, 16 Jun 2018 11:30:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=Iez/gvHYQGJxG2Soo38o9AISpbar09GuS+DK0tvvSAQ=; b=ajVtQ2WWv/jveB8kgXVQwIZXa0ajI499AF+P2xPCrvyNnAl7opRmGFDVDlJW+63F577z7L6hIYjRJ0/f5l/EjrEaeAkUjwI+urhEfGwMIPqqyqUj666G1wGz9R15oEO/983V4USkDqtBKPQkvWPzMkubq7NpMyd/2tzC1oewl4ZHEgvnwR29ru4GewrshVnKZV7qSEXY1A/Z6xV4NzREGZpIFCH3SnUgx0UuwXK9Dsew8pgmQUgCfl7IWUTY9655Ldi1kOj4msIDYg5laX2lWgP7q6wiUpGmQz53pmdCWdNtnTQairZqrTXBPVAox7kvrj/iObUmU8fdOyDuE9ZOlQ==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUDAC-0001yd-PU; Sat, 16 Jun 2018 08:30:52 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Sat, 16 Jun 2018 08:30:52 -0700 In-Reply-To: <83lgbezs6q.fsf@gnu.org> X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:226366 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. There's no loss of generality in allowing only eq at face filtering time: you can set an integer or symbol to reflect the result of any other computation, as I do at https://github.com/dcolascione/emacs-window-highlight/blob/master/window-highlight.el. If you want to evaluate a condition more complex than eq can handle, you arrange to run some code when your condition changes, then store the result of your comparison in a property that the face filter can inspect with eq. Anything you can do by allowing equal in filters, you can do using this technique. 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. Contractually allowing something more powerful than eq here can really screw us over later: what happens when we equal-compare large data structures? What happens when we eventually get custom type-by-type equality predicates? What happens if we want to cache the result of applying face filters? The way it is now, with an eq-test, the result of a face filter operation can change _only_ after a call to set-window-parameter or an update of a face spec somewhere. I don't want to give up this invariant for no reason. Limiting the test to eq greatly simplifies the contract while not reducing power. _That's_ the Emacs way.