Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-24 Thread Federico Mena Quintero

  :set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
  
  Works most of the case.. (maybe not perfect, but..)

Thanks a lot!  I just put it in the programming guidelines.

  Federico



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-23 Thread Glyph Lefkowitz


On Wed, 23 Feb 100, Miles O'Neal wrote:

[snip thought GNU style was bad but it's OK]

 I still don't.  Two spaces just isn't enough.  Three
 or four is much better.  And I like space before the
 paren only if it isn't after a function or procedure
 name.

And I firmly believe that if God had intended we format our code with
spaces, He would have made them wider.  In my own projects, I use a
one-tab-per-indent style. (I have no idea if my style is analagous to
someone else's; I wrote my own .emacs files.) This drives some of my
developers nuts, but it's my perogative, just as it's the GIMP community's
perogative to enforce GNU style.

[snip consistent style important]

 I use to feel this way.  But now, so long as each file has a
 consisten, reasonable style (or preferably, package of files, say a
 directory), I'm happy.

If it's a requirement of a project that one adhere to a specific coding
style, I think it's pretty rude to ignore such a request in contributions
to that code, regardless of one's personal beliefs on the matter.

 I handle perl as closely as possible to how I handle C.

I think Perl should standardize on only 10 or 20 different ways to write a
loop before you start worrying about indentation.  And people wonder why
Python has the whitespace enforcement rules... ::runs from Marc :-)::

  __  __   __  _  _ _
 |   |  \_/   |_] |_|
 |_| |_  ||   | |
 @ t w i s t e d m a t r i x  . c o m
 http://www.twistedmatrix.com/~glyph/





Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Raphael Quinet

On Tue, 22 Feb 2000, [EMAIL PROTECTED] wrote:
 On 22 Feb, Manish Singh wrote:
  True, although we have a couple other inconsistencies already. The
  coding style needs to be the same as the rest of gimp though.
 
  I tried to bring it as near as possible. Of course a lot things could
  be better

I noticed two obvious differences in your code: it does not use two
spaces for indentation (the default in Emacs and the recommended GNU
style) and there is no space between the function names and the
opening parenthesis for the arguments.  I suggest that you use a
recent version of GNU indent to process your source code and re-indent
everything automatically, or that you use Emacs with the default
settings (no modifications in a ~/.emacs file) and call indent-region
on the whole file.

I did not like the GNU style at first (especially the space before the
opening parenthesis) but now I understand that it is very important to
keep a consistent coding style in each project, because it keeps the
code manageable and maintainable.  So I always use whatever coding
style is recommended for the each project, even if this means that I
have to format my patches differently for the Gimp and for a Linux
driver, for instance.  Since the Gimp uses the GNU style, I think that
it is important to follow the GNU coding guidelines faithfully.

While we are on the subject of coding style, there are two areas of
the Gimp that are not using a consistent coding style: the Script-Fu
scripts and, to a lesser extent, the Perl scripts.  Is there a
recommended style for these?

  It's not that much code, and does fix a gaping hole in the i18n
  framework for plugins not distributed with gimp. Especially if we want
  1.2 to last a while..
 
  That's absolutely right.

Yup!  Me too (tm).

-Raphael



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Daniel . Egger

On 22 Feb, Raphael Quinet wrote:

 I did not like the GNU style at first (especially the space before the
 opening parenthesis) but now I understand that it is very important
 to keep a consistent coding style in each project, because it keeps
 the code manageable and maintainable.  So I always use whatever coding 
 style is recommended for the each project, even if this means that I 
 have to format my patches differently for the Gimp and for a Linux 
 driver, for instance.  Since the Gimp uses the GNU style, I think that 
 it is important to follow the GNU coding guidelines faithfully.

 Okay, will turn from the Standard vi indention into GNU coding style.

 BTW: While browsing the code I saw some file not matching ANY standard
 like xcf.h. It has neither a GNU header nor any guardings

  It's not that much code, and does fix a gaping hole in the i18n
  framework for plugins not distributed with gimp. Especially if we
  want 1.2 to last a while..
 
  That's absolutely right.
 
 Yup!  Me too (tm).

 Glad to hear that.

-- 

Servus,
   Daniel



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Miles O'Neal

Raphael Quinet said...
|
|I did not like the GNU style at first (especially the space before the
|opening parenthesis)

I still don't.  Two spaces just isn't enough.  Three
or four is much better.  And I like space before the
paren only if it isn't after a function or procedure
name.

|but now I understand that it is very important to
|keep a consistent coding style in each project, because it keeps the
|code manageable and maintainable.  So I always use whatever coding
|style is recommended for the each project, even if this means that I
|have to format my patches differently for the Gimp and for a Linux
|driver, for instance.  Since the Gimp uses the GNU style, I think that
|it is important to follow the GNU coding guidelines faithfully.

I use to feel this way.  But now, so long as each file has a consisten,
reasonable style (or preferably, package of files, say a directory),
I'm happy.

|While we are on the subject of coding style, there are two areas of
|the Gimp that are not using a consistent coding style: the Script-Fu
|scripts and, to a lesser extent, the Perl scripts.  Is there a
|recommended style for these?

I handle perl as closely as possible to how I handle C.

-Miles



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Marc Lehmann

On Tue, Feb 22, 2000 at 02:59:18PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote:
 scripts and, to a lesser extent, the Perl scripts.  Is there a
 recommended style for these?

Yes, just copy mine ;)

For perl-only-syntax-questions, the reference should be "perldoc
perlstyle".  All the remaining questions (which excludes syntax, and
includes things like "how to add documentation", "how to name fucntions
etc.." should go into it's own style-document that I plan to write since,
well, years or so).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Coding style

2000-02-22 Thread Sven Neumann

