From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ivan Andrus Newsgroups: gmane.emacs.bugs Subject: bug#15415: 24.3.50; c++-mode fontification for constructors is inconsistent Date: Fri, 18 Oct 2013 16:00:45 -0600 Message-ID: References: <160417FD-FE6F-4C7F-AEC5-CEFD09ABE113@gmail.com> <20131012204542.GA3690@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11331cb2f65a5404e90b1085 X-Trace: ger.gmane.org 1382133703 10091 80.91.229.3 (18 Oct 2013 22:01:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Oct 2013 22:01:43 +0000 (UTC) Cc: "15415@debbugs.gnu.org" <15415@debbugs.gnu.org> To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 19 00:01:46 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VXI76-0007D7-IN for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Oct 2013 00:01:44 +0200 Original-Received: from localhost ([::1]:59502 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXI76-0003nM-8r for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Oct 2013 18:01:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXI6x-0003lX-DS for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2013 18:01:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXI6n-0006HG-8g for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2013 18:01:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXI6S-0006EF-AB; Fri, 18 Oct 2013 18:01:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VXI6Q-00035F-PA; Fri, 18 Oct 2013 18:01:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ivan Andrus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 18 Oct 2013 22:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15415 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 15415-submit@debbugs.gnu.org id=B15415.138213366011844 (code B ref 15415); Fri, 18 Oct 2013 22:01:02 +0000 Original-Received: (at 15415) by debbugs.gnu.org; 18 Oct 2013 22:01:00 +0000 Original-Received: from localhost ([127.0.0.1]:57290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VXI6M-00034w-7t for submit@debbugs.gnu.org; Fri, 18 Oct 2013 18:00:59 -0400 Original-Received: from mail-pd0-f169.google.com ([209.85.192.169]:36459) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VXI6F-00034e-LW for 15415@debbugs.gnu.org; Fri, 18 Oct 2013 18:00:53 -0400 Original-Received: by mail-pd0-f169.google.com with SMTP id q10so3801213pdj.28 for <15415@debbugs.gnu.org>; Fri, 18 Oct 2013 15:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vJMjR0P+XPJIabp7mQgFC+K/FmVsXLGsEE+Dx0uBejY=; b=c6ZGuqD+FN12AARRgXE+oJfm+1o8OWUzKenLoPAEYP+Ti0r4dQfNZms+tOxce5v1ig D3FazO+pIhA7EJVyvyTPDKCn6LDf63bL3WMTEy80q0+N7zBlcDhirUA6rejWtJKZ8I6f njbJBHbyQ5i42oyJtwQ4iIqoSd92RwzP+2avY5VhFlcI7RGYjYx+gqCGn53AojdL46bg Tcxb+YO4nx7FNIPTWi0kXpl9zBt/ZLFlvwEF3E3b90TBC9/pIiHK5B/lHsOh3lj/V3oz XC8OiybJF/5RfaLRhBVOniOE7iw5OopOjseQoyMvv+szK9QitPNCBgWKCQOpR+OU35uw 3gmw== X-Received: by 10.66.140.40 with SMTP id rd8mr5517537pab.119.1382133645333; Fri, 18 Oct 2013 15:00:45 -0700 (PDT) Original-Received: by 10.70.61.195 with HTTP; Fri, 18 Oct 2013 15:00:45 -0700 (PDT) In-Reply-To: <20131012204542.GA3690@acm.acm> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79374 Archived-At: --001a11331cb2f65a5404e90b1085 Content-Type: text/plain; charset=ISO-8859-1 Oops, forgot to CC the bug. I've been using the patch for a week now and haven't noticed any ill effects. Thanks, Ivan On Sat, Oct 12, 2013 at 2:45 PM, Alan Mackenzie wrote: > Hello, Ivan. > > On Sun, Sep 29, 2013 at 09:31:13PM -0600, Ivan Andrus wrote: > > Ivan Andrus writes: > > > > Font locking of C++ constructors is somewhat inconsistent. This is > > > no doubt complicated by the fact that unlike other function > > > declarations they "don't have a return type". > > This is, indeed, problematic. > > > > When a single argument is not used but named, the constructor is not > > > fontified (normally it's fontified with > > > `font-lock-function-name-face'). If the keyword explicit is used, > > > then the argument type is fontified as a variable, and the > > > constructor name is fontified as a type. Perhaps interestingly, > > > naming the parameter or adding another parameter causes fontification > > > to work correctly (with or without explicit). > > Yes. The pertinent function, `c-forward-decl-or-cast-1', is somewhat > probablistic. If it gets sufficient clues from the context, it gets > things right, otherwise it has to guess, and sometimes will get things > wrong, particularly in C++, which doesn't have a nice context-free > syntax. > > > > I have included a sample file below with comments on what I see in > > > `emacs -q` > > > > > class Bob > > > { > > > // string is `font-lock-type-face', Bob is > `font-lock-function-name-face' > 1 > > Bob( string bob ); > > > // string and Bob are not fontified (though I sometimes see > string fontified as a type) > 2 > > Bob( string ); > > > // string is `font-lock-variable-name-face', Bob is > `font-lock-type-face' > 3 > > explicit Bob( string ); > > > // string is `font-lock-type-face', Bob is > `font-lock-function-name-face' > 4 > > explicit Bob( string, string ); > > > }; > > > In fact, it's not just constructors that have this problem. For > > example the following function declaration: > > 5 > string lookup( size_t ) const; > > > Removing const, or adding a name to the size_t parameter causes > > fontification to work correctly. > > Yes. > > Of the lines of code you've illustrated, 1 and 4 were OK. I've corrected > 3 and 5, which were relatively simple. > > 2 is a problem, because it looks like a normal function call. If the > identifier in the parentheses (here "string") can be positively > identified as a type (for example, some use elsewhere can only be a type, > or it's a standard type like "string") it gets fontified. Otherwise, > it's assumed the construct is a function call. It would no doubt be > possible to check that the enclosing braces are a class declaration, and > that "Bob" is the name of the class, but this would slow down the > fontification, probably by a lot. > > Would you please try out the patch below, and let me know how it goes. > It is based on the current source in the bzr trunk. > > Again, thanks for such a crisp and concise bug report. > > > > === modified file 'lisp/progmodes/cc-engine.el' > *** lisp/progmodes/cc-engine.el 2013-09-28 17:17:01 +0000 > --- lisp/progmodes/cc-engine.el 2013-10-12 20:18:26 +0000 > *************** > *** 6917,6923 **** > ;; can happen since we don't know if > ;; `c-restricted-<>-arglists' will be correct inside the > ;; arglist paren that gets entered. > ! c-parse-and-markup-<>-arglists) > > (goto-char id-start) > > --- 6917,6925 ---- > ;; can happen since we don't know if > ;; `c-restricted-<>-arglists' will be correct inside the > ;; arglist paren that gets entered. > ! c-parse-and-markup-<>-arglists > ! ;; Start of the identifier for which `got-identifier' was set. > ! name-start) > > (goto-char id-start) > > *************** > *** 6935,6941 **** > ;; If the third submatch matches in C++ then > ;; we're looking at an identifier that's a > ;; prefix only if it specifies a member pointer. > ! (when (setq got-identifier (c-forward-name)) > (if (looking-at "\\(::\\)") > ;; We only check for a trailing "::" and > ;; let the "*" that should follow be > --- 6937,6945 ---- > ;; If the third submatch matches in C++ then > ;; we're looking at an identifier that's a > ;; prefix only if it specifies a member pointer. > ! (when (progn (setq pos (point)) > ! (setq got-identifier > (c-forward-name))) > ! (setq name-start pos) > (if (looking-at "\\(::\\)") > ;; We only check for a trailing "::" and > ;; let the "*" that should follow be > *************** > *** 6961,6967 **** > ;; Skip over an identifier. > (or got-identifier > (and (looking-at c-identifier-start) > ! (setq got-identifier (c-forward-name)))) > > ;; Skip over type decl suffix operators. > (while (if (looking-at c-type-decl-suffix-key) > --- 6965,6973 ---- > ;; Skip over an identifier. > (or got-identifier > (and (looking-at c-identifier-start) > ! (setq pos (point)) > ! (setq got-identifier (c-forward-name)) > ! (setq name-start pos))) > > ;; Skip over type decl suffix operators. > (while (if (looking-at c-type-decl-suffix-key) > *************** > *** 7052,7074 **** > ;; declaration. > (throw 'at-decl-or-cast t)) > > - (when (and got-parens > - (not got-prefix) > - (not got-suffix-after-parens) > - (or backup-at-type > - maybe-typeless > - backup-maybe-typeless)) > - ;; Got a declaration of the form "foo bar (gnu);" where > we've > - ;; recognized "bar" as the type and "gnu" as the > declarator. > - ;; In this case it's however more likely that "bar" is the > - ;; declarator and "gnu" a function argument or initializer > (if > - ;; `c-recognize-paren-inits' is set), since the parens > around > - ;; "gnu" would be superfluous if it's a declarator. Shift > the > - ;; type one step backward. > - (c-fdoc-shift-type-backward))) > > ! ;; Found no identifier. > > (if backup-at-type > (progn > > --- 7058,7084 ---- > ;; declaration. > (throw 'at-decl-or-cast t)) > > > ! (when (and got-parens > ! (not got-prefix) > ! ;; (not got-suffix-after-parens) > ! (or backup-at-type > ! maybe-typeless > ! backup-maybe-typeless > ! (eq at-decl-or-cast t) > ! (save-excursion > ! (goto-char name-start) > ! (not (memq (c-forward-type) '(nil > maybe)))))) > ! ;; Got a declaration of the form "foo bar (gnu);" or "bar > ! ;; (gnu);" where we've recognized "bar" as the type and > "gnu" > ! ;; as the declarator. In this case it's however more > likely > ! ;; that "bar" is the declarator and "gnu" a function > argument > ! ;; or initializer (if `c-recognize-paren-inits' is set), > ! ;; since the parens around "gnu" would be superfluous if > it's > ! ;; a declarator. Shift the type one step backward. > ! (c-fdoc-shift-type-backward))) > > + ;; Found no identifier. > (if backup-at-type > (progn > > > > > > > -Ivan > > -- > Alan Mackenzie (Nuremberg, Germany). > --001a11331cb2f65a5404e90b1085 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oops,= forgot to CC the bug.

