From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression Date: Thu, 03 Jul 2014 10:40:00 +0200 Message-ID: <53B516E0.2020501@gmx.at> 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> <20140702200522.GB3823@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1404376898 32583 80.91.229.3 (3 Jul 2014 08:41:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Jul 2014 08:41:38 +0000 (UTC) Cc: 16526-done@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 03 10:41:31 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 1X2caA-00063H-9k for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Jul 2014 10:41:30 +0200 Original-Received: from localhost ([::1]:58503 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2ca9-00068i-TW for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Jul 2014 04:41:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2cZz-00067R-Ii for bug-gnu-emacs@gnu.org; Thu, 03 Jul 2014 04:41:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2cZs-0007L8-1X for bug-gnu-emacs@gnu.org; Thu, 03 Jul 2014 04:41:19 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2cZj-0007JM-Uj; Thu, 03 Jul 2014 04:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X2cZi-000569-Rl; Thu, 03 Jul 2014 04:41:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 03 Jul 2014 08:41: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.140437682119507 (code D ref 16526); Thu, 03 Jul 2014 08:41:02 +0000 Original-Received: (at 16526-done) by debbugs.gnu.org; 3 Jul 2014 08:40:21 +0000 Original-Received: from localhost ([127.0.0.1]:41056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X2cZ1-00054W-Bm for submit@debbugs.gnu.org; Thu, 03 Jul 2014 04:40:20 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:51865) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X2cYy-000546-CI for 16526-done@debbugs.gnu.org; Thu, 03 Jul 2014 04:40:17 -0400 Original-Received: from [93.82.79.129] ([93.82.79.129]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lg1QN-1WIrPX1V19-00pejW; Thu, 03 Jul 2014 10:40:08 +0200 In-Reply-To: <20140702200522.GB3823@acm.acm> X-Provags-ID: V03:K0:tRcsEz3FLR//yXU+VwhEKEjf4DftgI0d2/UcPIubshYXPNjKPTd raIC3lVQNIa7bWXf9yYIChjqaXilY+2VBWhsPN93Dg9yCG8P7Hvw3u4PutlGcY/zUsGJujU Gy3LHTHKgTLb9J2jzzN6VTUucu1uk7gLlqhmpHJomSzaHXb1XeZXE6wSqfQLkvL3l/2cDG9 GIhwpt+PG0T3EXfimO+Zw== 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:91137 Archived-At: > 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. To obtain a meaningful result from `scan-lists' with a negative COUNT, we have to know whether the starting point is outside a comment or string. This means that we either first have to scan from BOB till that point or have the results from a previous scan in a not yet invalidated cache anyway. Can we agree on that? Now it's possible that CC-mode for some magic reason knows that the starting point meets the requirement above. In that case the magic used should also assure that `scan-lists' stops at a reasonable position (one known to have DEPTH zero when scanned from BOB) by narrowing the buffer appropriately. Otherwise we need some heuristics to provide a reasonable amount of defun starters to be eventually used by back_comment (I suppose it's that routine causing our problems). In any case, these starters must be provided by `parse-partial-sexp' (or forward_sexp as you suggest). I suppose we agree on that. In any case the question is why any defun starters cached before invoking `scan-lists' would be invalid. I can't see a good reason. Can you give me one?. >> 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. It's a waste that two subsequent `scan-lists' would not share the same cache but let's stay with this assumption for the rest. > 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. Then we have to flush its cache when calling `scan-lists'. > 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). I was thinking of one cache per buffer that would be produced by parsing from BOB. A second cache would mean to double the overhead for writing and maintaining the respective code. > 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. Which obviously means that we'd have to improve the robustness of the syntax-ppss cache. >> 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. OK >> 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. OK >> (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. Then we have to provide a C-level interface to that cache which can be used by find_defun_start. >> (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. This means that we'd have to specify which defun starts to store in that cache and replace the `open-paren-in-column-0-is-defun-start' stuff in find_defun_start by going to the last position stored in that cache. The latter should be trivial but is certainly not suited for Emacs 24.4. The former is less trivial (IMHO) and requires a general solution within the context of `syntax-ppss' which might even mean to move the cache building and flushing parts of the latter to C. martin