unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Chong Yidong <cyd@stupidchicken.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: x-font-family-list
Date: Fri, 09 Jan 2009 15:32:52 -0500	[thread overview]
Message-ID: <877i54jk3v.fsf@cyd.mit.edu> (raw)
In-Reply-To: <utz88jljx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Jan 2009 22:01:38 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand this change:
>
>> 	* xfaces.c (Fx_font_family_list): Function deleted.  Compatibility
>> 	version moved to faces.el.
>
> This "compatibility version" is not compatible, AFAICS: it claims that
> none of the font families are fixed-pitch, and also assumes that some
> builds of Emacs don't have font-family-list fboundp, which is never
> true AFAIK.  The net effect is that in the --without-x and MS-DOS
> builds x-font-family-list now returns nil, whereas previously it was
> unbound in the --without-x build and on MS-DOS returned `("default" . t)'.
>
> What am I missing?  What was the purpose of this change?

The previous version of x-font-family-list (in xfaces.c) was broken---it
simply returned the return value of font-family-list, and so did not do
what the docstring said.  I noticed that when updating the font handling
documentation, so I made this change, but forgot to implement the
fixed-p part.  Thanks for spotting the omission

> If the value of this function is not important at all, let's delete it
> completely.  If it _is_ important, then let's make the replacement
> really compatible, which means at the very least make the cdr of the
> cons cells it returns be non-nil for fixed-pitch font families.

I don't think it's important, but am not sure whether there is any
external code relying on it.  Normally, this means that we should try to
change the compatibility function and make it compatible.  But, I don't
know a simple way of computing whether a font is fixed-pitch using the
new font code, without jumping through some ugly hoops (e.g., somehow
turning each family name into an xlfd and examining its "monospace"
entry).  If no one can suggest a good method, let's just delete the
function.




  reply	other threads:[~2009-01-09 20:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1LLIEC-0007fX-03@monty-python.gnu.org>
2009-01-09 20:01 ` x-font-family-list Eli Zaretskii
2009-01-09 20:32   ` Chong Yidong [this message]
2009-01-10  4:57     ` x-font-family-list Leo
2009-01-10  9:15     ` x-font-family-list Eli Zaretskii
2009-01-10 12:58       ` x-font-family-list Chong Yidong
2009-01-10 14:58         ` x-font-family-list Eli Zaretskii
2009-01-10 15:00         ` x-font-family-list Eli Zaretskii
2009-01-10 16:08           ` x-font-family-list Jason Rumney
2009-01-10 18:26             ` x-font-family-list Eli Zaretskii

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=877i54jk3v.fsf@cyd.mit.edu \
    --to=cyd@stupidchicken.com \
    --cc=eliz@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).