From: Daniel Colascione <dan.colascione@gmail.com>
To: emacs-devel@gnu.org
Subject: Better parse-partial-sexp; multiple major modes (was: Idea for syntax-ppss)
Date: Sun, 31 Aug 2008 04:37:53 -0400 [thread overview]
Message-ID: <CD8754BE-CF3A-4339-8291-1D8DE10B6610@gmail.com> (raw)
In-Reply-To: <20080727145058.GA1598@muc.de>
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?
next prev parent reply other threads:[~2008-08-31 8:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-26 21:44 Idea for syntax-ppss. Is it new? Could it be any good? Alan Mackenzie
2008-07-27 0:36 ` Lennart Borgman (gmail)
2008-07-27 1:34 ` Stefan Monnier
2008-07-27 14:50 ` Alan Mackenzie
2008-07-27 15:51 ` Stefan Monnier
2008-07-27 19:20 ` Alan Mackenzie
2008-07-27 20:17 ` Stefan Monnier
2008-07-28 2:27 ` Richard M Stallman
2008-07-28 4:08 ` Stefan Monnier
2008-07-28 21:47 ` Richard M Stallman
2008-08-31 8:37 ` Daniel Colascione [this message]
2008-08-31 15:02 ` Better parse-partial-sexp; multiple major modes Lennart Borgman (gmail)
2008-09-01 6:10 ` Better parse-partial-sexp; multiple major modes (was: Idea for syntax-ppss) Richard M. Stallman
-- strict thread matches above, loose matches on Subject: below --
2008-08-31 9:39 Daniel Colascione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CD8754BE-CF3A-4339-8291-1D8DE10B6610@gmail.com \
--to=dan.colascione@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).