From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: generic buffer parsing cache data Date: Sun, 01 Jul 2007 17:20:29 +0200 Message-ID: <4687C63D.6020401@gmx.at> References: <200707010038.23072.pogonyshev@gmx.net> <200707011516.31959.pogonyshev@gmx.net> <4687A040.8030808@gmx.at> <200707011641.58414.pogonyshev@gmx.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1183303241 17294 80.91.229.12 (1 Jul 2007 15:20:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2007 15:20:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Pogonyshev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 17:20:40 2007 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 1I51E7-0002eb-MS for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2007 17:20:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I51E7-00060L-5R for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2007 11:20:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I51E4-00060G-B2 for emacs-devel@gnu.org; Sun, 01 Jul 2007 11:20:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I51E2-000604-T8 for emacs-devel@gnu.org; Sun, 01 Jul 2007 11:20:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I51E2-000601-N9 for emacs-devel@gnu.org; Sun, 01 Jul 2007 11:20:34 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1I51E2-0003Ve-6d for emacs-devel@gnu.org; Sun, 01 Jul 2007 11:20:34 -0400 Original-Received: (qmail invoked by alias); 01 Jul 2007 15:20:33 -0000 Original-Received: from N882P021.adsl.highway.telekom.at (EHLO [62.47.54.53]) [62.47.54.53] by mail.gmx.net (mp054) with SMTP; 01 Jul 2007 17:20:33 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19YxNdX1A9YiMcHccdre3zoc85FeSC87Kfoagj4wa Ft/CbCqmH6ZJ6i User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <200707011641.58414.pogonyshev@gmx.net> X-Y-GMX-Trusted: 0 X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:74113 Archived-At: > It is unclear whether changes in any text properties should lead to cache > invalidation. Probably no, at least by default. Maybe for changes in syntax-table text properties. > It also makes sense to define some `anchors'. Those would be ways of > partitioning buffers into parts, where changes in one part don't cause > invalidation of cache data in other parts. For instance, in Python mode > anchors would be set wherever a toplevel block is defined, since it stops > parsing on reaching a toplevel anyway. However, this can be added later. > For instance, it is not clear when and how to remove anchors. (I.e. in > Python mode if toplevel is indented to another level, it should stop > being an anchor.) An open-paren-in-column-0 would be such an anchor in many modes. > It is required that major mode stores cache data at some logical position, > so it can later find them again. Maybe it also makes sense to add > > Function: find-cache-data key &optional pos > > Find and return cache data at POS (or point position) or _before > it_. Return nil if there is no (valid) cached data at pos or > anywhere before with that KEY. The classic method based on the entire information to get out of a nested block. > However, I don't see any obvious ways of using it. As I can see, modes > should access cache data like this (in pseudocode): > > mode-get-cache-data: > data = (get-cache-data mode-key) > if data is nil: > data = (mode-compute-cache-data) > (put-cache-data mode-key data) > return data > > mode-compute-cache-data: > save-excursion: > travel-to-higher-level-cache-point > higher-level-data = (mode-get-cache-data) > data = (mode-compute-data-from-higher-level higher-level-data) > return data > > Here `higher-level' is not the same as `previous'. For instance, in > Python mode it makes sense to compute indentation from the block this one > is nested in, not just previous block: > > class X: > class Y: # <-- higher-level block for the current block > class Z: > def bla (): # <-- previos block (with cached data) > pass > def __init__(self): # <-- current block > pass I don't see why it should be difficult to keep the entire necessary information at "bla". After all you'd avoid to compute your data from "class Y". Moreover in other contexts it's not clear whether a thing like "class Y" does constitute a "higher-level" block than the current one. Anyway, I understand that you want some routines for cache management where the major (or minor) mode would fill in the necessary information itself. I don't see any problems adding such functionality to `syntax-ppss' as Stefan suggested.