I&#= 39;ve been using the patch for a week now and haven't noticed any ill e= ffects. =A0

Thanks,
Ivan


On Sat, Oct 12, 2013 at 2:45 PM, Alan M= ackenzie <acm@muc.de> wrote:
Hello, Ivan.

On Sun, Sep 29, 2013 at 09:31:13PM -0600, Ivan Andrus wrote:
> Ivan Andrus <darthandrus@gmail.com> writes:

> > Font locking of C++ constructors is somewhat inconsistent. =A0Thi= s is
> > no doubt complicated by the fact that unlike other function
> > declarations they "don't have a return type".

This is, indeed, problematic.

> > When a single argument is not used but named, the constructor is = not
> > fontified (normally it's fontified with
> > `font-lock-function-name-face'). =A0If the keyword explicit i= s used,
> > then the argument type is fontified as a variable, and the
> > constructor name is fontified as a type. =A0Perhaps interestingly= ,
> > naming the parameter or adding another parameter causes fontifica= tion
> > to work correctly (with or without explicit).

Yes. =A0The pertinent function, `c-forward-decl-or-cast-1', is so= mewhat
probablistic. =A0If it gets sufficient clues from the context, it gets
things right, otherwise it has to guess, and sometimes will get things
wrong, particularly in C++, which doesn't have a nice context-free
syntax.

> > I have included a sample file below with comments on what I see i= n
> > `emacs -q`


=A0 > > class Bob
=A0 > > {
=A0 > > =A0 =A0 // string is `font-lock-type-face', Bob is `font-= lock-function-name-face'
1 > > =A0 =A0 Bob( string bob );
=A0 > > =A0 =A0 // string and Bob are not fontified (though I so= metimes see string fontified as a type)
2 > > =A0 =A0 Bob( string );
=A0 > > =A0 =A0 // string is `font-lock-variable-name-face',= Bob is `font-lock-type-face'
3 > > =A0 =A0 explicit Bob( string );
=A0 > > =A0 =A0 // string is `font-lock-type-face', Bob is `= font-lock-function-name-face'
4 > > =A0 =A0 explicit Bob( string, string );
=A0 > > };

> In fact, it's not just constructors that have this problem. =A0For=
> example the following function declaration:

5 > string lookup( size_t ) const;

> Removing const, or adding a name to the size_t parameter causes
> fontification to work correctly.

Yes.

Of the lines of code you've illustrated, 1 and 4 were OK. =A0I've c= orrected
3 and 5, which were relatively simple.

2 is a problem, because it looks like a normal function call. =A0If the
identifier in the parentheses (here "string") can be positively identified as a type (for example, some use elsewhere can only be a type, or it's a standard type like "string") it gets fontified. =A0= Otherwise,
it's assumed the construct is a function call. =A0It would no doubt be<= br> possible to check that the enclosing braces are a class declaration, and that "Bob" is the name of the class, but this would slow down the=
fontification, probably by a lot.

Would you please try out the patch below, and let me know how it goes.
It is based on the current source in the bzr trunk.

Again, thanks for such a crisp and concise bug report.



=3D=3D=3D modified file 'lisp/progmodes/cc-engine.el'
*** lisp/progmodes/cc-engine.el 2013-09-28 17:17:01 +0000
--- lisp/progmodes/cc-engine.el 2013-10-12 20:18:26 +0000
***************
*** 6917,6923 ****
=A0 =A0 =A0 =A0 =A0 ;; can happen since we don't know if
=A0 =A0 =A0 =A0 =A0 ;; `c-restricted-<>-arglists' will be correct= inside the
=A0 =A0 =A0 =A0 =A0 ;; arglist paren that gets entered.
! =A0 =A0 =A0 =A0 c-parse-and-markup-<>-arglists)

=A0 =A0 =A0 =A0 (goto-char id-start)

--- 6917,6925 ----
=A0 =A0 =A0 =A0 =A0 ;; can happen since we don't know if
=A0 =A0 =A0 =A0 =A0 ;; `c-restricted-<>-arglists' will be correct= inside the
=A0 =A0 =A0 =A0 =A0 ;; arglist paren that gets entered.
! =A0 =A0 =A0 =A0 c-parse-and-markup-<>-arglists
! =A0 =A0 =A0 =A0 ;; Start of the identifier for which `got-identifier'= was set.
! =A0 =A0 =A0 =A0 name-start)

=A0 =A0 =A0 =A0 (goto-char id-start)

***************
*** 6935,6941 ****
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; If the third submatch ma= tches in C++ then
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; we're looking at an = identifier that's a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; prefix only if it specif= ies a member pointer.
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (when (setq got-identifier (c= -forward-name))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (looking-at "\= \(::\\)")
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; We only chec= k for a trailing "::" and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; let the &quo= t;*" that should follow be
--- 6937,6945 ----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; If the third submatch ma= tches in C++ then
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; we're looking at an = identifier that's a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; prefix only if it specif= ies a member pointer.
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (when (progn (setq pos (point= ))
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(s= etq got-identifier (c-forward-name)))
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (setq name-start pos)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (looking-at "\= \(::\\)")
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; We only chec= k for a trailing "::" and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; let the &quo= t;*" that should follow be
***************
*** 6961,6967 ****
=A0 =A0 =A0 =A0 ;; Skip over an identifier.
=A0 =A0 =A0 =A0 (or got-identifier
=A0 =A0 =A0 =A0 =A0 (and (looking-at c-identifier-start)
! =A0 =A0 =A0 =A0 =A0 =A0 =A0(setq got-identifier (c-forward-name))))

=A0 =A0 =A0 =A0 ;; Skip over type decl suffix operators.
=A0 =A0 =A0 =A0 (while (if (looking-at c-type-decl-suffix-key)
--- 6965,6973 ----
=A0 =A0 =A0 =A0 ;; Skip over an identifier.
=A0 =A0 =A0 =A0 (or got-identifier
=A0 =A0 =A0 =A0 =A0 (and (looking-at c-identifier-start)
! =A0 =A0 =A0 =A0 =A0 =A0 =A0(setq pos (point))
! =A0 =A0 =A0 =A0 =A0 =A0 =A0(setq got-identifier (c-forward-name))
! =A0 =A0 =A0 =A0 =A0 =A0 =A0(setq name-start pos)))

=A0 =A0 =A0 =A0 ;; Skip over type decl suffix operators.
=A0 =A0 =A0 =A0 (while (if (looking-at c-type-decl-suffix-key)
***************
*** 7052,7074 ****
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; declaration.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (throw 'at-decl-or-cast t))

- =A0 =A0 =A0 =A0 =A0 =A0 (when (and got-parens
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(not got-prefix)
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(not got-suffix-after-pare= ns)
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(or backup-at-type
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0maybe-typeless
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0backup-maybe-typel= ess))
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; Got a declaration of the form "foo ba= r (gnu);" where we've
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; recognized "bar" as the type and= "gnu" as the declarator.
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; In this case it's however more likely = that "bar" is the
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; declarator and "gnu" a function = argument or initializer (if
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; `c-recognize-paren-inits' is set), sin= ce the parens around
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; "gnu" would be superfluous if it= 's a declarator. =A0Shift the
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; type one step backward.
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 (c-fdoc-shift-type-backward)))

