From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bug#7517: 24.0.50; repeated crash under Mac OS X Date: Mon, 03 Jan 2011 00:08:50 +0200 Message-ID: <83sjxbnekt.fsf@gnu.org> References: <87vd2dyzfj.fsf@stupidchicken.com> <4D1B22A1.6080202@swipnet.se> <4D1B27AF.7010701@swipnet.se> <4D1C6E7D.2040300@swipnet.se> <4D1D0172.8080404@swipnet.se> <4D1DB555.5080002@swipnet.se> <4D1DBD4A.6010303@swipnet.se> <83d3oiaysj.fsf@gnu.org> <4D1DD655.1040809@swipnet.se> <83aajmaxme.fsf@gnu.org> <4D1E5987.2000502@swipnet.se> <83mxnkq1ej.fsf@gnu.org> <8362u8pkg6.fsf__47242.3368752517$1293906238$gmane$org@gnu.org> <83y674ne9h.fsf@gnu.org> <19744.58213.935000.469856@gargle.gargle.HOWL> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1294006073 9455 80.91.229.12 (2 Jan 2011 22:07:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 2 Jan 2011 22:07:53 +0000 (UTC) Cc: user.emacs@gmail.com, emacs-devel@gnu.org To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 02 23:07:48 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PZW5c-0005sa-7Y for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2011 23:07:48 +0100 Original-Received: from localhost ([127.0.0.1]:48832 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZW5b-0005h7-NZ for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2011 17:07:47 -0500 Original-Received: from [140.186.70.92] (port=41509 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZW5U-0005cX-27 for emacs-devel@gnu.org; Sun, 02 Jan 2011 17:07:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZW5M-0006sl-FY for emacs-devel@gnu.org; Sun, 02 Jan 2011 17:07:39 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:65042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZW5M-0006sQ-73 for emacs-devel@gnu.org; Sun, 02 Jan 2011 17:07:32 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LEF00F000CVG000@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 03 Jan 2011 00:06:45 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.127.157]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LEF00EHR1F2B4G0@a-mtaout20.012.net.il>; Mon, 03 Jan 2011 00:06:40 +0200 (IST) In-reply-to: <19744.58213.935000.469856@gargle.gargle.HOWL> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134179 Archived-At: > Date: Sun, 2 Jan 2011 20:43:17 +0000 > From: Uday S Reddy > Cc: Uday S Reddy , > user.emacs@gmail.com, > emacs-devel@gnu.org > > > The only subtlety here is that iso-8859-8-i is a coding-system-alias > > of iso-8859-8. Does that help to resolve the issue? > > I have now given up on using the mime-charset property to search for > coding systems because of the too many aliases going on. However, it > seems that all the coding systems have aliases that correspond to MIME > charset names. So, I am using that to find the right coding system. Why, doesn't (coding-system-get FOO :mime-charset) work for you, or isn't TRT in this case? > However, OP reports that the frame title says "bad coding" or some > such incantation, even though the buffer name shows up correctly > inside Emacs. Perhaps it is a problem in the interface between Emacs > and the OS? No, that's our way to defend ourselves against buffer names that are unibyte strings, to avoid a crash that was the trigger for this bug. If the unibyte buffer name is now solved, the "bad coding" text will never show up.