From: Richard Stallman <address@hidden>
Reply-To: address@hidden
To: "Herbert Euler" <address@hidden>
CC: address@hidden
Subject: Re: Some problems in `add-log-current-defun'
Date: Wed, 27 Dec 2006 16:17:18 -0500
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 <address@hidden> 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.
_______________________________________________
Emacs-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-devel