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: Mon, 30 Jun 2014 09:55:02 +0200 Message-ID: <53B117D6.1050306__7893.28965261138$1404114999$gmane$org@gmx.at> 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> <20140629174953.GE2948@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 1404114999 19362 80.91.229.3 (30 Jun 2014 07:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Jun 2014 07:56:39 +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 Mon Jun 30 09:56: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 1X1WRx-00043P-BI for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jun 2014 09:56:29 +0200 Original-Received: from localhost ([::1]:60984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1WRw-00009p-Jx for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jun 2014 03:56:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1WRm-00009c-FW for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 03:56:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1WRe-0004Yw-VW for bug-gnu-emacs@gnu.org; Mon, 30 Jun 2014 03:56:18 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1WRW-0004YF-VG; Mon, 30 Jun 2014 03:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X1WRW-0005HE-I3; Mon, 30 Jun 2014 03:56:02 -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: Mon, 30 Jun 2014 07:56: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.140411492320215 (code D ref 16526); Mon, 30 Jun 2014 07:56:02 +0000 Original-Received: (at 16526-done) by debbugs.gnu.org; 30 Jun 2014 07:55:23 +0000 Original-Received: from localhost ([127.0.0.1]:37390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1WQs-0005Fy-RK for submit@debbugs.gnu.org; Mon, 30 Jun 2014 03:55:23 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:62448) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1WQo-0005Fh-8S for 16526-done@debbugs.gnu.org; Mon, 30 Jun 2014 03:55:19 -0400 Original-Received: from [93.82.12.246] ([93.82.12.246]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGip3-1Wo42G1x1F-00DXIX; Mon, 30 Jun 2014 09:55:10 +0200 In-Reply-To: <20140629174953.GE2948@acm.acm> X-Provags-ID: V03:K0:3+8Eyf4Pr+z2B1oGoQDXq+i5R2Qp7fyEupCApu5dKH9kTqDWgWy ctD4a4nSrHQM+y/KSh8xgdar/8eWJaqnaPjiUet+oM04D4lnC/BoFhrI1P5ihpsh5pq/2o/ Az2PCrcJ5SPv8fiOxskn+Kwjw2g2wKUJAOif1yar4r/WY0L1efxLaJoytddVFJ2kJJ7EKGX vC/2Sjk8ripI0w5A8L7jg== 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:90995 Archived-At: >> 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. >> > 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. I meant that if someone is going to disable `before-change-functions' that someone has to take care of flushing the cache. > 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? > 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. >> 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. > 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? > 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. > 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. 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'. (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'. (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. martin