From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Some problems in `add-log-current-defun' Date: Wed, 27 Dec 2006 16:17:18 -0500 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: dough.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1167254508 2105 80.91.229.10 (27 Dec 2006 21:21:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Dec 2006 21:21:48 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 27 22:21:48 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GzgDU-0007Qn-SH for ged-emacs-devel@m.gmane.org; Wed, 27 Dec 2006 22:21:41 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GzgDU-0003DX-9i for ged-emacs-devel@m.gmane.org; Wed, 27 Dec 2006 16:21:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gzg9V-00071I-O4 for emacs-devel@gnu.org; Wed, 27 Dec 2006 16:17:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gzg9V-00070v-3u for emacs-devel@gnu.org; Wed, 27 Dec 2006 16:17:33 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gzg9U-00070j-SM for emacs-devel@gnu.org; Wed, 27 Dec 2006 16:17:32 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gzg9U-0003KU-Jf for emacs-devel@gnu.org; Wed, 27 Dec 2006 16:17:32 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Gzg9G-0002nd-I6; Wed, 27 Dec 2006 16:17:18 -0500 Original-To: "Herbert Euler" In-reply-to: (herberteuler@hotmail.com) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:64376 Archived-At: But this is not reliable. If someone forgets to put a newline after a function, `add-log-current-defun' will report wrong name. Please consider the following example: int f1 () { /* If point is here `add-log-current-defun' gets wrong result. */ } int f2 () { /* ... */ } When the point is inside the body of `f1', invoking `add-log-current-defun' will get `f2', rather than `f1'. That bug is worth fixing. In the past, CC mode does not consider the arguments of DEFUN as a defun, so `beginning-of-defun' will move point to the beginning of the function that appear before this DEFUN. With the forms in `add-log-current-defun', the result is correct. But I found in the newest CC mode considers the arguments (starting with ``("catch"'', ending with ``*/)'') as a defun, That change in CC mode would clearly be a change for the better, but it doesn't work for me. I updated my sources yesterday around noon EST. I find that `beginning-of-defun' when given inside the DEFUN args of Fcatch moves back to the { at the start of the body of Fmacroexpand. I also find that C-M-a is bound to `beginning-of-defun' in C mode. Wasn't it supposed to be `c-beginning-of-defun' nowadays? What is wrong here? In any case, it would be good to change `add-log-current-defun' to correspond to the new improved behavior of CC mode. void ssort(void * base, size_t n, size_t sz, CFT cmp) /* Sort the "n" elements of vector "base" into increasing order using the comparison function pointed to by "cmp". The elements are of size "sz". Shell sort (Knuth, Vol3, pg84) */ { /* ... */ } That seems like common usage -- not weird. It would be nice to handle that usage correctly. However, if we have never handled it in the past, I think it is not urgent to fix it now. Masatake YAMATO thinks that code is badly formatted. Masatake, why do you think so? This is not general too: C++ permits the nested name to be put in many lines. For example, the following name is valid: void class_1 :: sub_class_2 :: method_3 () { /* ... */ } The current implementation cannot handle this name correctly. I'd say don't bother with that. At least not now.