unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: martin rudalics <rudalics@gmx.at>,
	emacs-devel@gnu.org, Richard Stallman <rms@gnu.org>,
	Alan Mackenzie <acm@muc.de>
Subject: Re: font-locking and open parens in column 0
Date: Fri, 03 Nov 2006 14:29:15 -0500	[thread overview]
Message-ID: <jwvodro8hy7.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <DA6197CAE190A847B662079EF7631C0603407A8B@OEKAW2EXVS03.hbi.ad.harman.com> (Alan Mackenzie's message of "Fri\, 3 Nov 2006 17\:19\:18 +0100")

> CC Mode always sets o-p-i-c-0-i-d-start to nil, and caches the brace
> structure to prevent excessive scanning from BOB.

Interestingly, it may not be sufficient.  There are basically only 2 uses of
open-paren-in-column-0-is-defun-start in Emacs:
- one in lisp.el to define beginning-of-defun (in order to know whether to
  add "^" to defun-prompt-regexp).
- one in syntax.c used in forward-comment when scanning comments backward.

beginning-of-defun has always been based on regexps and not on syntax, so
open-paren-in-column-0-is-defun-start in there has no significant impact
w.r.t. scanning from the beginning of the buffer or not: you can change
defun-prompt-regexp instead and get the same result.

OTOH in forward-comment it's used within C code with no way to hook
into it.  So the paren cache you use has no effect on this :-(
It's on my TODO list to change forward-comment so that it calls syntax-ppss
when needed rather than scan from the beginning of the defun/buffer.

> After all, opic0id being nil will always find BO-defun.  Setting it to
> t was an optimisation for when computers were much less powerful than they
> are now - and this causes quite a bit of inconvenience.

It's an algorithmic optimization, and since in computer science, problems
tend to get bigger as we get bigger machines, it's not clear that the
optimization is less useful now than it was then.  I do believe it is less
useful because we're lucky enough that our "problems" haven't gotten much
bigger: source code size is limited by human constraints more than by the
machine (except for computer-generated code, obviously), and we haven't
noticeably complexified our parsing technology (contrary to many other
programming environments).

>> ... which parallels the work of `syntax-ppss', hence we currently end up
>> with two caches for the same structures - I know c-mode has to work hard
>> to handle all sorts of older (X)Emacsen ...
> Not only that, CC Mode uses its cache for things other than font-locking.

syntax-ppss is used by font-lock but not only.  Whether you could use it for
the other places where you use your cache?  I don't know.  I hope so.
But if you can't I'd be interested to hear about it (mostly to figure out
in which direction syntax-ppss should be improved).

> Should _HAVE_ been warned.  Martin Stjernholm has worked very hard to
> remove that restriction from C Mode without sacrificing (much) speed.  It
> would be a shame now to leave the restriction in Emacs 22.

In that case, I believe a better patch than the one you proposed is to
change cc-fonts.el so as to set syntax-begin-function to nil.  After all,
the whole point of syntax-begin-function is to provide a *heuristic* that
can "quickly" find a safe starting point for parsing.  If you want your
parsing to be more reliable than a heuristic, then just don't use that.


        Stefan

  reply	other threads:[~2006-11-03 19:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-03 16:19 font-locking and open parens in column 0 Mackenzie, Alan
2006-11-03 19:29 ` Stefan Monnier [this message]
2006-11-04 11:35   ` martin rudalics
2006-11-04  9:30 ` martin rudalics
2006-11-05  7:08 ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2006-11-03  8:44 AW: " Mackenzie, Alan
2006-11-03 14:14 ` Stefan Monnier
2006-11-02  8:49 Mackenzie, Alan
2006-11-02 18:31 ` martin rudalics

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=jwvodro8hy7.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    --cc=rudalics@gmx.at \
    /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).