From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 19:51:36 +0200 Message-ID: <83bm3z2vyv.fsf@gnu.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="239007"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 29 18:52:30 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 1goXYj-00103K-Cg for ged-emacs-devel@m.gmane.org; Tue, 29 Jan 2019 18:52:29 +0100 Original-Received: from localhost ([127.0.0.1]:53132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1goXYi-0008N8-34 for ged-emacs-devel@m.gmane.org; Tue, 29 Jan 2019 12:52:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1goXY3-0008N0-VV for emacs-devel@gnu.org; Tue, 29 Jan 2019 12:51:48 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1goXY3-0007AS-SE; Tue, 29 Jan 2019 12:51:47 -0500 Original-Received: from [176.228.60.248] (port=2336 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1goXY2-0004ew-Hs; Tue, 29 Jan 2019 12:51:46 -0500 In-reply-to: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Tue, 29 Jan 2019 17:26:50 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:232793 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.