[Top][All Lists]

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

Re: AW: font-locking and open parens in column 0

From: Richard Stallman
Subject: Re: AW: font-locking and open parens in column 0
Date: Sun, 12 Nov 2006 00:14:52 -0500

    4 - the original motivation for the patch (i.e. point 1 above) is better
        addressed by not using beginning-of-defun and rely on syntax-ppss's
        cache instead.

The specific purpose of the change in beginning-of-defun-raw was simply to make
it correctly handle the case of open-paren-in-column-0-is-defun-start = nil
when there is no beginning-of-defun-function.

I know this discussion is part of a larger one, but I no longer
remember the rest of the issues in the larger discussion.

However, I did not realize that CC mode actually used that case.  I
thought it had a beginning-of-defun-function.  I was surprised just
now to see that it didn't have one.  Perhaps that should be changed.

However, taking out the use of syntax-ppss in beginning-of-defun-raw
isn't the right way to get good behavior in CC mode.  That would only
make it parse from the start of the file every time.

    3 - changing beginning-of-defun to use parse-partial-sexp (or worse
        syntax-ppss) defeats the purpose of using it as a syntax-begin-function.
        It may even break such uses (e.g. in emacs-lisp-mode).

Why would it break them?

(In any case, such a problem won't arise in Emacs Lisp mode, since
open-paren-in-column-0-is-defun-start = t.)

    I think the problem is that beginning-of-defun has many different possible
    uses, not all of which are compatible:

    1 - it can be used as a "move to toplevel" (i.e. outside of any syntactic
        element).  Currently it's a not reliable way to do that, but it's been
        used as a good heuristic.  Note that in some languages such a concept
        may not even be very meaningful: in languages whose files are commonly
        composed of only one toplevel element (typically a module or a class
        which then contains other elements inside themselves maybe classes or
        modules, ...).

    2 - it can be used as a form of "backward-paragraph-for-prog-langs", to move
        to the beginning of a "block of text".  In case where defuns can be
        nested, this first only move to the beginning of the nested defun.

Normally I'd expect it NOT to treat nested definitions as defuns.
Normally they would be entirely indented.

    3 - a mix of the two: define some level of nesting (if any) as the main one
       (typically either the toplevel one, or if the toplevel is a single
       element, use the next level down) and move to the beginning of the defun
       at that level.

You can get this behavior by adjusting the indentation
when open-paren-in-column-0-is-defun-start = t.

    A reliable way to get behavior 1 is to use syntax-ppss rather than

That is a good point.  Maybe some uses of beginning-of-defun
(such as in Font Lock) ought to use syntax-ppss instead.

I think that is orthogonal to the question of this change
in beginning-of-defun-raw.

    The proposed patch basically tries to make beginning-of-defun follow the
    behavior number 1 and to make it do so reliably.

I don't see it that way.

    OTOH it might be a good idea indeed to change beginning-of-defun so that it
    ignores regexp-matches if they're inside comments or strings.  But that'd be
    a different patch, which would apply regardless of

I agree, that might be good.

reply via email to

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