From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Idea for syntax-ppss. Is it new? Could it be any good?
Date: Sun, 27 Jul 2008 16:17:20 -0400 [thread overview]
Message-ID: <jwvvdyr2kau.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20080727192045.GB1598@muc.de> (Alan Mackenzie's message of "Sun, 27 Jul 2008 19:20:45 +0000")
>> 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
<writeyouralternativehere>. 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
next prev parent reply other threads:[~2008-07-27 20:17 UTC|newest]
Thread overview: 13+ 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 [this message]
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 ` Better parse-partial-sexp; multiple major modes (was: Idea for syntax-ppss) Daniel Colascione
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvvdyr2kau.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.