Re: Some problems in `add-log-current-defun'

[Richard Stallman <rms@gnu.org>]

    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 <jet@gyve.org> 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.