From: Miles Bader <miles@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: terminal capability querying
Date: 20 Apr 2002 18:58:57 +0900 [thread overview]
Message-ID: <87pu0upu72.fsf@tc-1-100.kawasaki.gol.ne.jp> (raw)
In-Reply-To: <3776-Sat20Apr2002123114+0300-eliz@is.elta.co.il>
"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > No #-of-colors tests, but nice, flexible behavior on lots of display
> > types!
>
> This will work well if we assume that color choices for foreground and
> background are independent. I suspect that it's not always so. In
> those cases where there's a dependency between the two colors, I think
> we had better keep that dependency explicit in defface in some way
> (although doing that via the number of supported colors is not the
> only possible way).
Actually, it occured to me that it would be a nice feature to also allow
passing attribute lists to `display-supports-face-attribute-p' (or
whatever it ends up being called), e.g.:
(display-supports-face-attribute-p '(:foreground "red" :background "white"))
In most cases the effect would be same as simply the `and' of the
individual attributes, but for others, it could use the extra info to
return more `intelligent' results; in the case where both :foreground
and :background are specified, for instance, it could at least ensure
that the colors are `different".
For X displays, it could use more fully-specified font info to test, for
instance, if a font _really_ has a bold-faced font in a particular
family. For instance, it might return true for '(:weight bold) but
nil for '(:family "wackyfont" :weight "bold") -- many non-standard
fonts lack bold-faced variants.
Since a list of attributes is the form that occurs naturally in the
defface `or'-vectors I described, this would directly benefit people
using defface (and make defface's job even easier).
> So sometimes your vector of alternative colors will have to specify a
> totally different foreground color for low-end displays, and thus
> require a suitably different background color.
I agree, sometimes it's going to be necessary to use special cases, so
it's clearly necessary to be able to do low-level tests like the number
colors, but I'd like to avoid it as much as possible.
-Miles
--
"Most attacks seem to take place at night, during a rainstorm, uphill,
where four map sheets join." -- Anon. British Officer in WW I
next prev parent reply other threads:[~2002-04-20 9:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-20 2:20 terminal capability querying Miles Bader
2002-04-20 7:08 ` Eli Zaretskii
2002-04-20 8:12 ` Miles Bader
2002-04-20 9:31 ` Eli Zaretskii
2002-04-20 9:58 ` Miles Bader [this message]
2002-04-20 11:46 ` Eli Zaretskii
2002-04-21 20:02 ` Richard Stallman
2002-04-22 0:20 ` Miles Bader
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=87pu0upu72.fsf@tc-1-100.kawasaki.gol.ne.jp \
--to=miles@gnu.org \
--cc=emacs-devel@gnu.org \
/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).