emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Stallman
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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]