From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: History for query replace pairs Date: Sun, 09 Nov 2014 17:10:17 -0500 Message-ID: References: <87iojduj9n.fsf@mail.jurta.org> <87k33nyirh.fsf@mail.jurta.org> <87sii0becx.fsf@lifelogs.com> <87ioivx2xk.fsf@mail.jurta.org> <87h9yfaihq.fsf@lifelogs.com> <87zjc6pnpg.fsf@mail.jurta.org> <87r3xhnsjb.fsf@mail.jurta.org> <87zjc2pou7.fsf@mail.jurta.org> <87zjc2fqx2.fsf@lifelogs.com> <83oasiqduw.fsf@gnu.org> <87ioiq7yre.fsf@mail.jurta.org> <83ioiqq6j8.fsf@gnu.org> <87vbmpnw3a.fsf@mail.jurta.org> <83d28wpcy1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415571061 11927 80.91.229.3 (9 Nov 2014 22:11:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Nov 2014 22:11:01 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 09 23:10:54 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XnahB-0003Hq-RS for ged-emacs-devel@m.gmane.org; Sun, 09 Nov 2014 23:10:53 +0100 Original-Received: from localhost ([::1]:40132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnahB-0003VV-6A for ged-emacs-devel@m.gmane.org; Sun, 09 Nov 2014 17:10:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnagr-0003VM-Oq for emacs-devel@gnu.org; Sun, 09 Nov 2014 17:10:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xnagk-0004We-8M for emacs-devel@gnu.org; Sun, 09 Nov 2014 17:10:33 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:38327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnagc-0004UY-Br; Sun, 09 Nov 2014 17:10:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRLd+sd/2dsb2JhbABWBoMOg2KGfstTBAICgRwXAQF8hAMBAQMBViMQCzQSFBgNJIhLCctyAQEBAQYBAQEBHpBFQweESwWEYocCjyuXEYFvhBYfgnoBAQE X-IPAS-Result: Au4MAOatTlRLd+sd/2dsb2JhbABWBoMOg2KGfstTBAICgRwXAQF8hAMBAQMBViMQCzQSFBgNJIhLCctyAQEBAQYBAQEBHpBFQweESwWEYocCjyuXEYFvhBYfgnoBAQE X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96498195" Original-Received: from 75-119-235-29.dsl.teksavvy.com (HELO ceviche.home) ([75.119.235.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Nov 2014 17:10:17 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 6DD8466100; Sun, 9 Nov 2014 17:10:17 -0500 (EST) In-Reply-To: <83d28wpcy1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Nov 2014 18:15:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176651 Archived-At: >> char-displayable-p doesn't work reliably for text-terminals. > I think it's the other way around: it's not 100% reliable on GUI > frames, due to half-hearted way we test whether the available fonts > support the character. It's not 100% reliable for GUI frames (especially if the test doesn't pay attention to the `face' that's added), but for tty frames it's even worse since the only thing we (can) test is whether the char can be encoded in the terminal's coding-system. With the typical utf-8 encoding used under GNU/Linux and OSX nowadays this basically means that char-displayable-p under ttys will almost always return t, regardless of whether the text-terminal's font can actually display such a char (and since text-terminals are usually restricted to monospaced fonts, they have much less liberty to "look for alternative fonts" when faced with an unusual char, so it's much more frequent that they just can't display a character). Stefan