From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: What `opic0ids' really is [was: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.] Date: Thu, 14 Dec 2006 13:53:22 -0800 (PST) Message-ID: <48768.128.165.123.18.1166133202.squirrel@webmail.lanl.gov> References: <87odqhj89q.fsf@stupidchicken.com> <20061210014526.GB3738@muc.de> <877ix0lfm8.fsf@furball.mit.edu> <20061210102249.GA1235@muc.de> <87d56rpk7a.fsf@stupidchicken.com> <20061213224009.GA1206@muc.de> <87odq72ssy.fsf@stupidchicken.com> <20061214084713.GA1333@muc.de> <45812BDF.5050107@gmx.at> <20061214193733.GA1269@muc.de> Reply-To: herring@lanl.gov NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1166133234 1905 80.91.229.10 (14 Dec 2006 21:53:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 14 Dec 2006 21:53:54 +0000 (UTC) Cc: martin rudalics , Chong Yidong , emacs-devel@gnu.org, Richard Stallman , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 14 22:53:52 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GuyWS-0005ta-Ia for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 22:53:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuyWS-0004fh-3x for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 16:53:48 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuyWE-0004db-77 for emacs-devel@gnu.org; Thu, 14 Dec 2006 16:53:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuyWA-0004bq-Ms for emacs-devel@gnu.org; Thu, 14 Dec 2006 16:53:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuyWA-0004bn-J8 for emacs-devel@gnu.org; Thu, 14 Dec 2006 16:53:30 -0500 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GuyW8-0006DS-Pg; Thu, 14 Dec 2006 16:53:29 -0500 Original-Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by mailwasher-b.lanl.gov (8.13.8/8.13.8/(ccn-5)) with ESMTP id kBELrPFu021885; Thu, 14 Dec 2006 14:53:26 -0700 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay2.lanl.gov (8.13.8/8.13.8/(ccn-5)) with ESMTP id kBELrNNw005742; Thu, 14 Dec 2006 14:53:23 -0700 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id kBELrNpg003774; Thu, 14 Dec 2006 14:53:23 -0700 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id kBELrMoE003769; Thu, 14 Dec 2006 13:53:22 -0800 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.18 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Thu, 14 Dec 2006 13:53:22 -0800 (PST) Original-To: "Alan Mackenzie" User-Agent: SquirrelMail/1.4.8-2.el3.7lanl X-Priority: 3 (Normal) Importance: Normal In-Reply-To: <20061214193733.GA1269@muc.de> X-PMX-Version: 4.7.1.128075 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:63745 Archived-At: > I say we should GIVE THE USER THE CHOICE. I have proposed a way of > doing this to which nobody's commented yet: Have three values for the > variable with the furlong long name, namely (t nil mode). t and nil > will carry on meaning what they mean, and the symbol 'mode, the > default, will mean "Major mode may set its own default here". > > Comments, please! I've not been in this thread thus far, but I feel that the point may be being missed here. open-paren-in-column-0-is-defun-start is purely an optimization: 1. If the user knows that "bad" C0 parens are sufficiently rare ("sufficiently" for his purposes) that assuming them to be defun-start points, he should set the variable to t (perhaps as a file-local in a long C file which would otherwise be a problem). 2. If another user knows that code she deals with does not follow good indentation standards or is using some preprocessor or so that makes that assumption invalid, she should set the variable to nil (again, perhaps locally). 3. If a mode knows that its language requires that the rule be followed (or that it is followed in all halfway-sensible cases), it MAY (see RFC 2119) set opic0ids to t locally in its buffers, but it SHOULD NOT assume that the variable is non-nil (in that, perhaps, it assumes that low-level functions involved in `beginning-of-defun' will act as they do when it is non-nil) unless it specifically dynamically binds the variable so. 4. If a mode knows that its language requires or merely often involves that other C0 parens appear, it SHOULD set opic0ids to nil locally in its buffers. If a user overrides this setting, the mode SHOULD NOT fail or raise errors, and MUST NOT make incorrect textual buffer modifications, but may of course produce and/or cache incorrect answers about the structure of text in the buffer. All that I think is common sense or follows from the definition of opic0ids as an optimization control. My own suggested guidelines follow. 5. A mode MAY ignore opic0ids in its own code (and bind it conveniently when calling into standard routines) if parens are not associated with defuns in its language. A mode MAY similarly ignore the variable if (for some operation) it provides a more powerful, faster, more convenient, or otherwise superior (e.g., updates useful internal data) mechanism for finding the beginnings of defuns that incurs no user-perceptible performance penalty for any operation on a well-formed file of a size and complexity ever encountered in practice on the overwhelming majority of modern hardware. 6. Any feature or behavior without which a mode is usable (even if crippled) and which has the potential in any plausible scenario to delay editing (particularly repeatedly) MUST be controllable by a user option (although the default value SHOULD enable it so that it is available except when problematic and is known in the first place). 7. A mode SHOULD interpret the assumption implied by opic0ids non-nil as appropriate to that mode; for instance, in C mode, where functions begin not with their opening { but rather with the return type of the function, a C0 paren (with opic0ids set) may be assumed to be the beginning of a function's root block, but the mode should still arrange to move before the argument list, name, and return type (as possible) when performing `beginning-of-defun' or the equivalent. 8. A mode MUST NOT use the value of opic0dis to decide whether to make other unrelated assumptions or simplifications, but it MAY provide a value of a user option which means "enable iff opic0ids is set". 9. All code MUST NOT assume the converse -- that all starts of defuns are heralded by C0 parens -- as a result of the value of opic0ids. 10. All code SHOULD NOT assume that converse ever, unless their language requires it to be the case. If it is prohibitively expensive not to assume it, it may be assumed, but this variance MUST be documented and SHOULD be controlled by a user option (whose default value MAY allow the assumption) if feasible. I note that in 21.3.1 (the only version I have available at the moment) Emacs Lisp mode violates #10. Sorry that this is something of a rant, but I want to put out a set of rules such that either A) we come to agree that they are a good representation of how things should be, so that we now have a guide for how to resolve things; B) we discover that we are not in agreement about what the goals/effects of this user option are/should be, so that we can address them instead of wasting time talking at cross purposes; or C) we find that I was right to stay out of this thread because I do not understand the subject or have uselessly unique ideas about it, so that I will resume silence and not waste anyone's time with lots of shorter messages that would be no more helpful. So, er, which is it? Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.