Subject: matchVersion() compile problems

From: Dominik Vogt <[email-masked]>
Date: Thu, 8 Jul 2004 11:21:53 +0200

To avoid problems with comiling / reading the fvwm sources, please

 * adhere to the ANSI-C 88 standard, not the new one.
   Specifically,

    - Don't use C++-like comments with //
    - Declare variables only at the beginning of a block.

 * limit your lines to 79 characters (if possible, do not use 80
   characters - I can't get xemacs to start with 80 columns, it
   either has 79 or 81 because of the font I use).

 * Please put single statements in loops or if clauses in curly
   braces, i.e.

     if (1)
     {
       foo;
     }

   not

     if (1)
       foo;

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Scott Smedley <[email-masked]>
Date: Sat, 10 Jul 2004 17:58:54 +1000

Hi Dominik, :)

>    either has 79 or 81 because of the font I use).

Sure. No problem.

>  * Please put single statements in loops or if clauses in curly

What's the rationale behind this? I must confess I'm not particularly fond
of this restriction but I will, of course, follow any FVWM coding standards.

SCoTT. :)
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Scott Smedley <[email-masked]>
Date: Sat, 10 Jul 2004 18:42:24 +1000

>From docs/CONVENTIONS:

 o Always place curly braces on a separate line.  In some cases,
   placing braces on the same line as other code confuses
   (x)emacs.

Wouldn't it be prudent to fix Emacs?

(That's an honest question, not trying to start an xemacs-vs-gvim war.)

SCoTT.

---

From: Dan Espen <[email-masked]>
Date: Sat, 10 Jul 2004 09:36:45 -0400

> (That's an honest question, not trying to start an xemacs-vs-gvim war.)

I don't think Emacs has anything to do with it.
As far as I can tell, Emacs has no problems with either format.
Certainly someone would submit a bug report if there was a problem.

I think the above choices are personal preference.
Personally, I like curly braces to NOT take an extra line.
There are sound arguments to be made on both sides.

This is what I put in my .emacs to allow Emacs to follow the
fvwm standard for fvwm work, and for me to use my own rules for
everything else:

;set my defaults for c
(defun my-c-mode-hook ()
  (if (string-match "fvwm" buffer-file-name) ;fvwm project settings:
      (progn
	(setq
	 c-indent-level 8
	 c-basic-offset 8
	 c-brace-offset 0
	 c-continued-brace-offset 0
	 c-brace-imaginary-offset 0
	 c-continued-statement-offset 0
	 c-label-offset 0
	 c-argdecl-indent 0
	 c-auto-newline nil
	 c-tab-always-indent t
	 indent-tabs-mode t)
	 (c-set-offset 'substatement-open 0))
    ;; Local site default settings
    (setq 
     c-indent-level 2
     c-basic-offset 2
     c-brace-offset 0
     c-continued-brace-offset 0
     c-brace-imaginary-offset 0
     c-continued-statement-offset 2
     c-label-offset -2
     c-argdecl-indent 0
     c-auto-newline nil
     c-tab-always-indent t
     indent-tabs-mode nil
     comment-column 40)))
(add-hook 'c-mode-hook 'my-c-mode-hook t)

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Jul 2004 02:47:06 +0200

> > of this restriction but I will, of course, follow any FVWM coding standards.

Maintenance.  It is easy to forget to add the curly braces when
you add another statement to a branch, at least if your editor
does not automatically indent the code.  There's not much else
behind it.

> Wouldn't it be prudent to fix Emacs?

The question is:  who is going to do it?  I don't know how to fix
it.  One case in which xemacs misbehaves is when you have such a
function:

  void foo(void) {
    ...
  }

If you press C-x 4 a to generate a ChangeLog entry, it does not
find the function's name.   That does not affect code inside the
functions.  Personally

 * I don't like braces on a code line because I have difficulties
   to find the matching closing brace if it's not in the same
   column.
 * I don't care much about code in places I rarely look at, but if
   I see such code in the files I maintain most of the time (most
   of the fvwm core), I reformat it.

Ciao

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 11 Jul 2004 11:19:55 -0400

Dominik Vogt <[email-masked]> writes:
> > > >=20
> > > >=20
> > > >=20
...
> find the function's name.

So thats why a few things I try to do in Emacs don't work.
The underlying brokenness is in "beginning-of-defun" which is
widely used, for example, by C-x 4 a.
Emacs often has to go back to the beginning of
the function to figure out what it is looking at.

The default pattern for beginning-of_defun is to just look for
"{" in the first column.  That can be overridden by setting
defun-prompt-regexp but my few attempts were failures.

I see this is a known issue, and after reading this:

http://w3.pppl.gov/info/ccmode/Performance_Issues.html

I'm pretty much convinced that the curly brace in column 1 for
functions is an Emacs requirement.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Jul 2004 18:07:07 +0200

> functions is an Emacs requirement.

It's not only emacs, other C tools need it too.  I think cscope is
one of them.

Ciao

Dominik ^_^  ^_^