Junio C Hamano wrote:
quoted text
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>>> *.py whitespace=!indent,trail,space
>>> *.el whitespace=!indent,trail,space

Emacs Lisp is (like Perl, and contrary to Python) whitespace agnostic,
so here you just agree on historical usage. In this case the same
should IMHO be done for gitweb/gitweb.perl in main .gitattributes.

:<: checks contrib/emacs/git.el :>:

Hmmm... it looks like git.el uses only spaces, both for indent
and for align, with some spurious TABS happening.

If you allow this, couldn't you allow also for the gitweb.perl?

quoted text
>>> fast-import/git-p4 whitespace=!indent,trail,space
>>
>> I would also exclude gitweb/gitweb.perl
> 
> Why?
> 
> As far as I can tell, Perl does not use Python/Elisp "indents
> are all whitespace" rule and neither does the script.

Elisp is also whitespace agnostic, but like in Perl it can contain
here-docs, and heredoc-like docstring; I'm not sure about whitespace
rules for that.

quoted text
> It also happens that I do not personally believe in "alignment
> with spaces" argument.  If you accept W and a SP occupy the same
> horizontal space (which "alignment with spaces" assume), I do
> not think it is unreasonable to accept HT goes to the next
> column that is multiple of 8 places.
 
My argument is that when you change tab-width (and basic-offset), with
"tabs for indent, spaces for align" you don't have source get out of 
align. And not everybody uses large screens, and large resolution.

Besides there is also purely theoretical argument of consistency.
When using tabs also for align, it is in prectice align with tabs
_and spaces_, e.g.:

------>|if (expression ||
------>|____expression) {

or

------>|print "something" .
------>|______"something";

or

------>|$date{'mday-time'} = sprintf "%d %s %02d:%02d",
------>|------>|------>|_____$mday, $months[$mon], $hour ,$min;

where leading tab is marked as "------>|", and leading space as "_".


The argument for using tabs for align is that it is easy to check 
programatically for those kind of whitespace errors, and that editors 
do that. But lacking tools or misconfigured tools shouldn't IMHO be 
cause of selecting a coding style / choosing a policy.

-- 
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html