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#4835: 23.1; Improper `Invalid face reference' messages. Performance degraded. Date: Sat, 31 Oct 2009 15:40:26 -0700 Message-ID: <5101E088BA774F93BCA9BA30DF7C826F@us.oracle.com> References: <87ws2bfkyt.fsf@stupidchicken.com><87iqdvmk1j.fsf@stupidchicken.com><6ABF3195EEF74EB780205758FA68D61B@us.oracle.com><87pr83th6b.fsf@stupidchicken.com><8F2C3E771C104B03B9926AB1AAFD02A5@us.oracle.com> <87zl7743tj.fsf@stupidchicken.com> Reply-To: Drew Adams , 4835@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1257030460 17177 80.91.229.12 (31 Oct 2009 23:07:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2009 23:07:40 +0000 (UTC) Cc: 4835@emacsbugs.donarmstrong.com To: "'Chong Yidong'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 01 00:07:33 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N4N2f-0004pq-HQ for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Nov 2009 00:07:29 +0100 Original-Received: from localhost ([127.0.0.1]:44443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4N2e-00080h-N0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Oct 2009 19:07:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4N2Z-00080H-9A for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 19:07:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4N2U-0007zj-SG for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 19:07:22 -0400 Original-Received: from [199.232.76.173] (port=58929 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4N2U-0007zg-Mu for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 19:07:18 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:43432) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N4N2T-0005o6-9b for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 19:07:18 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9VN7FEg017606; Sat, 31 Oct 2009 16:07:15 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9VMo4ah014490; Sat, 31 Oct 2009 15:50:04 -0700 Resent-Date: Sat, 31 Oct 2009 15:50:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sat, 31 Oct 2009 22:50:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4835 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4835-submit@emacsbugs.donarmstrong.com id=B4835.125702889213535 (code B ref 4835); Sat, 31 Oct 2009 22:50:04 +0000 Original-Received: (at 4835) by emacsbugs.donarmstrong.com; 31 Oct 2009 22:41:32 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9VMfUKk013522 for <4835@emacsbugs.donarmstrong.com>; Sat, 31 Oct 2009 15:41:31 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9VMfw5e002101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 31 Oct 2009 22:42:00 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9VLSMej024020; Sat, 31 Oct 2009 22:42:45 GMT Original-Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 20744033801257028829; Sat, 31 Oct 2009 15:40:29 -0700 Original-Received: from dradamslap1 (/141.144.80.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 31 Oct 2009 15:40:29 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpadkjyHWiCqldjT0q5jpSMCOW+CAAAN37A In-Reply-To: <87zl7743tj.fsf@stupidchicken.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4AECBD11.0014:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sat, 31 Oct 2009 19:07:22 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:32331 Archived-At: > > Nonsense. You could say that it's crystal clear from the > > Elisp manual that _function_ was meant (since that's what > > is says) and not symbol function or "function name" (which > > would be a string). The code is bugged wrt its mission as > > documented in the manual, which is the > > closest thing we have to a spec. > > Nonsense. The manual is not a spec. What else do we have to go on? The code is bugged, and no one knows what the original intention was. How can you tell that function was _not_ intended and using `fboundp' instead of `functionp' was _not_ just an oversight? As I mentioned, the font-lock code _itself_ apparently uses a lambda form as a function here. And the doc clearly says a function is called for, without any further qualification. You seem to be arbitrarily imposing a restriction which is unwarranted. Your only reasons have been: 1. The doc string says "function name". That is wrong anyway, since that would be a string (which won't work). And if the manual is no spec, a doc string is even less of one. You are favoring an incorrect doc string over a lengthy passage in the manual that mentions the criterion of being a "function" multiple times. Why? 2. The currently bugged behavior, in at least one case when a lambda form is tried. Why canonize this bugged behavior? But: a. Font-lock itself uses a lambda form (without an error, for some reason - just why should be investigated). b. The manual clearly says that a function is allowed here. It says so in several places in several ways. "A function" means any function, not just a symbol. c. There is no comment in the code indicating that we intentionally use `fboundp' for some reason. Nothing speaks about an intended restriction or what problems `fboundp' avoids. Nothing indicates that `fboundp' is really intended instead of `functionp', and not just an oversight. d. Replacing `fboundp' by `functionp' might well fix the bug and thus align the code with the manual's description of what it's supposed to do. The remaining thing to do would then be to fix the doc string - which needs to be fixed anyway. Instead of fixing the bug (by allowing any function), you want to cast it in concrete and document the bugged behavior as if it were intentional. Doesn't make sense to me. What does the code actually _do_ with this function? That is the real question. Until we answer that question, there is no sense imposing an arbitrary interpretation on things and adding unnecessary restrictions. AFAICT, the code simply passes the function to `funcall'. Why is there any need to restrict funcall's arg here to be an `fboundp' symbol? You haven't given one reason why this should be limited to a symbol. Show why `functionp' is problematic, and you might have an argument. All you've shown is that the call to `fboundp' fails for a lambda form, so the wrong code path is followed. The solution to that is to use `functionp' so the right code path will be followed.