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: Wed, 2 Jul 2014 20:05:22 +0000 Message-ID: <20140702200522.GB3823__14778.0174426318$1404331903$gmane$org@acm.acm> References: <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> <20140629174953.GE2948@acm.acm> <53B117D6.1050306@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1404331903 31643 80.91.229.3 (2 Jul 2014 20:11:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jul 2014 20:11:43 +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 Wed Jul 02 22:11:35 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 1X2QsQ-0005iB-8A for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Jul 2014 22:11:34 +0200 Original-Received: from localhost ([::1]:56267 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2QsP-00020a-Qo for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Jul 2014 16:11:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2QsD-0001q0-PM for bug-gnu-emacs@gnu.org; Wed, 02 Jul 2014 16:11:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2Qs5-00070u-8Z for bug-gnu-emacs@gnu.org; Wed, 02 Jul 2014 16:11:21 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2Qrv-0006xa-89; Wed, 02 Jul 2014 16:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X2Qru-0001zd-2m; Wed, 02 Jul 2014 16:11: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: Wed, 02 Jul 2014 20:11:02 +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.14043318107546 (code D ref 16526); Wed, 02 Jul 2014 20:11:02 +0000 Original-Received: (at 16526-done) by debbugs.gnu.org; 2 Jul 2014 20:10:10 +0000 Original-Received: from localhost ([127.0.0.1]:40755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X2Qqz-0001xT-E0 for submit@debbugs.gnu.org; Wed, 02 Jul 2014 16:10:10 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:64955 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X2Qqr-0001wj-4K for 16526-done@debbugs.gnu.org; Wed, 02 Jul 2014 16:10:02 -0400 Original-Received: (qmail 64250 invoked by uid 3782); 2 Jul 2014 20:09:55 -0000 Original-Received: from acm.muc.de (pD9519C56.dip0.t-ipconnect.de [217.81.156.86]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 02 Jul 2014 22:09:54 +0200 Original-Received: (qmail 4172 invoked by uid 1000); 2 Jul 2014 20:05:22 -0000 Content-Disposition: inline In-Reply-To: <53B117D6.1050306@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:91115 Archived-At: Hi, Martin. On Mon, Jun 30, 2014 at 09:55:02AM +0200, martin rudalics wrote: > >> 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. > Then you can forget caching. No. The particular rogue invocation of scan-lists which caused this (sub-)thread scans from BOB to near EOB 29 times. Inside scan-lists, _NO_ changes to syntax-tables, s-t text properties etc. are possible. What I'm suggesting is that cacheing that first scan from BOB will be a big win for many time-consuming scan-listses. [ .... ] > I meant that if someone is going to disable `before-change-functions' > that someone has to take care of flushing the cache. OK. > > 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) > > ....) > > . > And how would a defun start cache handle such constructs? Such a cache would be initialised to nil within a particular invocation of scan-lists, hence nothing like the above could cause any trouble. > > 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 writen > > parens inside a comment, C-M-n and friends do the right thing there. > Here C-M-n is bound to `forward-list' which according to its doc-string > "assumes point is not in a string or comment". `scan-lists' has > precisely the same problems as `syntax-ppss' wrt syntax changes. scan-lists is an atomic function, without memory of any state. It's functionality is wholly determined by the current buffer state and the current setting of (quite a few) state variables. syntax-ppss is motivated by cacheing historical state, hence is critically different. > >> 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. > We're not talking about `scan-lists' alone. We're talking about > `scan-lists' (or more precisely find_defun_start) with a cache of > previously calculated positions. OK, I think I see what you're getting at. You're thinking of a cache which would endure over random buffer changes. The cache I was intending would be flushed at the beginning of each scan-lists. "What I tell you three times is true." (Lewis Carroll, The Hunting of the Snark). > > By contrast, scan-lists does precisely what it says, no ifs and no buts. > > Even with a negative COUNT. > Any "problems" of `syntax-ppss' in this regard are the problems of > scan_lists plus those of maintaining a cache. No ifs and no buts. > >> 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. > And how do you invalidate that cache? It's truncated at buffer changes. It doesn't contain any information which could become stale on any of the other sorts of modifications we've been talking about, or it isn't used when they could hurt anything. That this cache has a tightly defined purpose is why it can be robust, whereas syntax-ppss's cache, being very general purpose, is vulnerable to certain changes. > > 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++. > I can live with such errors. I can't live with the slowdown. I'm hoping the slowdown will go away, or at least become tolerable, when scan-lists is optimised. > > Do I take it you're not keen on enhancing find_defun_start in the manner > > I suggested? > What you're asking for is impossible: > (1) You want to base find_defun_start on scan_lists starting at BOB. No, on scan_sexps_forward, which (despite the confusing name) is the core of parse-partial-sexp without its lispy arguments. > This means that you need a function that repeatedly calls > scan_lists, stopping whenever depth reaches zero and remembers that > position, returning the last such position before FROM. Such a > function exists already - it's called `parse-partial-sexp'. Yes. Or scan_sexps_forward which is the C core of it. > (2) You want to avoid that function call scan_lists repeatedly by > caching previously found positions. Such a function exists already > - it's called `syntax-ppss'. I'd have nothing against using syntax-ppss, as long as its cache was bound to nil for each scan-lists call - except it would cause some slowdown (compared with a special-purpose cache written in C), since it goes through the lisp bytecode interpreter. > (3) You want that function to work even if someone changes the syntax > table or disables `before-change-functions' without flushing its > cache. Such a function does not exist and never will. No, I want that cache to be flushed for each scan-lists call, so that the first scan of (nearly) the whole buffer will create the cache, and the other 28 scans will use that cache. > martin -- Alan Mackenzie (Nuremberg, Germany).