Coding style for emacs

Jeff Davis wrote:

At the link:

http://www.postgresql.org/docs/8.1/static/source.html

It gives some style configuration code to put in the .emacs file.
However, when I do that, emacs doesn't appear to follow the style of the
postgresql source. For instance, inside a function definition emacs
always indents by 8 columns.

What emacs scripts do the hackers use? Is that documentation out of
date?

I use more or less what is in the developers' FAQ (not surprising, since
I contributed it). It works just fine for me. See
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9

We should probably bring the docs in line with that, unless someone with
more emacs-fu than me has something to add.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

I use more or less what is in the developers' FAQ (not surprising, since
I contributed it). It works just fine for me. See
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9

We should probably bring the docs in line with that, unless someone with
more emacs-fu than me has something to add.

I think it depends on which version of emacs you're using. The stuff in
the docs is pretty close to what I'm still using on emacs 19 (yeah, it's
old, but if it ain't broke...). It might be appropriate to list both
macros with a note about the version dependency.

regards, tom lane

Andrew Dunstan <andrew@dunslane.net> writes:

I use more or less what is in the developers' FAQ (not surprising, since I
contributed it). It works just fine for me. See
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9

We should probably bring the docs in line with that, unless someone with more
emacs-fu than me has something to add.

Oh, I've been meaning to email about this. There's a file in the source tree
but it's buggy. The code in your FAQ seems ok, but I prefer the way I've done
it:

(add-hook 'c-mode-hook
(function
(lambda nil
(if (string-match "pgsql" buffer-file-name)
(progn
(c-set-style "bsd")
(setq c-basic-offset 4)
(setq tab-width 4)
(c-set-offset 'case-label '+)
(setq indent-tabs-mode t)
)
))))

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I use more or less what is in the developers' FAQ (not surprising, since I
contributed it). It works just fine for me. See
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9

We should probably bring the docs in line with that, unless someone with more
emacs-fu than me has something to add.

Oh, I've been meaning to email about this. There's a file in the source tree
but it's buggy. The code in your FAQ seems ok, but I prefer the way I've done
it:

(add-hook 'c-mode-hook
(function
(lambda nil
(if (string-match "pgsql" buffer-file-name)
(progn
(c-set-style "bsd")
(setq c-basic-offset 4)
(setq tab-width 4)
(c-set-offset 'case-label '+)
(setq indent-tabs-mode t)
)
))))

Would you please send me a patch to FAQ_DEV.html? I can't figure out
how this new version would affect what is there now.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I am still waiting for an actual patch to the developer's FAQ for this.

---------------------------------------------------------------------------

Gregory Stark wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I use more or less what is in the developers' FAQ (not surprising, since I
contributed it). It works just fine for me. See
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9

We should probably bring the docs in line with that, unless someone with more
emacs-fu than me has something to add.

Oh, I've been meaning to email about this. There's a file in the source tree
but it's buggy. The code in your FAQ seems ok, but I prefer the way I've done
it:

(add-hook 'c-mode-hook
(function
(lambda nil
(if (string-match "pgsql" buffer-file-name)
(progn
(c-set-style "bsd")
(setq c-basic-offset 4)
(setq tab-width 4)
(c-set-offset 'case-label '+)
(setq indent-tabs-mode t)
)
))))

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I will try to draw all this together today or tomorrow. It's not only
the FAQ that should be patched - the docs and the FAQ should agree with
each other.

In fact, this info arguably belongs in one place only. Which should it be?

cheers

andrew

Bruce Momjian wrote:

Andrew Dunstan wrote:

I will try to draw all this together today or tomorrow. It's not only
the FAQ that should be patched - the docs and the FAQ should agree with
each other.

Right.

In fact, this info arguably belongs in one place only. Which should it be?

Uh, if you put it in the docs, I can reference it from the FAQ, but not
the other way around, so I think the documentation is best.

---------------------------------------------------------------------------

cheers

andrew

Bruce Momjian wrote:

I am still waiting for an actual patch to the developer's FAQ for this.

---------------------------------------------------------------------------

