GNU bug report logs - #19134
24.4.51; Error using mark-defun in c++-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19134 in the body.
You can then email your comments to 19134 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.51; Error using mark-defun in c++-mode
Date: Thu, 20 Nov 2014 15:01:20 -0700

Starting from emacs -Q, create a buffer in `c++-mode' with contents below.

class Bob
{
protected:

    void fun()
    {
    }

};


Placing point on the line after "protected:" and running mark-defun gives
the error:

c-where-wrt-brace-construct: c-where-wrt-brace-construct: c-beginning-of-decl-1 returned label

Ideally it would give no error, and IMO, it should mark fun(), though marking the class would be fine as well.

-Ivan


In GNU Emacs 24.4.51.7 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
of 2014-11-17 on iandrus-osx
Repository revision: 1574e964bb3103e298e83fd2fca402fa48743465
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure --with-ns'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++/l

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
Mark set
user-error: No further undo information [3 times]
Quit
Undo! [3 times]
Redo!
Mark set
c-where-wrt-brace-construct: c-where-wrt-brace-construct: c-beginning-of-decl-1 returned label
Buffer is read-only: #<buffer *Messages*>
Undo! [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode cc-langs cl-loaddefs cl-lib
cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs time-date tooltip electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process cocoa ns
multi-tty emacs)

Memory information:
((conses 16 104996 7269)
(symbols 48 20219 0)
(miscs 40 56 233)
(strings 32 17498 4574)
(string-bytes 1 589344)
(vectors 16 11562)
(vector-slots 8 409861 5782)
(floats 8 57 254)
(intervals 56 227 21)
(buffers 960 12))

Message #8 received at 19134 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: 19134 <at> debbugs.gnu.org
Subject: Re: bug#19134: 24.4.51; Error using mark-defun in c++-mode
Date: 22 Nov 2014 22:04:13 -0000

Hello again, Ivan.

In article <mailman.14214.1416532702.1147.bug-gnu-emacs <at> gnu.org> you wrote:
> Starting from emacs -Q, create a buffer in `c++-mode' with contents below.

> class Bob
> {
> protected:

>    void fun()
>    {
>    }

> };


> Placing point on the line after "protected:" and running mark-defun gives
> the error:

> c-where-wrt-brace-construct: c-where-wrt-brace-construct: c-beginning-of-decl-1 returned label

Yes.  I've just pushed the following patch to the git repository:


diff --git a/lisp/progmodes/cc-cmds.el b/lisp/progmodes/cc-cmds.el
index 5fa3b25..50cdd78 100644
--- a/lisp/progmodes/cc-cmds.el
+++ b/lisp/progmodes/cc-cmds.el
@@ -1417,12 +1417,15 @@ No indentation or other \"electric\" behavior is performed."
              (car (c-beginning-of-decl-1
                    ;; NOTE: If we're in a K&R region, this might be the start
                    ;; of a parameter declaration, not the actual function.
+                   ;; It might also leave us at a label or "label" like
+                   ;; "private:".
                    (and least-enclosing ; LIMIT for c-b-of-decl-1
                         (c-safe-position least-enclosing paren-state)))))

        ;; Has the declaration we've gone back to got braces?
