From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Idea for syntax-ppss. Is it new? Could it be any good? Date: Sun, 27 Jul 2008 14:50:58 +0000 Message-ID: <20080727145058.GA1598@muc.de> References: <20080726214429.GB3623@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217170372 19160 80.91.229.12 (27 Jul 2008 14:52:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jul 2008 14:52:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 27 16:53:40 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 1KN7cx-0005Ro-Dl for ged-emacs-devel@m.gmane.org; Sun, 27 Jul 2008 16:53:39 +0200 Original-Received: from localhost ([127.0.0.1]:48192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KN7c3-00060L-IJ for ged-emacs-devel@m.gmane.org; Sun, 27 Jul 2008 10:52:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KN7bj-0005oh-2p for emacs-devel@gnu.org; Sun, 27 Jul 2008 10:52:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KN7bh-0005nT-Kk for emacs-devel@gnu.org; Sun, 27 Jul 2008 10:52:21 -0400 Original-Received: from [199.232.76.173] (port=60209 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KN7bh-0005n7-AL for emacs-devel@gnu.org; Sun, 27 Jul 2008 10:52:21 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:3998 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KN7bg-0007x6-NN for emacs-devel@gnu.org; Sun, 27 Jul 2008 10:52:21 -0400 Original-Received: (qmail 40621 invoked by uid 3782); 27 Jul 2008 14:50:46 -0000 Original-Received: from acm.muc.de (pD9E53EF9.dip.t-dialin.net [217.229.62.249]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sun, 27 Jul 2008 16:50:42 +0200 Original-Received: (qmail 4040 invoked by uid 1000); 27 Jul 2008 14:50:58 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:101579 Archived-At: Hi, Stefan! On Sat, Jul 26, 2008 at 09:34:45PM -0400, Stefan Monnier wrote: > > How about reimplementing it thusly?: The current syntax would be cached > > for positions at every N bytes (where N would be, perhaps 1024, possibly > > 8192). A call to syntax-ppss would simply call parse-partial-sexp from > > the latest valid cached position, filling out the cache as it goes. Any > > buffer change would invalidate cached values for N > POS. > Isn't that what syntax-ppss does? It caches the state for several positions, but I don't think they're at regular positions. I don't understand the detailed workings of the routine at the moment. I suspect that the slowness of all the lisp manipulation will outweigh the benefit of the caching, but I would confirm or refute that with the profiler before doing anything serious. partial-parse-sexp is blindingly fast. To scan an entire 3Mb C buffer on my elderly 1.2 GHz Athlon takes 0.27s. That is why I suspect that the lisping in syntax-ppss might need severe optimisation. But again, it's only a hunch. What I think really needs doing is to make this function bulletproof: It should work on narrowed buffers, it should give reliable elements 2 and 6, its cache should be cleared when functions like `modify-syntax-entry' are called or parse-sexp-lookup-properties is changed, and the cache should be bound to nil on `with-syntax-table'. I actually think it could be useful to maintain several parallel caches, each for a different syntax-table (or an equivalence class of syntax tables). And so on. Basically, I would like `(syntax-ppss)' to tell me with 100% reliability, no ifs, no buts, whether I am at top-level, in a comment, or in a string. Also, Lennart is asking for it to work nicely with multiple major modes. Surely this would be a Good Thing. Files containing several major modes are commonplace (awk or sed embedded within a shell script, html embedded within php, ....). At the moment, CC Mode applies a heuristic maximum size of strings and comments, for performance reasons. Checking for strings and comments is done so frequently that the mode uses elaborate internal caches. It would be nice if this cacheing could move to the Emacs core. Again, this isn't something which can be implemented in a weekend, but I think it would be worthwhile for Emacs 24. > Stefan -- Alan Mackenzie (Nuremberg, Germany).