Bruno Haible wrote:
>> *** NEWS.orig2009-12-09 20:16:50.0 +0100
>> --- NEWS 2009-12-09 19:39:00.0 +0100
>> ***
>> *** 6,11
>> --- 6,15
>>
>> DateModules Changes
>>
>> + 2009-12-09 * Most source code files have been c
> *** NEWS.orig 2009-12-09 20:16:50.0 +0100
> --- NEWS 2009-12-09 19:39:00.0 +0100
> ***
> *** 6,11
> --- 6,15
>
> DateModules Changes
>
> + 2009-12-09 * Most source code files have been converted to
> +
I'm not sure `indent` is being kept up to date TBH.
As Simon mentioned, David Ingamells released indent 2.2.10 early this
year after a lapse of some years. So perhaps sending a report to
bug-indent about the missing type definitions, etc. would have some
effect.
-l80
I strongly suggest
Pádraig Brady writes:
>> I don't care much about coding styles conventions, but I care about
>> consistency. Moving away from the default style of GNU indent in gnulib
>> seems a bit inconsistent to me. I can't find anything about tab vs
>> space in the coding standard though. Thoughts?
>
> I'
On 10/12/09 14:33, Simon Josefsson wrote:
Bruno Haible writes:
Simon Josefsson wrote:
Is there a need to modify how 'indent' works here? Or document how to
make indent do the right thing? When making substantial changes to
gnulib code, I tend to run 'indent' on the code to make sure I'm
fol
Bruno Haible writes:
> Simon Josefsson wrote:
>> Is there a need to modify how 'indent' works here? Or document how to
>> make indent do the right thing? When making substantial changes to
>> gnulib code, I tend to run 'indent' on the code to make sure I'm
>> following the right style -- but th
Simon Josefsson wrote:
> Is there a need to modify how 'indent' works here? Or document how to
> make indent do the right thing? When making substantial changes to
> gnulib code, I tend to run 'indent' on the code to make sure I'm
> following the right style -- but that would add tabs, wouldn't i
Simon Josefsson wrote:
> Is there a need to modify how 'indent' works here? Or document how to
> make indent do the right thing? When making substantial changes to
> gnulib code, I tend to run 'indent' on the code to make sure I'm
> following the right style -- but that would add tabs, wouldn't i
Is there a need to modify how 'indent' works here? Or document how to
make indent do the right thing? When making substantial changes to
gnulib code, I tend to run 'indent' on the code to make sure I'm
following the right style -- but that would add tabs, wouldn't it?
/Simon
Pádraig Brady wrote:
> s/Spacer/Spaces/
>
> Spaces make me much happier.
> Note after this patch `git blame` is useless without the -w option
> so I would mention that somewhere.
Good point. I'll add this sentence to the README:
When you use "git annotate" or "git blame" with gnulib, it's reco
*** README.orig 2009-12-09 20:16:50.0 +0100
--- README 2009-12-09 19:36:18.0 +0100
How about adding everything in README to gnulib.texi, and generating it?
The README grows and grows, in both length and importance ...
Jim Meyering wrote:
> Bruno Haible wrote:
>> What should I write in the NEWS file, about recommendations for people who
>> have
>> patches on top of gnulib?
>
> We also need a way to keep things in order going forward.
> I.e., a syntax-check style rule that enforces this style.
>
> To that end, p
Bruno Haible wrote:
> What should I write in the NEWS file, about recommendations for people who
> have
> patches on top of gnulib?
We also need a way to keep things in order going forward.
I.e., a syntax-check style rule that enforces this style.
To that end, please prepare a file like the one
Hi Jim, all,
Here's the proposal for untabifying:
- all *.m4 files,
- all *.sh files,
- all *.[chy] files except lib/reg*
The entire patch is at http://www.haible.de/bruno/gnu/gnulib-expand.diff.gz
(768 KB). The interesting parts are below:
1) Changes to NEWS and README (thanks Paolo for t
14 matches
Mail list logo