From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15177: 24.3.50; codepoint 35 chars displayed as binary matrix after some file names Date: Sat, 24 Aug 2013 08:00:58 -0700 (PDT) Message-ID: <780d4b6d-6c7d-4d49-b21f-d2077c6a3828@default> References: <<71165b90-083c-44a6-a6bf-19013b041fae@default>> <<83y57rgzdw.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1377356542 4592 80.91.229.3 (24 Aug 2013 15:02:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Aug 2013 15:02:22 +0000 (UTC) Cc: 15177@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 24 17:02:22 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VDFM6-0001qG-4M for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Aug 2013 17:02:22 +0200 Original-Received: from localhost ([::1]:41960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDFM5-0007sM-Mj for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Aug 2013 11:02:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDFLv-0007rK-K1 for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 11:02:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDFLn-0005KK-1A for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 11:02:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDFLm-0005KG-U1 for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 11:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VDFLm-0007p1-2u for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 11:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Aug 2013 15:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15177 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15177-submit@debbugs.gnu.org id=B15177.137735646329986 (code B ref 15177); Sat, 24 Aug 2013 15:02:01 +0000 Original-Received: (at 15177) by debbugs.gnu.org; 24 Aug 2013 15:01:03 +0000 Original-Received: from localhost ([127.0.0.1]:52586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VDFKo-0007nZ-Gy for submit@debbugs.gnu.org; Sat, 24 Aug 2013 11:01:02 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51151) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VDFKn-0007nB-1U for 15177@debbugs.gnu.org; Sat, 24 Aug 2013 11:01:01 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7OF0xJl023590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Aug 2013 15:01:00 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7OF0v3Z000228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 15:00:58 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7OF0vUd000223; Sat, 24 Aug 2013 15:00:57 GMT In-Reply-To: <<83y57rgzdw.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:77700 Archived-At: > > See attached screenshot from `emacs -Q' followed by M-x speedbar. > > > > Some of the file names are followed by a codepoint 35 character (`#') > > that is displayed as a blue matrix of tiny 0s and 1s. Other file names > > have no such character after them. (Not shown: read-only files have > > instead a yellow padlock icon following the file name.) >=20 > It's a feature; "M-x speedbar-toggle-images RET" toggles it on and > off. The tiny 0s and 1s are supposed to tell you that there's a > binary file associated with the current file. See sb-image.el for the > details. I would never have guessed that. At first I thought it might be an image, but when I did C-u C-x =3D I did not notice anything pointing that out. I guess the "displayed as" is the only hint about this. > Any reason not to close this bug? Yes, of course. It's not fixed. Just because you happen to know why users see what they see, that does not fix the bug. At all. All explanation for the user speaks only of `#'. The doc, messages, mode-string (`C-h m'), etc. all need to be updated to properly describe what the user now sees, not something s?he no longer sees by default. The doc can make clear that there are two alternative display modes: images and chars. But I already knew that, and I still had no clue as to what this was about. In particular because the doc does not provide a legend for that (or the other) images. It provides only an incomplete, hence out-of-date, legend of what each char means, not each image. At the very least, if the doc cannot show the various images, it needs to describe each of them and say what char(s) each image corresponds to in the char display. I would point out also that similar glyphs (or images or whatever) are shown when a given font cannot show some character, and a user is likely to have seen these. I was guessing that perhaps that was the problem here: some char was being displayed that the font could not show as such. And that's why I tried `C-u C-x =3D', to see what I could find out about the "mystery character". IOW, that particular image is perhaps not the best one to use to represent a binary/compiled file type. Something to consider, anyway.