On Wed, 2013-09-04 at 18:15 -0400, David Boyce wrote: > On Wed, Sep 4, 2013 at 4:42 PM, Paul D. Smith > <invalid.nore...@gnu.org> 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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make