From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Better parse-partial-sexp; multiple major modes (was: Idea for syntax-ppss) Date: Sun, 31 Aug 2008 04:37:53 -0400 Message-ID: References: <20080726214429.GB3623@muc.de> <20080727145058.GA1598@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v926) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220189600 9381 80.91.229.12 (31 Aug 2008 13:33:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2008 13:33:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 15:34:14 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 1KZn4H-0003WM-9E for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 15:34:13 +0200 Original-Received: from localhost ([127.0.0.1]:44152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZn3I-0003Ba-GS for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 09:33:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZiRd-0007Ch-47 for emacs-devel@gnu.org; Sun, 31 Aug 2008 04:38:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZiRb-0007BF-PJ for emacs-devel@gnu.org; Sun, 31 Aug 2008 04:38:00 -0400 Original-Received: from [199.232.76.173] (port=58992 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZiRb-0007Az-7P for emacs-devel@gnu.org; Sun, 31 Aug 2008 04:37:59 -0400 Original-Received: from yx-out-1718.google.com ([74.125.44.155]:9625) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZiRa-0000Co-QH for emacs-devel@gnu.org; Sun, 31 Aug 2008 04:37:59 -0400 Original-Received: by yx-out-1718.google.com with SMTP id 34so740370yxf.66 for ; Sun, 31 Aug 2008 01:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=PX0KaNfhowXmjgw+52Gc8CmxXxccxhuBArUnlrb6fsk=; b=vpM0BXH11UgxdhGQRgRo4USxp0q9YampS3l+xT58FY7AAM1eXY3/1GMzEU9fiPNTkP NoqZ1neIA+VCblE4DlDbJGx9Urr7CNa0kLJfjbZTu4/YXholAS9CDHdYjAJXCsVZcKeT LnpmI2ra1AwZkTDLroYZ9IBSaqE7vva1ldihY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Mif/9fvlE8DZ7tmk0iFksFuk39MGyL3iMAbw2QPkG761GaaRqFr/vUoejDqzvryR4h m8QUFygql8c3hDqZVbgFqc+Q/Q/xETaj0XSWY1CGK+9pQwkC0FW45Rcphy1qnBiuwNRa yQm4nz3OQGkLn5ekqHbs2K53rJYHC9idiIOA8= Original-Received: by 10.151.13.7 with SMTP id q7mr6859315ybi.52.1220171877168; Sun, 31 Aug 2008 01:37:57 -0700 (PDT) Original-Received: from ?192.168.1.103? ( [76.180.38.217]) by mx.google.com with ESMTPS id 9sm5551847yws.5.2008.08.31.01.37.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Aug 2008 01:37:56 -0700 (PDT) In-Reply-To: <20080727145058.GA1598@muc.de> X-Mailer: Apple Mail (2.926) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-Mailman-Approved-At: Sun, 31 Aug 2008 09:31:57 -0400 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:103315 Archived-At: On Jul 27, 2008, at 10:50 AM, Alan Mackenzie wrote: > 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. Surely, such a creature would have to live on the C side of things, if only for practical reasons. (With the proliferation of with-this and inhibit-that options available to Lisp, I don't see how one can easily and robustly catch all buffer modification. Not to mention that no matter which of before-change-functions and after-change-functions you used, you could still race against other functions using the same facility.) If this perfectly caching parse-partial-sexp lives in C anyway, why not just call it parse-partial-sexp? Optimize parse-partial-sexp for the case of start being 1 or (point-min). syntax-ppss becomes a simple wrapper. Not only would it be possible to robustly catch all buffer and context modification, but by optimizing the existing function, all existing users would automatically win. I'd offer to write a patch, but I don't know the core well enough to know how to "easily and robustly catch all buffer modification". > > 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, ....). After several attempts at using and understanding multiple major mode facilities, I'm convinced the only way forward is core support for the concept. Lennart's done a fine job with what's in Emacs currently. But anything involving multiple major modes today is a quivering mound of hacks. All the work Lennart's had to do to get modes playing nice with each other is a testament to that. Maybe a core solution could be something like this: in a given buffer, each character has a chunk-name character property. You'd buffer- locally map chunk names to major modes. For each chunk name, create a buffer containing just the text assigned to that chunk. Make the major- mode the major mode for the chunk buffer, and let that major-mode handle fontification, keybindings, and so on. In the main buffer, assemble the various bits from the chunk-buffers and allow the user to navigate the combined buffer normally. Keybindings with point at a particular character would just be the keybindings present in that character's chunk-buffer. If you need special keybindings common across all chunk buffers, just bind the key in all the chunk buffers. If a given chunk needs placeholder text to represent text of some other chunk, it should be possible add it to that chunk buffer without affecting any of the others. Anyway, this scheme is: 1) Robust - no messing around with variables, no tweaking fontification 2) Backwards compatible - a major-mode doesn't need to know it's being used this way 3) Versatile - you can compose arbitrary modes this way, even recursively 4) Conceptually simple (I hope) Any thoughts?