On Feb 9, 2007, at 8:50 AM, Kevin Ballard wrote:

The spacing in MacPorts is a bit non-standard. We have mostly tabs, but there's a bunch of spaces in there as well, and it causes for some interesting indentation.

I propose that all future edits be standardized at either 2-width or 4-width soft tabs (as in, spaces). I'd even be willing to convert all existing tcl files to use spaces instead of tabs in one batch, though that could leave indentation issues (but those can be fixed by hand the next time the file is edited).

Is there any reason to keep tabs? Or any other comments?

Personally I prefer anarchy over regulation. Other than a lack of consistency, has anybody experienced real problems with the way things are? (Yes, I understand that with tabs spacing can get a bit wonky if one person's editor is set to 4 characters per tab, while another has theirs at 8 spaces, and that spacing when files are cat'd to a terminal at 8 spaces can look funny too... but is consistency worth the price of conformity?) James

-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com

_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

The lack of consistent indentation consistently causes me to misread code. On Feb 9, 2007, at 11:55 AM, James Berry wrote:

Personally I prefer anarchy over regulation.

Other than a lack of consistency, has anybody experienced real problems with the way things are? (Yes, I understand that with tabs spacing can get a bit wonky if one person's editor is set to 4 characters per tab, while another has theirs at 8 spaces, and that spacing when files are cat'd to a terminal at 8 spaces can look funny too... but is consistency worth the price of conformity?)

-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com

On Feb 9, 2007, at 11:06, Kevin Ballard wrote:

On Feb 9, 2007, at 12:01 PM, Ryan Schmidt wrote:

...

Is there any reason why we shouldn't

- have tabs at the beginnings of lines to provide indentation - use spaces within a line when we want to do something like align columns

That would seem the most logical solution to me.

