Re: Fwd: Flymake and the 'face' property (was: master cd06d17: Fix bug with face-id after restoring from pdump)

[Eli Zaretskii]

> From: João Távora <address@hidden>
> 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 <facility-name>--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.