From: Junio C Hamano <gitster@pobox•com>
To: Charles Bailey <charles@hashpling•org>
Cc: git@vger•kernel.org, Jakub Narebski <jnareb@gmail•com>
Subject: Re: [PATCH] gitweb: add a setting to control the tabstop width
Date: Mon, 03 Mar 2008 15:13:39 -0800 [thread overview]
Message-ID: <7vhcfnfljw.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080303221159.GA6875@hashpling.org> (Charles Bailey's message of "Mon, 3 Mar 2008 22:11:59 +0000")
Charles Bailey <charles@hashpling•org> 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"
;-)
next prev parent reply other threads:[~2008-03-03 23:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-03 22:11 [PATCH] gitweb: add a setting to control the tabstop width Charles Bailey
2008-03-03 22:33 ` Jakub Narebski
2008-03-03 22:52 ` Charles Bailey
2008-03-04 0:08 ` Jakub Narebski
2008-03-03 22:52 ` Jakub Narebski
2008-03-03 23:13 ` Junio C Hamano [this message]
2008-03-04 3:35 ` Martin Langhoff
2008-03-04 8:19 ` Jakub Narebski
2008-03-04 8:41 ` Charles Bailey
2008-03-04 8:36 ` Charles Bailey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vhcfnfljw.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=charles@hashpling$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox