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: Idea for syntax-ppss. Is it new? Could it be any good? Date: Sun, 27 Jul 2008 16:17:20 -0400 Message-ID: References: <20080726214429.GB3623@muc.de> <20080727145058.GA1598@muc.de> <20080727192045.GB1598@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217190117 8877 80.91.229.12 (27 Jul 2008 20:21:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jul 2008 20:21:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 27 22:22:46 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KNClI-0005sh-S8 for ged-emacs-devel@m.gmane.org; Sun, 27 Jul 2008 22:22:37 +0200 Original-Received: from localhost ([127.0.0.1]:45694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNCkO-0002Pb-Rl for ged-emacs-devel@m.gmane.org; Sun, 27 Jul 2008 16:21:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNCgG-0004LI-9z for emacs-devel@gnu.org; Sun, 27 Jul 2008 16:17:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNCgF-0004Je-Av for emacs-devel@gnu.org; Sun, 27 Jul 2008 16:17:23 -0400 Original-Received: from [199.232.76.173] (port=56133 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNCgF-0004JK-3V for emacs-devel@gnu.org; Sun, 27 Jul 2008 16:17:23 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:54046) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNCgF-0002pn-3v for emacs-devel@gnu.org; Sun, 27 Jul 2008 16:17:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAOtzjEhFxIYw/2dsb2JhbACBW4k+oUyBdA X-IronPort-AV: E=Sophos;i="4.31,260,1215403200"; d="scan'208";a="24862069" Original-Received: from 69-196-134-48.dsl.teksavvy.com (HELO pastel.home) ([69.196.134.48]) by ironport2-out.teksavvy.com with ESMTP; 27 Jul 2008 16:17:21 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 431667FE3; Sun, 27 Jul 2008 16:17:20 -0400 (EDT) In-Reply-To: <20080727192045.GB1598@muc.de> (Alan Mackenzie's message of "Sun, 27 Jul 2008 19:20:45 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:101590 Archived-At: >> When I wrote syntax-ppss, my main goal was to never be significantly >> slower than parse-partial-sexp. Even if it's not as fast as it could >> be if written in C (which is pretty much obviously true), that's not a >> reason to recode it in C. > Surely the goal should be to be significantly faster most of the time. Of course, but that's the easy part. > Presumably it achieves this in practice. The reason to recode in C > would be to make it fast enough, or to couple it up to things which > couldn't be done in lisp. But probably neither of these things is > needed. I may prove necessary to reimplement it in C at some point, but for now I haven't found any need for it. >> That can be done, tho it needs extra info in order to know how to >> interpret the fact that it's narrowed. > Don't understand. The function is defined as the equivalent of > (parse-partial-sexp (point-min) pos)? You've said before that the > function is best not called when a buffer is narrowed. Couldn't we just > redefine it as (parse-partial-sexp 1 pos)? Then we could just put > (save-extension (widen ..... )) into syntax-ppss. We need the equivalent of font-lock-dont-widen for cases such a Rmail or Info. Probably this could be considered as a special case of multi-mode buffers. >> I think this will result in too many cache flushes and will make the >> code too intrusive or too ad-hoc. I'd rather have a >> syntax-ppss-syntax-table (and force parse-sexp-lookup-properties to t) >> if you want more reliable results. > Hey, syntax-ppss-syntax-table is a brilliant idea! In its doc string one > could say "after setting this, clear the cache by calling ... > (syntax-ppss-flush-cache 1)". Tho, it'd then make sense to let (syntax-ppss-flush-cache) do the job, so as to avoid the need to hardcode this ugly 1. [ Note: my own buffers all start at position 12345678. ] > No. I think I've been scared by its vagueness (about narrowed regions) > more than anything. It's defined in the elisp manual as equivalent to > (pps (point-min) pos) rather than (pps 1 pos). It also uses > syntax-begin-function, which doesn't seem right, and wouldn't work well > in CC Mode; the only way s-b-f can give a cast-iron result is by calling > parse-partial-sexp, or syntax-ppss. In fact, if syntax-ppss was > bulletproof, syntax-begin-function would be redundant. Note that it's default value is nil. I.e. it's only provided for those cases where the major mode can provide the info more cheaply than by running parse-partial-sexp. > Maybe I should test syntax-ppss by coding up inside a macro which > widens. And I've been less than convinced it's actually faster. In > fact, I'll go and do some speed tests and report back. I'm sure you can come up with tests where it's consistently slower than . The specific use I had in mind of syntax-ppss is when you call it very freely, even several times within the same command in nearby locations. And as mentioned, it mostly tries to avoid pathological behaviors rather than trying to get the very best possible speed in "the usual case". Also the question is not "is it faster", but "is it fast enough". Stefan