[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mysterious fontification/C++ context issue - Patch for beginning-of-

From: Richard Stallman
Subject: Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.
Date: Fri, 15 Dec 2006 00:03:16 -0500

I have now read the messages about this which arrived in the past week
or two, and checked the code again.

Basically, we have three different things in Emacs that
need to find, more or less, "the start of this defun".

* beginning-of-defun-raw.

* syntax.el

* find_defun_start in syntax.c

There are different features for customizing each of these three.
This is a very confusing situation.

The change I asked for, to make open-paren-in-column-0-is-defun-start
affect beginning-of-defun-raw, causes a major slowness.  4 seconds for
M-> is too painful.  So now I think that change should be undone.  But
just undoing it won't make everything ok.

The name open-paren-in-column-0-is-defun-start implies to me
that this variable ought to affect beginning-of-defun-raw.
After all, that command finds a defun start.

So if we make that variable apply only to syntax.c, as it used to,
perhaps we should rename it to open-paren-in-column-0-is-outer-level.

However, that name suggests that syntax.el ought to obey it too.

That makes me wonder whether find_defun_start should use
syntax-begin-function.  Does that work right?  If so, we could
eliminate open-paren-in-column-0-is-defun-start.  Stefan suggested
something similar: making back_comment use syntax-ppss.

How hard is that to implement?

Stefan also suggested we arrange another better way to
customize beginning-of-defun (and the parts of Font Lock that
highlight things that look like beginnings of defuns).

With those two changes, open-paren-in-column-0-is-defun-start
could be eliminated.

As for fixing the misfontifications of C mode, David Kastrup wrote:

    The large slowdown most likely would not be necessary if information
    was reused intelligently and not scanned repeatedly.  That requires a
    good analysis and careful implementation/reimplementation.

I agree with him that that is worth trying, but only after the

A different but related question:

Should C mode do (setq beginning-of-defun-function 'c-beginning-of-defun)
Is there any reason that would be bad?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]