c-mark-function goes too far

c-mark-function goes too far

[Pete Klammer]

In certain cases, `M-C-h' (`c-mark-function') goes too far.  

The bottom (mark) is placed at end-of-buffer, if my function looks like this
...

void myfunction( void ) {
	mychar = getch() ;
}

... But if it looks like this, mark is correctly placed after the closing
brace:

void myfunction( void )
{
	mychar = getch() ;
}

I have my C style set to 'k&r', and all automatic indenting, and even M-C-\
region indenting, is doing as I like.  I suppose putting the opening
function-block brace up on the same line as the function declaration may not
be pure k&r... However, syntactic analysis (C-c C-s) of the closing brace
shows the same information in either case, and besides, it's consistent with
k&r while() and do etc. brace positioning.  So why doesn't c-mark-function
recognize the defun-close and put the mark there?

--

 Peter F. Klammer, P.E.
 NETRONICS Professional Engineering, Inc.
 3200 Routt Street
 Wheat Ridge, Colorado 80033-5452
   (303)915-2673 (Wireless w/voicemail)
   (303)274-6182 (w/voicemail and FAX)
    Mailto:PKlammer@NETRONICS-PE.com
 "Net:Working Programmable Electronics!"

Re: c-mark-function goes too far

[Eric Hanchrow]

>>>>> "Pete" == Pete Klammer <NETRONICS-PE@comcast.net> writes:

    Pete> In certain cases, `M-C-h' (`c-mark-function') goes too far.
    Pete> The bottom (mark) is placed at end-of-buffer, if my function
    Pete> looks like this ...

    Pete> void myfunction( void ) { mychar = getch() ;
    Pete> }

I don't remember the details, but I think Emacs always assumed that
function definitions begin with a left-brace at the left column.
Presumably c-mark-function is making that same assumption, and
searching forward for one, and not finding it.

-- 
When it comes to electronic voting, most liberals are just plain
old-fashioned nuts.
        -- Joe Andrew, former chairman of the Democratic National
           Committee

Re: c-mark-function goes too far

[Miles Bader]

Eric Hanchrow <offby1@blarg.net> writes:
> I don't remember the details, but I think Emacs always assumed that
> function definitions begin with a left-brace at the left column.
> Presumably c-mark-function is making that same assumption, and
> searching forward for one, and not finding it.

Yes, it's actually a somewhat complicated issue, it's not a quick fix
sort of thing.

It might help people using this syntax to set the Emacs variable
`open-paren-in-column-0-is-defun-start' to nil, but I'm not really sure
of all the consequences of doing that.

Languages like Java have it much worse -- even isolated braces are
indented because functions are always methods within a class, so Emacs
function-oriented commands basically never do the right thing.

I find that as a _person_ reading code I tend to use similar assumptions
when reading code, which makes "function opening brace at the end of the
line" code a fair bit harder to read for me -- that "opening brace in
column 0" is really easy for your eye to find when quickly scanning
code.  My guess as to the reason is that (1) it's much easier to quickly
locate a brace that's isolated on a line by itself, and (2) the end of
the line is harder to track simply because it doesn't have a fixed
position.  [Of course it was a lot worse in the old K&R days, when some
people would mix that brace style with K&R-style function arguments
... ugh!]

-miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: c-mark-function goes too far

[Richard Stallman]

    Languages like Java have it much worse -- even isolated braces are
    indented because functions are always methods within a class, so Emacs
    function-oriented commands basically never do the right thing.

What about the commands that CC mode provides in Java mode?
Do they work better in these cases?


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: c-mark-function goes too far

[Alan Mackenzie]

Hi, Miles, Richard and Emacs!

On Wed, Jan 10, 2007 at 01:46:17PM -0500, Richard Stallman wrote:
>     Languages like Java have it much worse -- even isolated braces are
>     indented because functions are always methods within a class, so Emacs
>     function-oriented commands basically never do the right thing.

> What about the commands that CC mode provides in Java mode?
> Do they work better in these cases?

No, not at the moment. 

This enhancement (making C-M-[ae] jump to the beginning/end of a
function/method/... contained within a class/namespace/...) has been at
the top of the CC Mode TODO list for some time.  It's been asked for by
quite a lot of people.  The feature almost made it into CC Mode 5.31 at
the end of 2005.

It isn't actually that hard an enhancement, particularly after the
recent refactoring of c-\(beginning\|end\)-of-defun.  Amending the CC
Mode and Emacs manuals will likely be more work than fixing the code.

Just as soon as I've got "all" the bugs fixed for 5.31.4 and released
it, I'll get this into a quick 5.32 release (with one other new
feature).

-- 
Alan.

Re: c-mark-function goes too far

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> Just as soon as I've got "all" the bugs fixed

Very well-placed quotes there... :-)

> for 5.31.4 and released it, I'll get this into a quick 5.32 release
> (with one other new feature).

I'm looking forward to it -- I never really realized how much I use
beginning/end-of-defun until I started hacking on Java!

Thanks,

-Miles

-- 
Quidquid latine dictum sit, altum viditur.

Re: c-mark-function goes too far

[Richard Stallman]

    Just as soon as I've got "all" the bugs fixed for 5.31.4 and released
    it,

Would you please install those fixes in Emacs too?

     I'll get this into a quick 5.32 release (with one other new
    feature).

Is this something that would be safe enough to install now?

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV