[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: Chong Yidong
Subject: Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.
Date: Thu, 14 Dec 2006 17:51:58 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

Alan Mackenzie <address@hidden> writes:

> What problems do you see with open-paren-in-column-0-is-defun-start
> having the default 'mode?

None---if the default behavior from setting this to 'mode is the
behavior before the beginning-of-defun-raw changes, i.e. M-> is
instantaneous for xdisp.c.  If the default behavior is the current
slowness, then this change alone doesn't solve anything.

> Well, xdisp.c is a massive file, not a moderately big one, and I
> wouldn't find the slowness unacceptable, though that's obviously a
> personal thing.  If it were 15 seconds rather than 4, I would freak out
> like you're doing now.  I would find massive misfontification (as
> happened in syntax.c, the bug for which the pertinent patch is a repair)
> totally unacceptable.

As has been pointed out, the font-lock limitations have existed for
years.  If you want to introduce a change that has been known to cause
problems for people (and please don't try to downplay these
problems---4 seconds is a long time for an interactive command), when
Emacs is in *pretest*, it makes sense to leave that change turned off
by default.

> Another possibility would be a variable like this in place of opic0ids:
> (defvar threshold-ppss-bod 200000
>   "The buffer size above which a paren in column0 will signal a defun start.
> Below this size, a paren at the top level signals a defun start.
> If this variable is nil, a paren at top level is always used.  If t, a
> paren in column 0 is always used.")
> What do you think?

Given the fact that Emacs is in pretest, changes to the Emacs core
should be discouraged if a more self-contained change can be used in
its place.  Since no one has described this bug as occurring outside
C-mode, we should postphone such changes till after the release.

That is why I think C-mode should introduce its own
beginning-of-defun-function, which can employ the buffer-size
threshold you described.  That change I can agree with.

reply via email to

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