Re: master 1be349c 1/2: * lisp/emacs-lisp/package.el: Define custom faces

Re: master 1be349c 1/2: * lisp/emacs-lisp/package.el: Define custom faces

[Johan Bockgård]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> branch: master
> commit 1be349c628b9fedd6db96dcd5e3d9d1abb60e4d0
> Author: Artur Malabarba <bruce.connor.am@gmail.com>
> Commit: Artur Malabarba <bruce.connor.am@gmail.com>
>
>     * lisp/emacs-lisp/package.el: Define custom faces
>     
>     (package-name-face, package-description-face)
>     (package-status-built-in-face, package-status-external-face)
>     (package-status-available-face, package-status-new-face)
>     (package-status-held-face, package-status-disabled-face)
>     (package-status-installed-face, package-status-dependency-face)
>     (package-status-unsigned-face, package-status-incompat-face)
>     (package-status-avail-obso-face): New faces.
>     (package-menu--print-info-simple): Use them.

The convention is to not end face names with "-face".

Re: master 1be349c 1/2: * lisp/emacs-lisp/package.el: Define custom faces

[Artur Malabarba]

> The convention is to not end face names with "-face".

Cool. I prefer to not end the names with `-face', but I was just
following the lead of the font-lock faces. For reference, is this
convention stated anywhere? I couldn't find it in (info "(elisp)
Defining Faces").

Re: master 1be349c 1/2: * lisp/emacs-lisp/package.el: Define custom faces

[Johan Bockgård]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> The convention is to not end face names with "-face".
>
> Cool. I prefer to not end the names with `-face', but I was just
> following the lead of the font-lock faces.

The font-lock face are different for historical reasons.

> For reference, is this convention stated anywhere? I couldn't find it
> in (info "(elisp) Defining Faces").

It says right there:

    -- Macro: defface face spec doc [keyword value]…
        This macro declares FACE as a named face whose default face spec is
        given by SPEC.  You should not quote the symbol FACE, and it should
        not end in ‘-face’ (that would be redundant).

Re: master 1be349c 1/2: * lisp/emacs-lisp/package.el: Define custom faces

[Artur Malabarba]

Clearly I should stop replying to emails past midnight.
Thanks, Johan. I'm fixing that now.

Re: master 1be349c 1/2: * lisp/emacs-lisp/package.el: Define custom faces

[Oleh Krehel]

Johan Bockgård <bojohan@gnu.org> writes:

> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>>> The convention is to not end face names with "-face".
>>
>> Cool. I prefer to not end the names with `-face', but I was just
>> following the lead of the font-lock faces.
>
> The font-lock face are different for historical reasons.
>
>> For reference, is this convention stated anywhere? I couldn't find it
>> in (info "(elisp) Defining Faces").
>
> It says right there:
>
>     -- Macro: defface face spec doc [keyword value]…
>         This macro declares FACE as a named face whose default face spec is
>         given by SPEC.  You should not quote the symbol FACE, and it should
>         not end in ‘-face’ (that would be redundant).

Is it actually a good idea not end with "-face"? I do it for all my
packages. And the reason is a very good one: I get completion
(completion-at-point, apropos, git-grep, CEDET tags, whatever) for faces
with "package-prefix.*-face". It's useful to distinguish the face
symbols from the variable symbols.

    Oleh

Re: master 1be349c 1/2: * lisp/emacs-lisp/package.el: Define custom faces

[Alexis]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> Is it actually a good idea not end with "-face"? I do it for all 
> my packages. And the reason is a very good one: I get completion 
> (completion-at-point, apropos, git-grep, CEDET tags, whatever) 
> for faces with "package-prefix.*-face". It's useful to 
> distinguish the face symbols from the variable symbols.

Agreed. In my `picolisp-mode` package, i have a defface 
`picolisp-global-variable-face`, i.e. the face used for PicoLisp 
global variables. i feel that dropping '-face' from this wouldn't 
provide any concrete benefits to me or my users, and indeed, would 
prevent the sort of useful actions you describe.


Alexis.