From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: Fwd: Flymake and the 'face' property (was: master cd06d17: Fix bug with face-id after restoring from pdump) Date: Tue, 29 Jan 2019 09:54:57 -0800 Message-ID: <6f94dc3fda7d52b9df14af08f34c2b88.squirrel@dancol.org> References: <20190128152540.6870.46132@vcs0.savannah.gnu.org> <20190128152541.12A4D20B50@vcs0.savannah.gnu.org> <30bm401x64.fsf@fencepost.gnu.org> <83r2cw35jq.fsf@gnu.org> <83munk33gj.fsf@gnu.org> <83h8dr2yll.fsf@gnu.org> <83bm3z2vyv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="256101"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: =?iso-8859-1?Q?=22Jo=C3=A3o_T=C3=A1vora=22?= , emacs-devel@gnu.org To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 29 18:56:11 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1goXcI-0014Uv-BR for ged-emacs-devel@m.gmane.org; Tue, 29 Jan 2019 18:56:10 +0100 Original-Received: from localhost ([127.0.0.1]:53148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1goXcH-0001PY-3e for ged-emacs-devel@m.gmane.org; Tue, 29 Jan 2019 12:56:09 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1goXbA-0001Nx-2t for emacs-devel@gnu.org; Tue, 29 Jan 2019 12:55:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1goXb9-000086-7r for emacs-devel@gnu.org; Tue, 29 Jan 2019 12:55:00 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49258) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1goXb8-00007X-01; Tue, 29 Jan 2019 12:54:58 -0500 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=c488kLGdQxBq6PvHSowBY4Il2R58ABVxDpDR+AP1KVI=; b=eL3JE6uEH8YVye3O5G+9Q0ETKmZg5EzQpFBIiBbP7mgOg2MBf3z0Wv+C5umsyfdqjTogqCQ1CudBvUCXWBp54iRI92WCyTPulpJ2ZlCjA9Zguqd4q7UAA58yVoA9Xl1MHlrtcWHCnuoLG4Cs4fdhtdkYCNjeFsjdBEDtOoXwZSQMdTdpjD8dAPRru8GWY+lgOb6WlJJiCB1TIa3h0l1au42rP/yFlWdtKN30L4DBPrBgd0vZSm08ijZKd3d09ENEZZG0u+DqDS9TcEmSjVbwy8cJs3vssFofhos/h0LoFgXFgEQt5HF3mLnCFZMMNzXPRHzCp2gderRfblYbUjMCuQ==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1goXb7-0005HQ-9J; Tue, 29 Jan 2019 09:54:57 -0800 Original-Received: from 172.92.145.124 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Tue, 29 Jan 2019 09:54:57 -0800 In-Reply-To: <83bm3z2vyv.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:232795 Archived-At: >> From: João Távora >> Date: Tue, 29 Jan 2019 17:26:50 +0000 >> >> > No, the problem is that each face has its numeric face ID stored as >> > the value of the face symbol's 'face' property. So, no matter what is >> > the face symbol, its 'face' property should not be touched. >> >> Undoubtedly, but if the face changes the name to 'flymake-error-face' >> and >> the diagnostic type retains the name 'flymake-error', then the 'face' >> property >> will not be applied to a face, but to an arbitrary, non-face related >> symbol, > > Ah, okay. Yes, this will solve the problem with the face. > >> > It's too late for that, I think. Instead, packages should IMO try to >> > keep the global namespace clean in the property domain as well, thus >> > defining properties whose names have the prefix of the package name. >> >> That is certainly true for properties whose semantics are valid only >> within a package. But flymake.el here is merely managing existing >> properties of overlays designated by "external" symbols, such as >> 'face' ,'priority' ,'display', 'help-echo' ,etc... > > That is okay as long as the properties are used as documented. > >> Now, flymake.el happened to be unlucky enough to store these >> properties in the plist of a symbol which, by doubling as a face >> symbol, already had some implementation-specific a meaning for some >> of those properties. > > A 'face' property is documented for general use only for text, not for > symbol plists. > >> As a backward-compatible alternative to that, if it is not an immense >> amount of work, we could look at the Emacs facility that treats 'face' >> as an implementation detail (i.e. doesn't give it public meaning, >> contrary >> to what text- and overlay properties do), and change it to use another >> name for that implementation detail, such as --face-id >> or something. >> >> I think this second alternative is consistent with your views on the >> global namespace. It might be more work though. > > More importantly, I see no reason for such backward-incompatible > change. It is easier to change one package, flymake, than to > potentially impose incompatible changes on external packages and user > customizations, even though this is an internal usage. It just is too > veteran to change it for this reason. Making this 'face property on random symbols special is bad design. It affects only flymake *as far we know*, but that could be ignorance or blind luck. Emacs shouldn't be using high-collision-probability names on arbitrary symbols for internal purposes when other options are available.