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

[Daniel Colascione]

> [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 <address@hidden> 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.
>

We could also just use an uninterned symbol.