Charles Bailey <charles@xxxxxxxxxxxxx> writes:
> + # Tabstop width. Controls the number of spaces to which tabs are
> + # expanded. Default is 8.
> + # To change system wide add the following to $GITWEB_CONFIG
> + # $feature{'tabstop'}{'default'} = [8];
> + # To have project specific config enable override in $GITWEB_CONFIG
> + # $feature{'tabstop'}{'override'} = 1;
> + # and in project config gitweb.tabstop = <width>
> + 'tabstop' => {
> + 'sub' => \&feature_tabstop,
> + 'override' => 0,
> + 'default' => [8]},
Some people say "Tabs are 8 characters, and thus indentations are also 8
characters. There are heretic movements that try to make indentations 4
(or even 2!) characters deep, and that is akin to trying to define the
value of PI to be 3." Some people disagree.
But while viewing what is etched in the history, it does not hurt anybody
else if the viewer uses different tab width. Choice is good.
However, a choice made by the hosting service that runs gitweb would not
help individual viewers with different tab-width taste. Neither does
configuration that is per-repository. Participants of the same project
would want to view contents with different tab-width.
Perhaps the tabstop "feature" should control _if_ the tab width of the
material gitweb feeds can be tailored at all (i.e. boolean). And when
enabled, it would leave the choice of non-8 tab width to the browser (the
way to maintain per-client choice could be cookies or extra parameters, I
do not really care the details), and use that preferred tab-width in the
untabify function.
On the other hand, maybe the tab-width customization is not about user
preference but what tab-width was used when the contents were created. In
such a case, probably the right thing to do would be to look at the
tab-width hints embedded in the file. In such a case, probably the tab
width setting need to be per-path (e.g. *.c files may use standard 8,
while *.py may use heretic 4). Again, site-wide or repository-wide
configuration would not help.
In short, I do not like the patch, not because I do not like customizable
tab-width, but because I think the customizability the patch offers is of
the wrong kind and too limited to be useful.
P.S.
It might be interesting to come up with a heuristics to _guess_ the tab
width used by the content creator by looking at the contents, by the way.
There obviously are Emacs "Local Variables" and "-*-" lines and equivalent
clues vim would leave, but you could probably also use indentation levels
as a cue.
And perhaps teach the underlying git commands a special flag to expand
tabs on the output.
"git cat-file --expand=auto blob Makefile"
"git diff --expand=8 HEAD^..HEAD frotz.c"
;-)
--
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