! =A0 =A0 =A0 =A0 ;; Found no identifier.

=A0 =A0 =A0 =A0 =A0 (if backup-at-type
=A0 =A0 =A0 =A0 =A0 =A0 =A0 (progn

--- 7058,7084 ----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; declaration.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (throw 'at-decl-or-cast t))


! =A0 =A0 =A0 =A0 =A0 =A0 =A0(when (and got-parens
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (not got-prefix)
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; (not got-suffix-after-= parens)
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (or backup-at-type
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 maybe-typeless ! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 backup-maybe-type= less
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (eq at-decl-or-ca= st t)
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (save-excursion ! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (goto-char na= me-start)
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (not (memq (c= -forward-type) '(nil maybe))))))
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; Got a declaration of the form "foo= bar (gnu);" or "bar
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; (gnu);" where we've recognized= "bar" as the type and "gnu"
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; as the declarator. =A0In this case it&#= 39;s however more likely
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; that "bar" is the declarator = and "gnu" a function argument
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; or initializer (if `c-recognize-paren-i= nits' is set),
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; since the parens around "gnu"= would be superfluous if it's
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; a declarator. =A0Shift the type one ste= p backward.
! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(c-fdoc-shift-type-backward)))

+ =A0 =A0 =A0 =A0 =A0;; Found no identifier.
=A0 =A0 =A0 =A0 =A0 (if backup-at-type
=A0 =A0 =A0 =A0 =A0 =A0 =A0 (progn





> -Ivan

--
Alan Mackenzie (Nuremberg, Germany).

--001a11331cb2f65a5404e90b1085--