-       (setq brace-decl-p
-             (save-excursion
+       (or (eq decl-result 'label)
+           (setq brace-decl-p
+                 (save-excursion
                    (and (c-syntactic-re-search-forward "[;{]" nil t t)
                         (or (eq (char-before) ?\{)
                             (and c-recognize-knr-p
@@ -1430,10 +1433,11 @@ No indentation or other \"electric\" behavior is performed."
                                  ;; ';' in a K&R argdecl.  In
                                  ;; that case the declaration
                                  ;; should contain a block.
-                                 (c-in-knr-argdecl))))))
+                                 (c-in-knr-argdecl)))))))

        (cond
-        ((= (point) kluge-start)       ; might be BOB or unbalanced parens.
+        ((or (eq decl-result 'label)   ; e.g. "private:" or invalid syntax.
+             (= (point) kluge-start))  ; might be BOB or unbalanced parens.
          'outwith-function)
         ((eq decl-result 'same)
          (if brace-decl-p


I think this should fix the problem.  Would you please test it with
`mark-defun' and confirm it works properly.  Thanks!

Incidentally, `c-mark-function' (the default binding for C-M-h in CC Mode)
doesn't do the right thing here.  I'll be looking into this.

> Ideally it would give no error, and IMO, it should mark fun(), though
> marking the class would be fine as well.

It marks the class, since it gives priority to defuns point is in, rather
than those which follow point.  There might be scope for some improvement
here.

Thanks for taking the trouble to distil the problem down to a nice, very
short piece of code, and for describing the problem so helpfully.

> -Ivan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #11 received at 19134 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 19134 <at> debbugs.gnu.org
Subject: Re: bug#19134: 24.4.51; Error using mark-defun in c++-mode
Date: Mon, 24 Nov 2014 20:00:36 -0700

On Nov 22, 2014, at 3:04 PM, Alan Mackenzie <acm <at> muc.de> wrote:

> Hello again, Ivan.
> 
> In article <mailman.14214.1416532702.1147.bug-gnu-emacs <at> gnu.org> you wrote:
>> Starting from emacs -Q, create a buffer in `c++-mode' with contents below.
> 
>> class Bob
>> {
>> protected:
> 
>>   void fun()
>>   {
>>   }
> 
>> };
> 
> 
>> Placing point on the line after "protected:" and running mark-defun gives
>> the error:
> 
>> c-where-wrt-brace-construct: c-where-wrt-brace-construct: c-beginning-of-decl-1 returned label
> 
> Yes.  I've just pushed the following patch to the git repository:
> 
> 
> diff --git a/lisp/progmodes/cc-cmds.el b/lisp/progmodes/cc-cmds.el
> index 5fa3b25..50cdd78 100644
> --- a/lisp/progmodes/cc-cmds.el
> +++ b/lisp/progmodes/cc-cmds.el
> @@ -1417,12 +1417,15 @@ No indentation or other \"electric\" behavior is performed."
>              (car (c-beginning-of-decl-1
>                    ;; NOTE: If we're in a K&R region, this might be the start
>                    ;; of a parameter declaration, not the actual function.
> +                   ;; It might also leave us at a label or "label" like
> +                   ;; "private:".
>                    (and least-enclosing ; LIMIT for c-b-of-decl-1
>                         (c-safe-position least-enclosing paren-state)))))
> 
>        ;; Has the declaration we've gone back to got braces?
> -       (setq brace-decl-p
> -             (save-excursion
> +       (or (eq decl-result 'label)
> +           (setq brace-decl-p
> +                 (save-excursion
>                    (and (c-syntactic-re-search-forward "[;{]" nil t t)
>                         (or (eq (char-before) ?\{)
>                             (and c-recognize-knr-p
> @@ -1430,10 +1433,11 @@ No indentation or other \"electric\" behavior is performed."
>                                  ;; ';' in a K&R argdecl.  In
>                                  ;; that case the declaration
>                                  ;; should contain a block.
> -                                 (c-in-knr-argdecl))))))
> +                                 (c-in-knr-argdecl)))))))
> 
>        (cond
> -        ((= (point) kluge-start)       ; might be BOB or unbalanced parens.
> +        ((or (eq decl-result 'label)   ; e.g. "private:" or invalid syntax.
> +             (= (point) kluge-start))  ; might be BOB or unbalanced parens.
>          'outwith-function)
>         ((eq decl-result 'same)
>          (if brace-decl-p
> 
> 
> I think this should fix the problem.  Would you please test it with
> `mark-defun' and confirm it works properly.  Thanks!

Yes, I confirm that it works.  

> Incidentally, `c-mark-function' (the default binding for C-M-h in CC Mode)
> doesn't do the right thing here.  I'll be looking into this.

I didn’t notice that.  I have C-M-h bound to a wrapper around mark-defun in my .emacs, so I don’t actually run c-mark-function.  Thanks for pointing me to it.

>> Ideally it would give no error, and IMO, it should mark fun(), though
>> marking the class would be fine as well.
> 
> It marks the class, since it gives priority to defuns point is in, rather
> than those which follow point.  There might be scope for some improvement
> here.

That’s fine.  It could probably be better but, hey, what couldn’t?  :-)

> Thanks for taking the trouble to distil the problem down to a nice, very
> short piece of code, and for describing the problem so helpfully.

And thank you for the very fast fix.  I should have taken the time a while since I have run into it occasionally.

-Ivan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.