Gregory Stark wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I use more or less what is in the developers' FAQ (not surprising, since I
contributed it). It works just fine for me. See
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9

We should probably bring the docs in line with that, unless someone with more
emacs-fu than me has something to add.

Oh, I've been meaning to email about this. There's a file in the source tree
but it's buggy. The code in your FAQ seems ok, but I prefer the way I've done
it:

(add-hook 'c-mode-hook
(function
(lambda nil
(if (string-match "pgsql" buffer-file-name)
(progn
(c-set-style "bsd")
(setq c-basic-offset 4)
(setq tab-width 4)
(c-set-offset 'case-label '+)
(setq indent-tabs-mode t)
)
))))

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Andrew Dunstan wrote:

I will try to draw all this together today or tomorrow. It's not only
the FAQ that should be patched - the docs and the FAQ should agree with
each other.

Right.

In fact, this info arguably belongs in one place only. Which should it be?

Uh, if you put it in the docs, I can reference it from the FAQ, but not
the other way around, so I think the documentation is best.

Looking at this further, I am wondering if it would not be better to put
sample .emacs and .vimrc files in the source (in, say, src.tools).

The docs/FAQ would just say that we use BSD style with tab space 4 and
refer to the sample files.

thoughts?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Looking at this further, I am wondering if it would not be better to put
sample .emacs and .vimrc files in the source (in, say, src.tools).

Seems reasonable. I was about to say "what if they're just looking at
the docs and don't have a source tree?" ... but anyone editing the code
has got a copy of the source tree ...

regards, tom lane

On Wed, Aug 30, 2006 at 11:06:01AM -0400, Andrew Dunstan wrote:

Bruce Momjian wrote:

Andrew Dunstan wrote:

I will try to draw all this together today or tomorrow. It's not only
the FAQ that should be patched - the docs and the FAQ should agree with
each other.

Right.

In fact, this info arguably belongs in one place only. Which
should it be?

Uh, if you put it in the docs, I can reference it from the FAQ, but
not the other way around, so I think the documentation is best.

Looking at this further, I am wondering if it would not be better to
put sample .emacs and .vimrc files in the source (in, say,
src.tools).

The docs/FAQ would just say that we use BSD style with tab space 4
and refer to the sample files.

thoughts?

If we put them in a place that's visible before you get the source, we
can help people use the settings globally :)

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

David Fetter wrote:

Looking at this further, I am wondering if it would not be better to
put sample .emacs and .vimrc files in the source (in, say,
src.tools).

The docs/FAQ would just say that we use BSD style with tab space 4
and refer to the sample files.

thoughts?

If we put them in a place that's visible before you get the source, we
can help people use the settings globally :)

The likely level of our influence on someone who hasn't used the
settings and isn't editing our source code is approximately equal to the
influence of Pluto's gravitational field on your mood when you got out
of bed this morning.

cheers

andrew

Andrew Dunstan wrote:

David Fetter wrote:

If we put them in a place that's visible before you get the source, we
can help people use the settings globally :)

The likely level of our influence on someone who hasn't used the
settings and isn't editing our source code is approximately equal to the
influence of Pluto's gravitational field on your mood when you got out
of bed this morning.

I always wondered what affected his mood when he got out of bed this
morning. Now I know!

It's amazing the things you can learn by lurking here... :-)

--
Kevin Brown kevin@sysexperts.com

On Wed, Aug 30, 2006 at 06:28:06PM -0400, Andrew Dunstan wrote:

David Fetter wrote:

thoughts?

If we put them in a place that's visible before you get the source,
we can help people use the settings globally :)

The likely level of our influence on someone who hasn't used the
settings and isn't editing our source code is approximately equal to
the influence of Pluto's gravitational field on your mood when you
got out of bed this morning.

I want to believe! ;)

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

David Fetter wrote:

On Wed, Aug 30, 2006 at 06:28:06PM -0400, Andrew Dunstan wrote:

David Fetter wrote:

thoughts?

If we put them in a place that's visible before you get the source,
we can help people use the settings globally :)

