I wrote:
> Piotr Stefaniak writes:
>> Sorry, but GNU indent already uses -kr for something else and I would
>> like FreeBSD indent have something like that under the same name.
>> Besides, indent has too many options and this one doesn't look like
>> particularly desired by anyone. It's
Piotr Stefaniak writes:
> On 19/05/2019 19.27, Tom Lane wrote:
>> Piotr Stefaniak writes:
>>> I think it's safe to assume that upstream can drop support for K
>>> parameters altogether.
>> Cool. I already created the switch, but maybe we could have it
>> default to -nkr?
> Sorry, but GNU
On 19/05/2019 19.27, Tom Lane wrote:
> Piotr Stefaniak writes:
>> On 17/05/2019 16.48, Tom Lane wrote:
>>> It doesn't really seem practical to me to make the lookahead function
>>> smart enough to tell the difference between attributes and K
>>> parameter declarations. What I'm thinking of doing
Piotr Stefaniak writes:
> On 17/05/2019 16.48, Tom Lane wrote:
>> It doesn't really seem practical to me to make the lookahead function
>> smart enough to tell the difference between attributes and K
>> parameter declarations. What I'm thinking of doing to have an
>> upstreamable patch is to
On 17/05/2019 16.48, Tom Lane wrote:
> I wrote:
A small problem with the "rejiggering" is that it now makes the wrong
choice for K function definitions, causing them to be weirdly
indented. For our purposes, that's a non-problem so I'm not excited
about trying to make it smart
I wrote:
>>> A small problem with the "rejiggering" is that it now makes the wrong
>>> choice for K function definitions, causing them to be weirdly
>>> indented. For our purposes, that's a non-problem so I'm not excited
>>> about trying to make it smart enough to recognize those. We do have
>>>
Thomas Munro writes:
> On Thu, May 16, 2019 at 9:17 AM Tom Lane wrote:
>> A small problem with the "rejiggering" is that it now makes the wrong
>> choice for K function definitions, causing them to be weirdly
>> indented. For our purposes, that's a non-problem so I'm not excited
>> about trying
On Thu, May 16, 2019 at 9:17 AM Tom Lane wrote:
> I wrote:
> > I experimented with fixing this. I was able to get pg_bsd_indent to
> > distinguish multi-line function declarations from definitions, but it
> > turns out that it doesn't help your concern about the lines being too
> > long after
Thomas Munro writes:
> I tried teaching pgindent's post_indent subroutine to unmangle the
> multi-line declarations it mangles. That produces correct
> indentation! But can also produce lines that exceed the column limit
> we would normally wrap at (of course, because pg_bsd_indent had less
>
On Mon, Jan 28, 2019 at 9:48 PM Thomas Munro
wrote:
> On Mon, Jan 28, 2019 at 8:08 PM Michael Paquier wrote:
> > If you could get pgindent smarter in this area, it would be really
> > nice..
>
> Ah, it's not indent doing it, it's pgindent's post_indent subroutine
> trying to correct the effects
On Mon, Jan 28, 2019 at 8:08 PM Michael Paquier wrote:
> On Mon, Jan 28, 2019 at 12:28:30AM -0500, Tom Lane wrote:
> > Thomas Munro writes:
> >> That's ... annoying. I wish indent wouldn't do that, because it means
> >> that my declarations get moved around every time I write code.
> >
> > If
On Mon, Jan 28, 2019 at 12:28:30AM -0500, Tom Lane wrote:
> Thomas Munro writes:
>> That's ... annoying. I wish indent wouldn't do that, because it means
>> that my declarations get moved around every time I write code.
>
> If you can fix it, I'd vote for accepting the patch. I don't
Thomas Munro writes:
> For a while I've been baffled by that: the first arguments of later
> lines don't line up with that of the first line, but they're also not
> in a constant column (it varies from function to function), and it's
> also not caused by 8-space vs 4-space confusion. It was only
Hello,
Using either the .dir-locals.el settings or the "more complete"
src/tools/editors/emacs.samples, I have never convinced Emacs to
produce multi-line function declarations in .h files that satisfy
pg_indent.
For example, latch.c has the following definition:
int
14 matches
Mail list logo
