From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'. Date: Tue, 08 Mar 2016 19:17:17 -0500 Message-ID: References: <20160308132530.861.91488@vcs.savannah.gnu.org> <20160308183010.GB6269@acm.fritz.box> <20160308200753.GC6269@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1457482661 21897 80.91.229.3 (9 Mar 2016 00:17:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2016 00:17:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 09 01:17:33 2016 Return-path: Envelope-to: ged-emacs-devel@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 1adRoi-0002dj-UQ for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 01:17:33 +0100 Original-Received: from localhost ([::1]:38149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adRoh-0004MZ-Tu for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 19:17:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adRoc-0004Ji-8k for emacs-devel@gnu.org; Tue, 08 Mar 2016 19:17:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adRoX-0005Tc-6n for emacs-devel@gnu.org; Tue, 08 Mar 2016 19:17:26 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:53746) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adRoX-0005SC-1S for emacs-devel@gnu.org; Tue, 08 Mar 2016 19:17:21 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.DIT.UMontreal.CA (8.14.1/8.14.1) with ESMTP id u290HdYA031110; Tue, 8 Mar 2016 19:17:40 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id D96AAAE099; Tue, 8 Mar 2016 19:17:17 -0500 (EST) In-Reply-To: <20160308200753.GC6269@acm.fritz.box> (Alan Mackenzie's message of "Tue, 8 Mar 2016 20:07:53 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5604=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5604> : inlines <4463> : streams <1599858> : uri <2161447> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201223 Archived-At: > syntax-ppss is a lisp level thing, rather loosely defined. No, it's pretty precisely defined: it (should) returns the same value as (parse-partial-sexp (point-min) pos). > For example it reacts to the setting/clearing of the particular > syntax-table text properties it's sensitive to, even when > inhibit-modification-hooks is non-nil (which it _always_ is when text > properties are changed). `syntax-ppss' is used all over the place, so if there's a problem with it, we should fix it. >> > That a high class editor such as Emacs should have >> > problems with such parens is ludicrous and unacceptable. >> FWIW, I (setq open-paren-in-column-0-is-defun-start nil) in my ~/.emacs. > People (e.g. Martin R.) have complained that this makes CC Mode too slow. Hmm... I found a prototype patch (not the one I was thinking about, tho) which uses syntax-ppss, see below. It appears to give correct results in my superficial testing, yet I can't notice any performance difference whether I enable it nor by changing the value of open-paren-in-column-0-is-defun-start, so I'm not sure I was testing correctly. > If I understand correctly, you work on a super fast machine, not an > ordinary PC. Not really. I did recently upgrade one of my desktops from a 1.6GHz E350 to my first >3GHz CPU, but my typical work machine is a Thinkpad T61. This said, recently I've been using sm-c-mode when editing C code, which being much less sophisticated is also faster than CC mode. > Maybe, maybe not. Special purpose things can have an austere simplicity > which their general purpose equivalents lack. Think of a high quality > screwdriver, and compare it to using the screwdriver piece of a Swiss > Army knife. While the patch below is just a proof-of-concept prototype, I can't believe it could end up anywhere nearly as complex as your current patch. So "simplicity" is a question of point of view. Stefan diff --git a/src/syntax.c b/src/syntax.c index 249d0d5..d0dfa90 100644 --- a/src/syntax.c +++ b/src/syntax.c @@ -570,9 +570,6 @@ dec_bytepos (ptrdiff_t bytepos) /* Return a defun-start position before POS and not too far before. It should be the last one before POS, or nearly the last. - When open_paren_in_column_0_is_defun_start is nonzero, - only the beginning of the buffer is treated as a defun-start. - We record the information about where the scan started and what its result was, so that another call in the same area can return the same value very quickly. @@ -597,12 +594,25 @@ find_defun_start (ptrdiff_t pos, ptrdiff_t pos_byte) && MODIFF == find_start_modiff) return find_start_value; - if (!open_paren_in_column_0_is_defun_start) + if (NILP (Vopen_paren_in_column_0_is_defun_start)) { find_start_value = BEGV; find_start_value_byte = BEGV_BYTE; goto found; } + else if (EQ (Vopen_paren_in_column_0_is_defun_start, Qsyntax_ppss)) + { + EMACS_INT modiffs = CHARS_MODIFF; + Lisp_Object ppss = call1 (Qsyntax_ppss, make_number (pos)); + if (modiffs != CHARS_MODIFF) + error ("syntax-ppss modified the buffer!"); + TEMP_SET_PT_BOTH (opoint, opoint_byte); + Lisp_Object boc = Fnth (make_number (8), ppss); + if (NUMBERP (boc)) + return XINT (boc); + else + return pos; + } /* Back up to start of line. */ scan_newline (pos, pos_byte, BEGV, BEGV_BYTE, -1, 1); @@ -863,7 +873,7 @@ back_comment (ptrdiff_t from, ptrdiff_t from_byte, ptrdiff_t stop, case Sopen: /* Assume a defun-start point is outside of strings. */ - if (open_paren_in_column_0_is_defun_start + if (EQ (Vopen_paren_in_column_0_is_defun_start, Qt) && (from == stop || (temp_byte = dec_bytepos (from_byte), FETCH_CHAR (temp_byte) == '\n'))) @@ -3647,6 +3657,7 @@ void syms_of_syntax (void) { DEFSYM (Qsyntax_table_p, "syntax-table-p"); + DEFSYM (Qsyntax_ppss, "syntax-ppss"); staticpro (&Vsyntax_code_object); @@ -3687,10 +3698,10 @@ See the info node `(elisp)Syntax Properties' for a description of the doc: /* Non-nil means `scan-sexps' treats all multibyte characters as symbol. */); multibyte_syntax_as_symbol = 0; - DEFVAR_BOOL ("open-paren-in-column-0-is-defun-start", - open_paren_in_column_0_is_defun_start, + DEFVAR_LISP ("open-paren-in-column-0-is-defun-start", + Vopen_paren_in_column_0_is_defun_start, doc: /* Non-nil means an open paren in column 0 denotes the start of a defun. */); - open_paren_in_column_0_is_defun_start = 1; + Vopen_paren_in_column_0_is_defun_start = Qsyntax_ppss; /* Qt; */ DEFVAR_LISP ("find-word-boundary-function-table",