Because different editors use different widths for tabs. And people who use editors that don't visually show tabs may not realize that it's tabs and not spaces (I assume that's why there are plenty of lines that start with a few tabs and then have 4 spaces after that).

I assume that's due to the stupid setting available in emacs or vi or whatever editor it is that actually encourages that behavior. The one where they've said "We want to indent to 4-space tabs. However, the editor is configured to print 8 spaces for a tab. Therefore, when we want to indent one level, we will use 4 spaces, and when we want to indent 2 levels, we will use one tab, and when we want to indent three levels, we will use one tab and then 4 spaces." And so forth. I'm convinced such an editor setting exists somewhere, because I have seen this nonsense in other projects too, even to the extreme of 2- space indentation. (Indent sequence: 2 spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.)

...

Using only spaces seems not so good to me, because

- spaces uses 2 or 4 times as much disk space as a tab

Do you honestly believe this is a problem? I'm sure I can spare the few extra kB it might take.

No, not really a problem. I would accept extra disk space if this solution brought significant advantages, but I'm saying it brings drawbacks.

...

- spaces need 2 or 4 times as many presses on the delete key as a tab to remove in my editor

Then you need a better editor. Any modern editor should know how soft tabs work and allow you to delete them just like tabs. What editor are you using?

I use TextWrangler, the free sibbling of BBEdit. Also, if I press the Tab key on the keyboard, it inserts a tab character. Even if I could tell the editor to insert spaces instead, I would not configure my editor this way, because that is not how I want to use my editor in every other text file that I edit. Now I'm curious: What editor do other people use to edit their portfiles?

...

- I can't use my editor's tab width setting to see the amount of indentation I want to see

Is this ever actually a problem? lines should not be indented so much that 4-width soft tabs cause it to go off the end of the line. And besides, given the current state of indentation (mixture of tabs and spaces), this isn't viable with current source.

I'm just saying that you may like 2-space tabs, but I don't. If that's what we standardize on, I'll be unhappy. Someone else may like 3-space tabs, and they'll be unhappy unless we choose that. Why choose at all? Why not let the user choose with their editor's tab width setting? That's what it's for.

On Feb 9, 2007, at 11:43, Kevin Ballard wrote:

On Feb 9, 2007, at 12:39 PM, Ryan Schmidt wrote:

...

I assume that's due to the stupid setting available in emacs or vi or whatever editor it is that actually encourages that behavior. The one where they've said "We want to indent to 4-space tabs. However, the editor is configured to print 8 spaces for a tab. Therefore, when we want to indent one level, we will use 4 spaces, and when we want to indent 2 levels, we will use one tab, and when we want to indent three levels, we will use one tab and then 4 spaces." And so forth. I'm convinced such an editor setting exists somewhere, because I have seen this nonsense in other projects too, even to the extreme of 2-space indentation. (Indent sequence: 2 spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.)

I doubt that's the case. I see this in places where there's 2 tabs followed by 4 spaces. Why would somebody have their tabs set to width 8 and then want to indent 4 for a nesting level? That makes no sense.

It makes no sense to me either, but I have seen it occur, and hadn't come up with another explanation for how it could come about. Perhaps it comes about from one person using an editor that uses tabs, and then someone else who uses an editor that uses spaces. I don't know.

...

No, not really a problem. I would accept extra disk space if this solution brought significant advantages, but I'm saying it brings drawbacks.

Do you view commenting code as a drawback as well? That adds far more disk space than changing tabs to spaces does. The disk space is simply a non-issue.

No, if course I don't object to comments, and I meant to say that I would happily accept the extra disk space needed by using only spaces, if using only spaces brought only advantages. However, I had intended to point out in the rest of my email that I see some disadvantages as a result of this practice.

...

I use TextWrangler, the free sibbling of BBEdit.

Also, if I press the Tab key on the keyboard, it inserts a tab character. Even if I could tell the editor to insert spaces instead, I would not configure my editor this way, because that is not how I want to use my editor in every other text file that I edit.

Funny, I use soft tabs almost exclusively, and dislike it when I have to switch back to hard tabs just to fit the indentation used by a particular text file.

...

Now I'm curious: What editor do other people use to edit their portfiles?

Usually TextMate, but sometimes vim.

...

I'm just saying that you may like 2-space tabs, but I don't. If that's what we standardize on, I'll be unhappy. Someone else may like 3-space tabs, and they'll be unhappy unless we choose that. Why choose at all? Why not let the user choose with their editor's tab width setting? That's what it's for.

Sure, that's what it's for, but it doesn't work. Go look around at the current source. Sure, it's mostly tabs, but I routinely run into spaces mixed among the tabs and it causes indentation problems.

There's a reason that software projects often standardize their coding style, including spacing conventions.

I agree that standardizing the spacing of a software project can be beneficial. I just want to encourage debate about the specific conventions you're proposing. If we do decide on an indentation convention, then a pre-commit hook in the repository should probably enforce it. One point in favor of your suggestion is that it makes the hook script very easy: if the file contains any tab character at all, it does not conform to your conventions. Writing a hook to verify conformance to my suggestion would be more complicated, though I think not impossible.

On 2007-02-09 11:39:20 -0600, Ryan Schmidt wrote:

I assume that's due to the stupid setting available in emacs or vi or whatever editor it is that actually encourages that behavior. The one where they've said "We want to indent to 4-space tabs. However, the editor is configured to print 8 spaces for a tab. Therefore, when we want to indent one level, we will use 4 spaces, and when we want to indent 2 levels, we will use one tab, and when we want to indent three levels, we will use one tab and then 4 spaces." And so forth. I'm convinced such an editor setting exists somewhere, because I have seen this nonsense in other projects too, even to the extreme of 2- space indentation. (Indent sequence: 2 spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.)

A mix of tabs and spaces is bad since it won't look right in diffs, for instance. Moreover, using tabs only is also a bad choice since one can't align columns and a 8-column space is often too much for a single indentation (even though some editors could be configured to use fewer columns, this is not the case of terminals and web browsers). And tabs are often not preserved in copy-paste. So, I'd say: let's use spaces only.

...

...

Using only spaces seems not so good to me, because

- spaces uses 2 or 4 times as much disk space as a tab

Do you honestly believe this is a problem? I'm sure I can spare the few extra kB it might take.

No, not really a problem. I would accept extra disk space if this

and compared to all the other files on a disk (in particular videos, images, binaries), one shouldn't noticed the difference.

solution brought significant advantages, but I'm saying it brings drawbacks.

I disagree. See above.

Now I'm curious: What editor do other people use to edit their portfiles?

Emacs. One can use: (setq indent-tabs-mode nil) to disable tabs in indentation. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

On Feb 10, 2007, at 20:58, Vincent Lefevre wrote:

On 2007-02-09 11:39:20 -0600, Ryan Schmidt wrote:

...

I assume that's due to the stupid setting available in emacs or vi or whatever editor it is that actually encourages that behavior. The one where they've said "We want to indent to 4-space tabs. However, the editor is configured to print 8 spaces for a tab. Therefore, when we want to indent one level, we will use 4 spaces, and when we want to indent 2 levels, we will use one tab, and when we want to indent three levels, we will use one tab and then 4 spaces." And so forth. I'm convinced such an editor setting exists somewhere, because I have seen this nonsense in other projects too, even to the extreme of 2- space indentation. (Indent sequence: 2 spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.)

A mix of tabs and spaces is bad since it won't look right in diffs, for instance.

What do you mean, won't look right in diffs? What do you mean, mix of tabs and spaces? Do you mean mixing tabs at the beginning of a line, as I described in the quoted section above, or do you mean mixing tabs within a line, as in tabs at the beginning, then some text, then spaces to get over to a second column, as I'm suggesting? Or do you mean any use of tabs at all?

Moreover, using tabs only is also a bad choice since one can't align columns and a 8-column space is often too much for a single indentation (even though some editors could be configured to use fewer columns, this is not the case of terminals and web browsers).

Right, tabs are bad for trying to indent additional columns since different editors have different tab sizes.

And tabs are often not preserved in copy-paste.

Copying within an editor should preserve tabs. If you mean copying text out of a Terminal window and trying to paste it, then yes, tabs probably get lost. I think copying out of a web page and pasting into an editor might also convert tabs to spaces, depending on the browser. I hadn't thought of that. That is to say, I've noticed this problem before, but never thought of "don't use tabs, only use spaces" as a solution to it.

...

No, not really a problem. I would accept extra disk space if this solution brought significant advantages, but I'm saying it brings drawbacks.

I disagree. See above.

Well, you cannot disagree that there is the disadvantage that we all must as a team agree on how many tabs to indent, and that anyone with a differing preference will be out of luck, and that anyone with an editor configured to use tabs will have to jump through some hoops to avoid those tabs now. You may claim that these are not significant drawbacks, and that may be true, but you cannot say that there are no drawbacks at all. Something else to think of if we adopt a convention for spacing and run some automated process to convert all existing portfiles to match this convention: doesn't that make all existing patches in all open bug reports rather difficult to apply? And, nevermind, I think I'm answering my own question: looks like the patch command has an -- ignore-whitespace option which should be just the ticket.

A lot of the macports base files actually were written with 8-space tabs, and then edited later with 4-space soft tabs (at least, that's my assumption based on some tabbing assuming 8-space, and some soft tabs at the end of other tabs that are 4-width long). In any case, using 4-space tabs will not have a detrimental effect on your editor, unless you're editing lines using soft tabs inside base/ when you have your editor set to hard tabs. And I don't see much editing of base/ going on these days (aside from my recent changes), so I think it's safe to say that won't happen ;) In any case, I'm pretty sure there are existing programs to convert tabs, but I can't recall any offhand. Even if there aren't, it should be trivial to write one. And as for the 8-space vs 4-space issue, anybody using an editor set to 4-width tabs already has a problem with these (and I would venture to guess that's most people), so I see no issue with simply converting them and letting people re-indent if they edit a file that has a problem. On Feb 13, 2007, at 12:43 AM, Ryan Schmidt wrote:

On Feb 11, 2007, at 22:56, Kevin Ballard wrote:

...

Are there any more thoughts on this matter?

For now, every line I modify is going to have its hard tabs converted to 4-width soft tabs (and reindented if necessary).

Why will this occur? Is it because this is how your editor is configured, and you do not want to change your editor configuration? If so, then this is not a good reason; if we change the spacing rules as you propose, then you will fix this problem for yourself, but also cause the same problem for me and others with editor settings like mine.

...

I'd really like to do a single pass and convert the entire source base over to 4-width soft tabs, but it seems we have at least one dissenter.

Can we come to an agreement on an overall policy for this?

If nobody else has any objections to converting to all spaces, I'll learn to live with it too. But a question occurs to me: How will you convert the entire source base over to 4-space-width soft tabs? Is there already a program to do that? You can't of course just replace all occurrences of ASCII 0x09 with 4 instances of ASCII 0x20; you'd need anywhere from 1 to 4 spaces depending on preceding characters on the line.

If we agree to convert to all spaces, then I'd like there to be a script that does the above available as part of the MacPorts distribution, or as an installable port, so that I can use that script over any files that I modify, since as I've said, my editor does and will use tabs, and I'll need an easy automated way to replace those with the right number of spaces before committing.

Also, I think the whole reason for this exercise is that not all people have had 4-space-width tabs before, making things look weird when the local editor setting doesn't match the port author's editor setting. What about those portfiles that were written with 8- space-width tabs? How will you identify such files to properly replace the tab characters with between 1 and 8 spaces? Or will you not attempt to identify these files, and just assume all tabs in all files are 4-space-width tabs? Won't that make things even uglier for those files, until all portfiles are manually examined and corrected, which would likely be a random discovery process that would take a long indeterminate amount of time if not done in a coordinated manner? During which time indentation of random portfiles would still be ugly, which is the very problem you're trying to fix by changing the spacing?

Is it useful to consider the use of a tcl prettyprinter, rather than just converting tabs to spaces? Is there such a tool? Would there need to be a specialized MacPorts portfile prettyprinter, rather than a generic tcl one?

-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com

On Feb 13, 2007, at 00:06, Douglas Philips wrote:

...

In any case, I'm pretty sure there are existing programs to convert tabs, but I can't recall any offhand.

Yep. expand and unexpand. Even take the size(s) of the tabstops.

Neat! They're even included with the OS already. Thanks.

I'm just going to point out that all of the base/ files I've looked at have the following at the top of the file: # et:ts=4 What that does is, in vim, sets 4-width soft tabs. Sounds like whomever created these files in the first place intended for it to be that way ;) -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com