unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
Cc: rudalics@gmx.at, emacs-devel@gnu.org
Subject: Re: Customizing faces with `defcustom'
Date: Sat, 31 Dec 2005 02:48:15 +0200	[thread overview]
Message-ID: <8764p6yp8g.fsf@jurta.org> (raw)
In-Reply-To: <E1EsSSX-0007mf-E4@fencepost.gnu.org> (Richard M. Stallman's message of "Fri, 30 Dec 2005 17:10:49 -0500")

>     mode-line-mule-info variable - mode-line-mule face
>     mode-line-modified variable - mode-line-modified face
>     mode-line-frame-identification variable - mode-line-frame face
>     mode-line-position variable - mode-line-position face
>
> It is logical, but far too complicated, and not worth it.  I would
> rather have just the one face, called mode-line-emphasis or
> mode-line-location or mode-line-subject-matter, and use that for the
> buffer name and the info node name, and for any other similar thing.

I think using one face for different parts of the mode line is not
useful.  Users might want to highlight the buffer name and the info
node name with different faces.  There are already several faces for
highlighting different parts of the Info header line (`info-header-node',
`info-header-xref'), so it should be natural to add a new Info face for
the node name in the mode line.

Since part of the mode line highlighted currently in bold is clearly
associated with the buffer name (it even has a keymap for switching the
buffer), a good face name should have the word `buffer' in its name.  Any
other name would be not intuitive and even useless for other parts of
the mode line since it won't allow highlighting other parts in different
faces.

In the previous messages you said that `mode-line-buffer' is a good name
for a face used only to highlight buffer names.  So let's add this face
and also `info-mode-line-node' which by default will inherit from
`mode-line-buffer'.

BTW, while looking at `mode-line-buffer-identification-keymap', I noticed
that currently it is broken due to the recent changes in `last-buffer' which
now uses a new frame parameter `buried-buffer-list'.  This means that
mouse-1 clicked on the buffer name in the mode line uses the buffer list
from the frame parameter `buried-buffer-list', but mouse-3 uses `bury-buffer'
to put the buffer to the bottom of the global buffer list.  Either both
mouse-1 and mouse-3 should use the frame-local buffer list or the global
buffer list.  I'm not sure which is better.  Since `previous-buffer' and
`next-buffer' (that use the frame-local buffer list) currently are unfinished
(they require more changes in C after the release) they don't work reliably,
so maybe mouse-1 and mouse-3 in the mode line should use the global buffer
list.  Even though it is not convenient, it exhibits predictable behavior.

-- 
Juri Linkov
http://www.jurta.org/emacs/

  reply	other threads:[~2005-12-31  0:48 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-27 10:24 Customizing faces with `defcustom' martin rudalics
2005-08-28 15:11 ` Richard M. Stallman
2005-08-30  5:55   ` martin rudalics
2005-09-01 15:53     ` Richard M. Stallman
2005-11-12  8:09       ` martin rudalics
2005-11-13 20:54         ` Richard M. Stallman
2005-11-15  7:45           ` martin rudalics
2005-11-16 19:26           ` martin rudalics
2005-11-17 14:07             ` Richard M. Stallman
2005-11-30  2:44           ` Juri Linkov
2005-11-30  7:47             ` martin rudalics
2005-11-30 13:27               ` Per Abrahamsen
2005-11-30 15:33                 ` Juri Linkov
2005-12-23 13:23                 ` martin rudalics
2005-12-24 20:14                   ` Juri Linkov
2005-12-25 16:23                     ` martin rudalics
2005-12-26  2:20                       ` Richard M. Stallman
2005-12-27 19:05                         ` Juri Linkov
2005-12-28 17:01                           ` Richard M. Stallman
2005-12-25 19:07                     ` Richard M. Stallman
2005-12-25 19:07                     ` Richard M. Stallman
2005-12-26 16:37                       ` martin rudalics
2005-12-27  4:55                         ` Richard M. Stallman
2005-12-27 19:04                           ` Juri Linkov
2005-12-28 10:04                             ` martin rudalics
2005-12-28 15:57                               ` Juri Linkov
2005-12-28 22:48                               ` Richard M. Stallman
2005-12-29  9:47                                 ` martin rudalics
2005-12-30  2:18                                   ` Richard M. Stallman
2005-12-28 22:48                               ` Richard M. Stallman
2005-12-29  1:23                                 ` Juri Linkov
2005-12-30  2:17                                   ` Richard M. Stallman
2005-12-30  6:29                                     ` Juri Linkov
2005-12-30 14:15                                       ` martin rudalics
2005-12-31  0:48                                         ` Juri Linkov
2005-12-31 19:36                                           ` Richard M. Stallman
2005-12-30 22:10                                       ` Richard M. Stallman
2005-12-31  0:48                                         ` Juri Linkov [this message]
2005-12-31 19:36                                           ` Richard M. Stallman
2006-01-04  6:34                                             ` Juri Linkov
2006-01-05  3:46                                               ` Richard M. Stallman
2006-01-01 16:10                                           ` Richard M. Stallman
2005-12-31 17:40                                       ` Richard M. Stallman
2006-01-04  6:31                                         ` Juri Linkov
2006-01-05  3:46                                           ` Richard M. Stallman
2005-12-29 10:13                                 ` martin rudalics
2005-12-30  2:18                                   ` Richard M. Stallman
2005-12-28 17:01                             ` Richard M. Stallman
2005-12-27 19:04                       ` Juri Linkov
2005-12-28 17:01                         ` Richard M. Stallman
2005-11-30  9:15             ` Per Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8764p6yp8g.fsf@jurta.org \
    --to=juri@jurta.org \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).