[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mysterious fontification/C++ context issue
From: |
Alan Mackenzie |
Subject: |
Re: Mysterious fontification/C++ context issue |
Date: |
10 Dec 2006 11:56:21 +0100 |
Date: |
Sun, 10 Dec 2006 12:06:36 +0000 |
User-agent: |
Mutt/1.5.9i |
Hi, Richard, hi, Martin!
On Sat, Dec 09, 2006 at 11:24:54PM -0500, Richard Stallman wrote:
> > 2. That a user's idea of "defun" for her programming
> > language does not necessarily coincide with that of
> > `beginning-of-defun'.
> >
> > The major mode is supposed to try to make them correspond. It
> > seems strange to assume that it doesn't succeed.
beginning-of-defun unfortunately conflates (i) "beginning of a function" and
(ii) "outermost level of parens", this arising because they coincide in
the most important language (Lisp). Having
"beginning-of-defun-function" makes things even worse.
Typically, b-o-d (sense (i)) is going to be calling
foo-beginning-of-defun (the value of b-o-d-function) which is going to
be recursively calling beginning-of-defun (sense (ii)), getting one's
knickers horribly twisted.
Maybe, for Emacs 23, we could disentangle these things.
> If it really succeeded why should C mode ever bother to provide
> its own `c-beginning-of-defun'?
c-beginning-of-defun puts point at the beginning of the C function, i.e.
at the "int" in the following, regardless of whether the brace is hung
or at column 0:
int foo (bar)
{
....
}
> Maybe C mode should arrange to use `c-beginning-of-defun'
> as the beginning-of-definition-function. Is there a reason why
> this would give bad results?
Yes.
You mean syntax-begin-function? c-beginning-of-defun is a user level
function, and it's slow. About 90% of its runtime is spent determining
where point is initially (inside a defun / inside "int foo (bar)" / at
"int foo (bar)"/ ... ) and finally moving from the open brace to the
"int". Only ~10% is used in finding the outermost open brace, which is
all that's needed for font-locking and so on.
> > Anyway, this is not the right place to discuss what happens in
> > specific modes.
> The current change affects the behavior of `beginning-of-defun' which
> may affect other modes as well.
> Yes, if they set `open-paren-in-column-0-is-defun-start' to t.
You mean setting it to nil. ;-)
The behaviour of beginning-of-defun has been changed ONLY for when
opic0ids gets set to nil. The only other file.el within Emacs which
does this is progmodes/python.el. Any Python users here? Dave Love,
are you listening?
There is also this baffling comment in net/tramp.el:
;; Fontification is messed up when
;; `open-paren-in-column-0-is-defun-start' set to t.
--
Alan Mackenzie (Ittersbach, Germany)
Re: Mysterious fontification/C++ context issue, Richard Stallman, 2006/12/06
- Re: Mysterious fontification/C++ context issue, martin rudalics, 2006/12/06
- Re: Mysterious fontification/C++ context issue, Richard Stallman, 2006/12/08
- Re: Mysterious fontification/C++ context issue, martin rudalics, 2006/12/09
- Re: Mysterious fontification/C++ context issue, Richard Stallman, 2006/12/09
- Re: Mysterious fontification/C++ context issue, martin rudalics, 2006/12/10
- Re: Mysterious fontification/C++ context issue,
Alan Mackenzie <=
- Re: Mysterious fontification/C++ context issue, martin rudalics, 2006/12/10
- Re: Mysterious fontification/C++ context issue, Slawomir Nowaczyk, 2006/12/10
Re: Mysterious fontification/C++ context issue, Stefan Monnier, 2006/12/10
Re: Mysterious fontification/C++ context issue, Alan Mackenzie, 2006/12/06