[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Flymake and the 'face' property (was: master cd06d17: Fix bug w

From: Daniel Colascione
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
User-agent: SquirrelMail/1.4.23 [SVN]

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]