On Tue, Jun 10, 2008 at 11:18 AM, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 02:11:26PM -0400, Paul Smith wrote: >> On Tue, 2008-06-10 at 10:44 -0700, Patrick Horgan wrote: >> > In the original K & R C book there was an exercise to build entab and >> > detab programs--easy to do with FSM. I bet if you search with google >> > you can find a million of them. (Perhaps a million and seventeen). >> >> If that's all you want a trivial perl script will do as well: >> >> perl -pe 's/^ /\t/' >> >> (untested). This is good enough for make, which only cares about the >> first character on the line. > > Yet for many simple uses (think windoze users that do > not know how to insert tabs) it would be a usefull > extension with: > .ASSUMETAB: > > So whenever Make today says "did you mean a tab" then > it would instead just assume so. > > I know that adding the above to existing scripts would > break them, but I also know that for example at my job > people has an additional editor solely for the purpose > of editing Makefiles. > And the Makefile they use would work perfectly fine > > if gmake just assumed a tab when it saw > > target: prerequisite > <8 spaces>command > > I would never use this on Linux but I could see > benefits on Windoze simply due to the Windoze users > inherited bad habbits (and tool issues). > > Sam
Then comes the issue of style. Different programs, as well as different users define tabs to be different amounts of spaces when editing. \t preceding each rule is just a much simpler, cleaner rule to follow. IMO (I'm representing myself; not the make folks) if you don't play by the rules you have one of two choices: 1. Play the game as required. 2. Don't play. -Garrett PS Using awk, perl, sed, tcl, ... to reformat text is most likely the best means of solving the problem. _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
