bug#6159: 23.2; c++ parenthesis matching problem

bug#6159: 23.2; c++ parenthesis matching problem

[Ertan Dogrultan]

I do C++ programming on Emacs. When I call methods of a class from an object pointer and write
like object->get_value(); The sign '>' is considered like parenthesis
and causes indentation mistakes, although the program compiles and
executes without any problems. 


In GNU Emacs 23.2.1 (i686-pc-linux-gnu)
 of 2010-05-09 on Ertan
Windowing system distributor `Fedora Project', version 11.0.10706000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: C++/l

Minor modes in effect:
  show-paren-mode: t
  display-time-mode: t
  tooltip-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-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
o r < i n t > SPC c u t s e t <left> <left> <left> 
<left> <left> <left> <left> & <end> SPC = SPC d t r 
e e - > c u t s e t ; <down> <tab> <up> <end> <tab> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<tab> <end> <tab> <left> <left> <left> <left> <left> 
<left> <left> <tab> <tab> <tab> <tab> <tab> <left> 
<left> SPC <tab> <tab> <right> <tab> <right> <tab> 
<tab> <tab> <tab> <tab> <backspace> <backspace> <backspace> 
- > <tab> <tab> <tab> <tab> <tab> SPC SPC <backspace> 
SPC SPC <backspace> <backspace> <backspace> <tab> <tab> 
<tab> <tab> <tab> <tab> <tab> <tab> <down> <tab> <left> 
<tab> <tab> <up> <end> <down> <tab> <up> <tab> <end> 
<tab> <tab> <tab> <tab> <tab> <up> <down> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> SPC 
<right> <right> SPC <tab> <tab> <right> <left> <left> 
<tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> 
<tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> 
<tab> <tab> <tab> <tab> <tab> <down> <down> <left> 
<up> <left> <tab> <right> <tab> <tab> <tab> <tab> <tab> 
<tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> 
<tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> 
<tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> 
<tab> <tab> <tab> <tab> <tab> <up> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <backspace> <right> <right> <right> <backspace> 
<left> <left> <left> <left> <left> <left> <left> <backspace> 
<left> <backspace> <tab> <tab> <right> <right> <right> 
<right> <right> <right> <right> <tab> <right> <tab> 
<tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> <tab> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<end> <return> <tab> <tab> M-x r e p o <tab> r <tab> 
<return>

Recent messages:
Checking 87 files in /usr/local/share/emacs/23.2/lisp/calc...
Checking 39 files in /usr/local/share/emacs/23.2/lisp/obsolete...
Checking 1 files in /usr/local/share/emacs/23.2/leim...
Checking for load-path shadows...done
Auto-saving...done
Mark set [2 times]
Auto-saving...done
Auto-saving...done
Auto-saving...done
Making completion list...

Load-path shadows:
None found.

Features:
(newcomment help-mode view shadow sort mail-extr message sendmail
ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies
mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums
mailabbrev nnheader gnus-util netrc time-date mm-util mail-prsvr
gmm-utils wid-edit mailheader canlock sha1 hex-util hashcash mail-utils
emacsbug multi-isearch dabbrev vc-git cc-mode cc-fonts easymenu cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt
saveplace paren time cus-start cus-load edmacro kmacro tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag 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 loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process font-render-setting x multi-tty emacs)

-- 
Ertan

bug#6159: 23.2; c++ parenthesis matching problem

[Alan Mackenzie]

Hi, Ertan,

On Mon, May 10, 2010 at 11:58:00AM -0700, Ertan Dogrultan wrote:
> I do C++ programming on Emacs. When I call methods of a class from an
> object pointer and write like object->get_value(); The sign '>' is
> considered like parenthesis and causes indentation mistakes, although
> the program compiles and executes without any problems. 

this is a known problem with C++.  It takes semantic analysis (i.e. a
compiler) reliably to distinguish between "greater than" and "close
template".  However, there are improvements to this being worked on.

Is there any chance you could supply a preferably small but complete
piece of source code which illustrates the problem?  Does the bug happen
with every -> operator, or only in certain circumstances?

> Ertan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#6159: 23.2; c++ parenthesis matching problem

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> On Mon, May 10, 2010 at 11:58:00AM -0700, Ertan Dogrultan wrote:
>> I do C++ programming on Emacs. When I call methods of a class from an
>> object pointer and write like object->get_value(); The sign '>' is
>> considered like parenthesis and causes indentation mistakes, although
>> the program compiles and executes without any problems. 
>
> this is a known problem with C++.  It takes semantic analysis (i.e. a
> compiler) reliably to distinguish between "greater than" and "close
> template".  However, there are improvements to this being worked on.
>
> Is there any chance you could supply a preferably small but complete
> piece of source code which illustrates the problem?  Does the bug happen
> with every -> operator, or only in certain circumstances?

More information was requested three years ago, but no further progress
has been made, so I'm closing this bug report.  If this problem is still
present, please reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/