From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression Date: Sun, 29 Jun 2014 17:49:53 +0000 Message-ID: <20140629174953.GE2948@acm.acm> References: <20140628130059.GA4144@acm.acm> <53AECA88.7010401@gmx.at> <20140628145509.GB4144@acm.acm> <53AFD1FA.5010201@gmx.at> <20140629091757.GA2948@acm.acm> <53AFE536.7010407@gmx.at> <20140629124829.GC2948@acm.acm> <53B02042.1050107@gmx.at> <20140629144151.GD2948@acm.acm> <53B03876.9070307@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1404064536 21897 80.91.229.3 (29 Jun 2014 17:55:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Jun 2014 17:55:36 +0000 (UTC) Cc: 16526-done@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 29 19:55:29 2014 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 1X1JK4-00033a-AB for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jun 2014 19:55:28 +0200 Original-Received: from localhost ([::1]:58652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1JK4-00028s-1i for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jun 2014 13:55:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1JJt-00028J-Us for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2014 13:55:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1JJm-00062y-Bd for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2014 13:55:17 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1JJe-0005me-DI; Sun, 29 Jun 2014 13:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X1JJd-0003ga-Py; Sun, 29 Jun 2014 13:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 29 Jun 2014 17:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16526 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 16526-done@debbugs.gnu.org id=D16526.140406447013943 (code D ref 16526); Sun, 29 Jun 2014 17:55:01 +0000 Original-Received: (at 16526-done) by debbugs.gnu.org; 29 Jun 2014 17:54:30 +0000 Original-Received: from localhost ([127.0.0.1]:36963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1JJ7-0003cm-PU for submit@debbugs.gnu.org; Sun, 29 Jun 2014 13:54:30 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:16830 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1JJ4-0003ca-N5 for 16526-done@debbugs.gnu.org; Sun, 29 Jun 2014 13:54:27 -0400 Original-Received: (qmail 85489 invoked by uid 3782); 29 Jun 2014 17:54:24 -0000 Original-Received: from acm.muc.de (pD9518149.dip0.t-ipconnect.de [217.81.129.73]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 29 Jun 2014 19:54:21 +0200 Original-Received: (qmail 32751 invoked by uid 1000); 29 Jun 2014 17:49:53 -0000 Content-Disposition: inline In-Reply-To: <53B03876.9070307@gmx.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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:90972 Archived-At: Hi, Martin. On Sun, Jun 29, 2014 at 06:01:58PM +0200, martin rudalics wrote: > > scan-lists, a primitive, must be utterly robust. syntax-ppss is too > > fragile to be used here without a lot of hardening. > > syntax-ppss's cache is rendered invalid at any operation which changes > > the syntax table (e.g. `modify-syntax-entry'), or changes to a different > > syntax table (e.g. `with-syntax-table'), or when a syntax-table text > > property/overlay is applied to the buffer, or even when a symbol's > > property list is changed when that symbol is the value of a category > > text property. CC Mode does all these things, and does all of them > > apart from the first during run time, not merely at mode initialisation. > How can any of these affect the cached start position of a defun before > the position where the buffer contents were changed? In this context, the "start of defun" means an outermost paren of some sort, nothing more, nothing less. Any of the changes above could disturb this: For example, adding an open-paren syntax-table property to a character which thereby becomes the BOD. Or temporarily switching to the Pascal syntax table, where "{" and "}" are comment brackets. I'm not saying that something like this will happen on a regular basis, but it's definitely possible. > > Also, the syntax-ppss cache's functioning is dependent upon > > before-change-functions, which can be bound to nil by any program at any > > time. > There's an appropriate advice what to do in such case. Primitive functions are deaf to advice. You're surely not suggesting that a primitive like scan-lists should become vulnerable to high-level programmers failing to follow advice? If this were to be done, scan-lists would only work most of the time, not all of the time. This would be catastrophic for Emacs. > > If one were to harden syntax-ppss against all these things, one would > > probably end up calculating the cache from scratch every time, in > > effect. > Can you give an example? An example of what? What I meant was, each time you used syntax-ppss from scan-lists, you'd somehow need to be sure that a syntax-table entry hadn't been changed, etc. I can't really see how this would be possible. You'd somehow need to handle constructs like (with-syntax-table c++-template-syntax-table .... (scan-lists (point) -1 1) ....) . > > scan-lists is a primitive, and must function correctly regardless of any > > trickery which might be played on it. > You can easily play trickery on `scan-lists' if you start it within a > comment or string. No. scan-lists works according to its spec even if you start it inside a comment/string. It's effect is well defined. For example if you write parens inside a comment, C-M-n and friends do the right thing there. > So `syntax-ppss' is at least as primitive as `scan-lists' (especially > when the latter is used with negative COUNT). Sorry, but that's utter rubbish. syntax-ppss is a high-level convenience function, which if used carefully by the lisp programmer gives correct results. By contrast, scan-lists does precisely what it says, no ifs and no buts. Even with a negative COUNT. > Anyway, IIUC this implies that CC mode can't work with `syntax-ppss' at > all. If that is true, then `open-paren-in-column-0-is-defun-start' was > indeed the last resort that made editing larger files possible. CC Mode doesn't use syntax-ppss, but I can't see how that's implied by anything we've been discussing so far. It does maintain its own caches which fulfil the same purpose. For example, there's a syntactic cache which treats preprocessor constructs as comments, something syntax-ppss can't do. open-..-start being t is a kludge which works for certain types of files and situations and not others. It was causing hard to fathom errors in CC Mode, particularly C and C++. Do I take it you're not keen on enhancing find_defun_start in the manner I suggested? > martin -- Alan Mackenzie (Nuremberg, Germany).