The likely level of our influence on someone who hasn't used the
settings and isn't editing our source code is approximately equal to
the influence of Pluto's gravitational field on your mood when you
got out of bed this morning.

I want to believe! ;)

You will pull Joe from my cold dead hands!

Cheers,
D

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Andrew Dunstan wrote:

Looking at this further, I am wondering if it would not be better to put
sample .emacs and .vimrc files in the source (in, say, src.tools).

What does people use in .vimrc? Mine has simply this:

: set cinoptions=(0
: set tabstop=4
: set shiftwidth=4

wrapped in a

:if match(getcwd(), "/home/alvherre/Code/CVS/pgsql") == 0
...
:endif

of course.

I find it to be all I need to get the style Postgres uses. (On the
other hand, default cinoptions may be different on other versions of
Vim)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Wed, Aug 30, 2006 at 09:48:01PM -0400, Alvaro Herrera wrote:

Andrew Dunstan wrote:

Looking at this further, I am wondering if it would not be better to put
sample .emacs and .vimrc files in the source (in, say, src.tools).

What does people use in .vimrc? Mine has simply this:

: set cinoptions=(0
: set tabstop=4
: set shiftwidth=4

Has anyone considered adding vi/vim options to the files themselves?
Granted, not a trivial task, but it would ensure anyone using vim would
have the correct settings. I don't know if emacs has the same ability
(I've seen the "Hey emacs, this is a C file" stuff...)
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:

"Jim C. Nasby" <jim@nasby.net> writes:

Has anyone considered adding vi/vim options to the files themselves?
Granted, not a trivial task, but it would ensure anyone using vim would
have the correct settings. I don't know if emacs has the same ability
(I've seen the "Hey emacs, this is a C file" stuff...)

Certainly it does; it even knows that certain variables are safe to allow
files to set without warning the user and it has the indention marked as such.

I think this would be what you would want.

/*
* Local variables:
* eval: (c-set-style "bsd")
* tab-width: 4
* c-basic-offset: 4
* End:
*/

But it would have to be on the end of every single file which would be pretty
heavyweight.

Yeah, which is the real question... do people think it's worth it enough
to move towards doing that? Of course the nice thing is that *anyone*
(even me :) ) could produce a patch to do that.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

Jim C. Nasby wrote:

On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:

"Jim C. Nasby" <jim@nasby.net> writes:

Has anyone considered adding vi/vim options to the files themselves?
Granted, not a trivial task, but it would ensure anyone using vim would
have the correct settings. I don't know if emacs has the same ability
(I've seen the "Hey emacs, this is a C file" stuff...)

Certainly it does; it even knows that certain variables are safe to allow
files to set without warning the user and it has the indention marked as such.

I think this would be what you would want.

/*
* Local variables:
* eval: (c-set-style "bsd")
* tab-width: 4
* c-basic-offset: 4
* End:
*/

But it would have to be on the end of every single file which would be pretty
heavyweight.

Yeah, which is the real question... do people think it's worth it enough
to move towards doing that? Of course the nice thing is that *anyone*
(even me :) ) could produce a patch to do that.

No. It is obstructive and hard to maintain.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Jim C. Nasby wrote:

On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:

"Jim C. Nasby" <jim@nasby.net> writes:

Has anyone considered adding vi/vim options to the files themselves?
Granted, not a trivial task, but it would ensure anyone using vim would
have the correct settings. I don't know if emacs has the same ability
(I've seen the "Hey emacs, this is a C file" stuff...)

Certainly it does; it even knows that certain variables are safe to allow
files to set without warning the user and it has the indention marked as such.

I think this would be what you would want.

/*
* Local variables:
* eval: (c-set-style "bsd")
* tab-width: 4
* c-basic-offset: 4
* End:
*/

But it would have to be on the end of every single file which would be pretty
heavyweight.

Yeah, which is the real question... do people think it's worth it enough
to move towards doing that? Of course the nice thing is that *anyone*
(even me :) ) could produce a patch to do that.

No, please don't. Greg is right, it is way too heavyweight. It's not a
one off exercise. You'd have to check every new file.

cheers

andrew