Hi,

 While we are on the subject of coding style, there are two areas of
 the Gimp that are not using a consistent coding style: the Script-Fu
 scripts and, to a lesser extent, the Perl scripts.  Is there a
 recommended style for these?

Oh well, there are more areas. Not even the core strictly follows a
common style. But this has got much better since Mitch and me got
infected with the "indentation paranoia". If we take care that new
code is correctly formatted, it's only a matter of time until all code
got overworked. But if you look into the plugins you will find a
collection of all sorts of coding styles and even some examples of the
total lack of it.  

I do not think that it is necessary to reformat all scripts, but since
you wanted to go through most Script-Fu's anyway, I suggest you use the
indendation emacs proposes for Scheme code. I've just checked and IMHO 
it's a useful default.


Salut, Sven







Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Marc Lehmann

On Tue, Feb 22, 2000 at 03:56:44PM +0100, [EMAIL PROTECTED] wrote:
  Okay, will turn from the Standard vi indention into GNU coding style.

"Standard vi indentation" is fine. Just follow the GNU coding style on
when to indent, and when not (and when to add spaces, when not...) ;)

The idea, however, is very sane.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Federico Mena Quintero

   Uhm, I use vim and vim uses tabs by default and doesn't indent
   the { after an if like GNU suggests. Du you have working settings to
   achieve this?

I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation style.  If you tweak it a bit it may work for GNU
indentation style.  You can look at it here:

  http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html

Please tell me if this works or if you had to change something; I'd
like to keep that part of the programming guidelines as accurate as
possible.

Sorry if this is not of any help, I don't do vi :-)

  Federico



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Marc Lehmann

On Tue, Feb 22, 2000 at 07:59:21PM +0100, [EMAIL PROTECTED] wrote:
  Uhm, I use vim and vim uses tabs by default and doesn't indent

vim, like vi and emacs, has a manual and can be configured quite freely ;)

  the { after an if like GNU suggests. Du you have working settings to
  achieve this?

One of my 99 config lines is:

set formatoptions=croql cindent cinkeys={,},:,0#,!^F,o,O,e cinoptions={.5s,}0,g0,^-2 
sw=2 comments=sr:/*,mb:*,el:*/,://

(However, that's not exactly gnu-style).

HTH,

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Daniel . Egger

On 22 Feb, Federico Mena Quintero wrote:

 I don't know if this will be useful at all, but the GNOME Programming
 Guidelines has a snippet for .vimrc to set the Linux kernel
 indentation style. 

 This is the standard vim style.

 If you tweak it a bit it may work for GNU indentation style.

 No, unfortunately I couldn't get vim used to GNU indention style.

 Please tell me if this works or if you had to change something; I'd
 like to keep that part of the programming guidelines as accurate as
 possible.

 It'd work, but not for GIMPs code. :/

-- 

Servus,
   Daniel



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Marc Lehmann

On Tue, Feb 22, 2000 at 11:54:03PM +0100, [EMAIL PROTECTED] wrote:
  Well, that the thing I'm talking about.
  I tried this options and think that it doesn't match it very good.
  After the first { of a function the source isn't indented for example. 

Then, most probably, you have a very very old or broken version of vim
(or maybe you use another editor, or vim in vi-emulation mode). The whole
point of these options is to make indentation automatic and more-or-less
gnu-style.

Anyway, read the docs. It's not black magic to get a little help from your
editor. Or, maybe, change your editor ;)

In any case, giving "my editor does indent differently" is a very poor
reply to a request to follow a specific coding style. You can write
gnu-style using any non-broken editor! So if your editor does indent
differently, use the keys of your keyboard to correct your editor, or read
the docs on how to persuade your editor to do it for you.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Federico Mena Quintero

   If you tweak it a bit it may work for GNU indentation style.
  
   No, unfortunately I couldn't get vim used to GNU indention style.
  
   Please tell me if this works or if you had to change something; I'd
   like to keep that part of the programming guidelines as accurate as
   possible.
  
   It'd work, but not for GIMPs code. :/

Oh, well.  Thanks anyway.

Please tell me if you find a way to make it work; other people may
find it useful.

  Federico



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Tomas Ogren

On 22 February, 2000 - [EMAIL PROTECTED] sent me these 0.6K bytes:

 On 22 Feb, Federico Mena Quintero wrote:
 
  I don't know if this will be useful at all, but the GNOME Programming
  Guidelines has a snippet for .vimrc to set the Linux kernel
  indentation style. 
 
  This is the standard vim style.
 
  If you tweak it a bit it may work for GNU indentation style.
 
  No, unfortunately I couldn't get vim used to GNU indention style.

:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0

Works most of the case.. (maybe not perfect, but..)

/Tomas
-- 
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Daniel . Egger

On 23 Feb, Marc Lehmann wrote:
 Then, most probably, you have a very very old or broken version of vim
 (or maybe you use another editor, or vim in vi-emulation mode).

 Actually it's the latest stable version of vim.

 The whole point of these options is to make indentation automatic and
 more-or-less gnu-style.

 I was told that the style I used before is not acceptable as GNU style
 so I guess it's the less in "more-or-less".

 In any case, giving "my editor does indent differently" is a very poor
 reply to a request to follow a specific coding style.

 Well, Marc, if you followed this list then you'd know that I already
 posted an well indented and improved version of my patch. It was just
 a kind of a BTW note that I can't bring my editor to automatically 
 create this indention style.

 You can write 
 gnu-style using any non-broken editor! So if your editor does indent 
 differently, use the keys of your keyboard to correct your editor, or
 read the docs on how to persuade your editor to do it for you.

 This seems impossible, but fortunately indent is working quite nice for
 me so this is now just an annoyance no "problem" anymore.

-- 

Servus,
   Daniel