On Tue, Jun 10, 2014 at 10:36:07AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Jun 09, 2014 at 09:04:02PM -0400, Peter Eisentraut wrote:
> >> I'd consider just getting rid of the
> >>
> >> (c-file-style . "bsd")
> >>
> >> setting in .dir-locals.el and put the actual interesting setti
Noah Misch writes:
> On Mon, Jun 09, 2014 at 09:04:02PM -0400, Peter Eisentraut wrote:
>> On Sun, 2014-06-08 at 21:55 -0400, Noah Misch wrote:
>>> After upgrading to GNU Emacs 23.4.1 from a version predating directory-local
>>> variables, I saw switch/case indentation go on the fritz. My hooks we
On Mon, Jun 09, 2014 at 09:04:02PM -0400, Peter Eisentraut wrote:
> On Sun, 2014-06-08 at 21:55 -0400, Noah Misch wrote:
> > After upgrading to GNU Emacs 23.4.1 from a version predating directory-local
> > variables, I saw switch/case indentation go on the fritz. My hooks were
> > issuing (c-set-s
On Sun, 2014-06-08 at 21:55 -0400, Noah Misch wrote:
> After upgrading to GNU Emacs 23.4.1 from a version predating directory-local
> variables, I saw switch/case indentation go on the fritz. My hooks were
> issuing (c-set-style "postgresql"), but ".dir-locals.el" set it back to plain
> "bsd" styl
On Mon, Jun 09, 2014 at 10:52:34AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Aug 07, 2013 at 07:57:53AM -0400, Peter Eisentraut wrote:
> >> Did anyone have any outstanding concerns about this latest version? I
> >> thought it looked ready to commit.
>
> > After upgrading to GNU Ema
Noah Misch writes:
> On Wed, Aug 07, 2013 at 07:57:53AM -0400, Peter Eisentraut wrote:
>> Did anyone have any outstanding concerns about this latest version? I
>> thought it looked ready to commit.
> After upgrading to GNU Emacs 23.4.1 from a version predating directory-local
> variables, I saw
On Wed, Aug 07, 2013 at 07:57:53AM -0400, Peter Eisentraut wrote:
> On 7/2/13 8:42 PM, Peter Eisentraut wrote:
> > Updated files with changes:
> >
> > - adjusted fill-column to 78, per Noah
> > - added c-file-style, per Andrew
> > - support both "postgresql" and "postgres" directory names
> > - us
On 2014-02-06 10:24:34 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Nah, not for that ;). I mean I haven't seen any replacement for pgindent
> > that generates equivalent variable indentations.
>
> Seems odd. I thought netbsd's indent was pretty much the granddaddy of
> them all --- so you
Andres Freund writes:
> Nah, not for that ;). I mean I haven't seen any replacement for pgindent
> that generates equivalent variable indentations.
Seems odd. I thought netbsd's indent was pretty much the granddaddy of
them all --- so you'd expect newer tools to be able to replicate that
style.
On 2014-02-06 10:04:54 -0500, Tom Lane wrote:
> Andres Freund writes:
> > What I haven't seen in any tool yet is something to resemble our
> > indentation style for variable declarations. Do we feel that's a
> > dealbreaker for any tool?
>
> Well, we're unlikely to change pgindent's rules to conf
Andres Freund writes:
> What I haven't seen in any tool yet is something to resemble our
> indentation style for variable declarations. Do we feel that's a
> dealbreaker for any tool?
Well, we're unlikely to change pgindent's rules to conform to the
behavior of some random emacs mode, if that's w
Andres Freund wrote:
> What I haven't seen in any tool yet is something to resemble our
> indentation style for variable declarations. Do we feel that's a
> dealbreaker for any tool?
I find our style more aesthetically pleasing than any other I've seen;
but anyway the changes if we used a tool th
On 2013-07-21 02:06:02 +0100, Greg Stark wrote:
> On Thu, Jun 27, 2013 at 10:31 PM, Tom Lane wrote:
> >
> > AFAIR, no one has ever done a serious comparison to anything except GNU
> > indent, and (at least at the time) it seemed to have bugs as bad as
> > pgindent's, just different ones. I'm cert
On 7/20/13, 9:06 PM, Greg Stark wrote:
> In theory this tool is promising though since it works by looking at
> the llvm bytecode to determine what the real syntax is. It should be
> able to handle the typedef issues we have with most of the the tools.
Since clang-format has no options to specify
On Fri, Jan 31, 2014 at 11:57:28AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > OK. I have updated entab.c to support this new ability as -m. When
> > should it be run this against HEAD and supported back branches? Probably
> > when we run pgindent for 9.4.
>
> Yeah. The whole point is t
Bruce Momjian writes:
> OK. I have updated entab.c to support this new ability as -m. When
> should it be run this against HEAD and supported back branches? Probably
> when we run pgindent for 9.4.
Yeah. The whole point is to keep the branches in sync for patching,
so we need to do them all at
On Fri, Jan 31, 2014 at 08:58:21AM -0500, Robert Haas wrote:
> > OK, eight hours later, I have the results for only removing tabs after
> > periods in comments:
> >
> > http://momjian.us/expire/entab_comment.v2.cdiff
> > http://momjian.us/expire/entab_comment.v2.pdiff
> > ht
On Thu, Jan 30, 2014 at 11:06 PM, Bruce Momjian wrote:
> On Thu, Jan 30, 2014 at 03:36:48PM -0500, Bruce Momjian wrote:
>> On Thu, Jan 30, 2014 at 03:32:27PM -0500, Robert Haas wrote:
>> > Or this:
>> >
>> > - mp_int_copy(a, b); /* ok: 0 <= r < b */
>> > - mp_int_copy(&q, a); /* ok: q <= a */
>>
On Thu, Jan 30, 2014 at 03:36:48PM -0500, Bruce Momjian wrote:
> On Thu, Jan 30, 2014 at 03:32:27PM -0500, Robert Haas wrote:
> > Or this:
> >
> > - mp_int_copy(a, b); /* ok: 0 <= r < b */
> > - mp_int_copy(&q, a); /* ok: q <= a */
> > + mp_int_copy(a, b); /* ok: 0 <= r < b */
> > + mp_int_copy
On Thu, Jan 30, 2014 at 03:32:27PM -0500, Robert Haas wrote:
> Or this:
>
> - mp_int_copy(a, b); /* ok: 0 <= r < b */
> - mp_int_copy(&q, a); /* ok: q <= a */
> + mp_int_copy(a, b); /* ok: 0 <= r < b */
> + mp_int_copy(&q, a); /* ok: q <= a */
>
> I do agree with you some of the changes-a
Alvaro Herrera writes:
> Robert Haas escribió:
>> I don't have any comment on that specific point, but I took a quick
>> look through one of these diffs and it looks like a lot of churn for
>> no improvement. So I'm not sure what we want to do here, but I don't
>> think it's this.
> I, on the co
On Thu, Jan 30, 2014 at 3:04 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian wrote:
>> > I compute 6627 lines as modified. What I did not do is handle _only_
>> > cases with periods before the tabs. Should I try that?
>>
>> I don't have any c
Robert Haas escribió:
> On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian wrote:
> > I compute 6627 lines as modified. What I did not do is handle _only_
> > cases with periods before the tabs. Should I try that?
>
> I don't have any comment on that specific point, but I took a quick
> look thro
On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian wrote:
> On Wed, Jan 29, 2014 at 07:31:29PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>> > I have cleaned up entab.c so I am ready to add a new option that removes
>> > tabs from only comments. Would you like me to create that and provide a
>
On Wed, Jan 29, 2014 at 07:31:29PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have cleaned up entab.c so I am ready to add a new option that removes
> > tabs from only comments. Would you like me to create that and provide a
> > diff at a URL? It would have to be run against all back b
Bruce Momjian writes:
> I have cleaned up entab.c so I am ready to add a new option that removes
> tabs from only comments. Would you like me to create that and provide a
> diff at a URL? It would have to be run against all back branches.
If you think you can actually tell the difference reliab
On Wed, Jan 29, 2014 at 12:53:02AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > If this only affects a handful of places, then sure, let's go ahead
> > and fix it. But if it's going to create a massive enough diff that
> > we've gotta think about back-patching it, then IMHO it's totally not
>
Robert Haas writes:
> If this only affects a handful of places, then sure, let's go ahead
> and fix it. But if it's going to create a massive enough diff that
> we've gotta think about back-patching it, then IMHO it's totally not
> worth it.
A quick grep search says there are well over 3000 comm
On 2014-01-28 18:39:43 -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I see I already asked about entab -s 3. Let me see how hard it would be
> > to modify entab.
>
> I cannot tell you what to waste your time on, of course, but I wonder if
> it'd be better spent trying to make somet
On Tue, Jan 28, 2014 at 11:03 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Tue, Jan 28, 2014 at 10:40:10PM -0500, Tom Lane wrote:
>>> TBH I'm not sure we should be changing pgindent at this late date, even if
>>> there is a good fix for its minor annoyances. When you changed its wrap
>>> be
Bruce Momjian writes:
> On Tue, Jan 28, 2014 at 10:40:10PM -0500, Tom Lane wrote:
>> TBH I'm not sure we should be changing pgindent at this late date, even if
>> there is a good fix for its minor annoyances. When you changed its wrap
>> behavior in 8.1, I spent the next several years cursing tha
On Tue, Jan 28, 2014 at 10:40:10PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I see I already asked about entab -s 3. Let me see how hard it would be
> > to modify entab.
>
> TBH I'm not sure we should be changing pgindent at this late date, even if
> there is a good fix for its minor an
Bruce Momjian writes:
> I see I already asked about entab -s 3. Let me see how hard it would be
> to modify entab.
TBH I'm not sure we should be changing pgindent at this late date, even if
there is a good fix for its minor annoyances. When you changed its wrap
behavior in 8.1, I spent the next
On Tue, Jan 28, 2014 at 06:39:43PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I see I already asked about entab -s 3. Let me see how hard it would be
> > to modify entab.
>
> I cannot tell you what to waste your time on, of course, but I wonder if
> it'd be better spent trying t
Bruce Momjian wrote:
>
> I see I already asked about entab -s 3. Let me see how hard it would be
> to modify entab.
I cannot tell you what to waste your time on, of course, but I wonder if
it'd be better spent trying to make something like astyle work for us.
The entab/pg_bsd_indent combo is a b
On Thu, Jun 27, 2013 at 09:54:45PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Should we be using entab -s 3?
>
> IIUC, that wouldn't affect leading whitespace at all. What it would
> affect I think (outside of comment blocks) is whitespace between code
> and a same-line /* ... */ comment
On Thu, Jun 27, 2013 at 05:31:54PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Noah Misch wrote:
> >> Note that emacs and pgindent remain at odds over interior tabs in comments.
> >> When pgindent finds a double-space (typically after a sentence) ending at a
> >> tab stop, it replaces the
Peter Eisentraut writes:
> Did anyone have any outstanding concerns about this latest version? I
> thought it looked ready to commit.
I wanted to have another round at trying it here and get a better
understanding at my failures of the previous time, but that's not a
blocker at all. I had anothe
On 7/2/13 8:42 PM, Peter Eisentraut wrote:
> Updated files with changes:
>
> - adjusted fill-column to 78, per Noah
> - added c-file-style, per Andrew
> - support both "postgresql" and "postgres" directory names
> - use defun instead of lambda, per Dimitri
> - put Perl configuration back into emac
On Thu, Jun 27, 2013 at 10:31 PM, Tom Lane wrote:
>
> AFAIR, no one has ever done a serious comparison to anything except GNU
> indent, and (at least at the time) it seemed to have bugs as bad as
> pgindent's, just different ones. I'm certainly open to another choice
> as long as we don't lose on
Updated files with changes:
- adjusted fill-column to 78, per Noah
- added c-file-style, per Andrew
- support both "postgresql" and "postgres" directory names
- use defun instead of lambda, per Dimitri
- put Perl configuration back into emacs.samples, for Tom
I also added configuration of c-auto-
On Thu, Jun 27, 2013 at 09:54:45PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Should we be using entab -s 3?
>
> IIUC, that wouldn't affect leading whitespace at all. What it would
> affect I think (outside of comment blocks) is whitespace between code
> and a same-line /* ... */ comment
Bruce Momjian writes:
> Should we be using entab -s 3?
IIUC, that wouldn't affect leading whitespace at all. What it would
affect I think (outside of comment blocks) is whitespace between code
and a same-line /* ... */ comment. Personally I'd prefer that a
tab-stop-aligned /* ... */ comment alw
On Thu, Jun 27, 2013 at 05:31:54PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Noah Misch wrote:
> >> Note that emacs and pgindent remain at odds over interior tabs in comments.
> >> When pgindent finds a double-space (typically after a sentence) ending at a
> >> tab stop, it replaces the
Tom Lane wrote:
> Andres Freund writes:
>
> > Being at least one of the persons having mentioned astyle to Alvaro, I
> > had tested that once and I thought the results were resembling something
> > reasonable after an hour of fiddling or so. But there were certain
> > things that I could not be m
Andres Freund writes:
> I think before doing any serious testing we would need to lay out how
> many changes and what changes in formatting we would allow and what kind
> of enforced formatting rules we think are required.
Well, we certainly never applied any such analysis to pgindent. I
persona
On 2013-06-27 17:31:54 -0400, Tom Lane wrote:
> > Really, we should get out of patched BSD indent entirely already. How
> > about astyle, for instance? I'm told that with some sensible options,
> > the diff to what we have now is not very large, and several things
> > actually become sensible (su
Alvaro Herrera writes:
> Noah Misch wrote:
>> Note that emacs and pgindent remain at odds over interior tabs in comments.
>> When pgindent finds a double-space (typically after a sentence) ending at a
>> tab stop, it replaces the double-space with a tab. c-fill-paragraph will
>> convert that tab
On Thu, Jun 27, 2013 at 03:51:15PM -0400, Alvaro Herrera wrote:
> Noah Misch wrote:
>
> > Note that emacs and pgindent remain at odds over interior tabs in comments.
> > When pgindent finds a double-space (typically after a sentence) ending at a
> > tab stop, it replaces the double-space with a ta
Noah Misch wrote:
> Note that emacs and pgindent remain at odds over interior tabs in comments.
> When pgindent finds a double-space (typically after a sentence) ending at a
> tab stop, it replaces the double-space with a tab. c-fill-paragraph will
> convert that tab to a *single* space, and that
On Tue, Jun 25, 2013 at 11:17:47PM -0400, Peter Eisentraut wrote:
> On Sun, 2013-06-23 at 16:03 -0400, Noah Misch wrote:
> > > ((c-mode . ((c-basic-offset . 4)
> > > (fill-column . 79)
> >
> > I don't know whether you'd consider it to fall within the scope of this
> > update, but 78 is
On 26/06/13 10:51, Dimitri Fontaine wrote:
Peter Eisentraut writes:
$ git clone git://git.postgresql.org/git/postgresql.git
Cloning into 'postgresql'...
I can reproduce that here. I don't know why I have those postgres dirs
then, and I'm pretty confused about my round of testing now.
Maybe
Peter Eisentraut writes:
>> emacs -q src/backend/commands/extension.c
>> emacs -q -l ../emacs.samples src/backend/commands/extension.c
>
> Well, the first one uses 8-space tabs, the second 4-space tabs, so they
> look completely different. I'm not sure what you are trying to point
> out.
On Sun, 2013-06-23 at 16:37 -0400, Tom Lane wrote:
> I'm un-thrilled with this as well, though for a slightly different
> reason: we have a policy that the PG sources should be tool agnostic,
> and in fact removed file-local emacs settings awhile back because of
> that.
We don't want to keep the t
On Sun, 2013-06-23 at 16:03 -0400, Noah Misch wrote:
> > ((c-mode . ((c-basic-offset . 4)
> > (fill-column . 79)
>
> I don't know whether you'd consider it to fall within the scope of this
> update, but 78 is the fill-column setting that matches pgindent.
Well, well, well. I did some
On Sun, 2013-06-23 at 16:11 -0400, Andrew Dunstan wrote:
> > The idea is a very good one in principle, but my short experiment with
> > the provided .dir-locals.el didn't give me BSD style brace
> > indentation. It works if we can do those "unsafe" things, but then we
> > surely don't want to ha
On Fri, 2013-06-21 at 11:20 +0200, Dimitri Fontaine wrote:
> I've tested that on a new git clone and with the `emacs -q` command so
> as not to load any of my local setup. While the indentation seemed ok,
> the placement of the comments seems way off:
>
> Compare what you see using those commands:
Andrew Dunstan writes:
> The idea is a very good one in principle, but my short experiment with
> the provided .dir-locals.el didn't give me BSD style brace indentation.
> It works if we can do those "unsafe" things, but then we surely don't
> want to have a user prompted to accept the settings
On 06/23/2013 03:43 PM, Andrew Dunstan wrote:
The idea is a very good one in principle, but my short experiment with
the provided .dir-locals.el didn't give me BSD style brace
indentation. It works if we can do those "unsafe" things, but then we
surely don't want to have a user prompted to
On Thu, Jun 13, 2013 at 09:27:07PM -0400, Peter Eisentraut wrote:
> I think the suggested emacs configuration snippets in
> src/tools/editors/emacs.samples no longer represent current best
> practices. I have come up with some newer things that I'd like to
> propose for review.
> ((c-mode . ((c-b
On 06/13/2013 09:27 PM, Peter Eisentraut wrote:
I think the suggested emacs configuration snippets in
src/tools/editors/emacs.samples no longer represent current best
practices. I have come up with some newer things that I'd like to
propose for review.
First, I propose adding a .dir-locals.el
Hi,
Peter Eisentraut writes:
> I think the suggested emacs configuration snippets in
> src/tools/editors/emacs.samples no longer represent current best
> practices. I have come up with some newer things that I'd like to
> propose for review.
Thanks for doing that!
> First, I propose adding a .
On Thu, Jun 13, 2013 at 6:27 PM, Peter Eisentraut wrote:
> First, I propose adding a .dir-locals.el file to the top-level directory
> with basic emacs settings. These get applied automatically. This
> especially covers the particular tab and indentation settings that
> PostgreSQL uses. With thi
I think the suggested emacs configuration snippets in
src/tools/editors/emacs.samples no longer represent current best
practices. I have come up with some newer things that I'd like to
propose for review.
First, I propose adding a .dir-locals.el file to the top-level directory
with basic emacs se
64 matches
Mail list logo
