Thread: Coding style for emacs
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? Regards,Jeff Davis
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 '+) (setqindent-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: > 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 >> > >
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 solutionssince 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
Bruce Momjian <bruce@momjian.us> writes:
> Jim C. Nasby wrote:
>> On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:
>>> Has anyone considered adding vi/vim options to the files themselves?
>>
>> Yeah, which is the real question... do people think it's worth it enough
>> to move towards doing that?
> No. It is obstructive and hard to maintain.
Actually, sooner than doing that I'd rather see us move to 8-space tabs...
but I suppose that war was over long ago.
regards, tom lane
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. Andrew, I am still waiting for the emacs startup script modification patch. -- 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: > > 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. > > Andrew, I am still waiting for the emacs startup script modification > patch. Sorry, found it applied. My mistake. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +