Junio C Hamano wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> 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?
>>> 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.
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
