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

["João Távora" <joaotavora@gmail.com>]

[Sorry for the double email Eli, I forgot to CC the list in the first one]

On Tue, Jan 29, 2019 at 4:55 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > As far as I can understand, this is because flymake-error, the flymake error
> > type, is conflated with flymake-error, the face.
> 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,
designating no more than a flymake diagnostic type (and not a face).
There is no reason why you would ask for the face ID of _that_ symbol,
is there?

> 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... 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.

So I'd first study the possibility of avoiding this "doubling as a
face symbol", which was merely aesthetic and even slightly confusing.

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.

--
João Távora