bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #39943] Add an alternative parsing mode that regards space and


From: Paul Smith
Subject: Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens
Date: Wed, 04 Sep 2013 18:32:43 -0400

On Wed, 2013-09-04 at 18:15 -0400, David Boyce wrote:
> On Wed, Sep 4, 2013 at 4:42 PM, Paul D. Smith
> <address@hidden> wrote:
>         Follow-up Comment #1, bug #39943 (project make):
>         
>         IMO _any_ editor which automatically replaces TABs with spaces
>         should never be
>         considered to be a useful programming tool.  But YMMV of
>         course.
>  
> You know what they say about standards and how great it is that
> there's so many? The Python coding standard calls for no use of tabs
> and thus many people who do Python coding have their editors
> configured to turn tabs into spaces. I do, for example.

I meant, editors which always replace TABs with spaces and can't be
configured to behave other ways.

I have my editor configured to replace TABs with spaces as well, for
many of the file types I use.  But my editor (Emacs, obviously) makes it
quite trivial to use different settings for different types of files.

> Of course it's usually possible to configure the editor to use
> different profiles with different languages but that gets harder since
> makefiles have no standard extension.

Well, most files DO have standard extensions; my attitude is your editor
should never reformat your file unless you specifically request it, and
so I leave the default setting as "no replacement", and only set "please
replace" on those file types where I want/need it.  Most of those,
including Python, DO have standard extensions so it's no problem.

Or, of course, you can also use an editor which is capable of basing its
decisions on more complex features than just an extension :-): Emacs
knows when I'm editing Makefile or makefile as well.


However I do agree that Stu's decision is a good case study when
deciding risk/reward of maintaining backward compatibility :-p.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]