This is a preparatory patch for separation of project list and frontpage
actions; it factors out most logic of git_project_list():

	* git_project_list_all() as a git_project_list_body() wrapper for
	  complete project listing
	* git_project_search_form() for printing the project search form

Also, git_project_list_ctags() is now separated out of
git_project_list_body(), showing tag cloud for given project list.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 gitweb/gitweb.perl |   69 +++++++++++++++++++++++++++++++---------------------
 1 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..e82ca45 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4201,10 +4201,9 @@ sub git_patchset_body {
 # project in the list, removing invalid projects from returned list
 # NOTE: modifies $projlist, but does not remove entries from it
 sub fill_project_list_info {
-	my ($projlist, $check_forks) = @_;
+	my ($projlist, $check_forks, $show_ctags) = @_;
 	my @projects;
 
-	my $show_ctags = gitweb_check_feature('ctags');
  PROJECT:
 	foreach my $pr (@$projlist) {
 		my (@activity) = git_get_last_activity($pr->{'path'});
@@ -4254,12 +4253,26 @@ sub print_sort_th {
 	}
 }
 
+sub git_project_list_ctags {
+	my ($projects) = @_;
+
+	my %ctags;
+	foreach my $p (@$projects) {
+		foreach my $ct (keys %{$p->{'ctags'}}) {
+			$ctags{$ct} += $p->{'ctags'}->{$ct};
+		}
+	}
+	my $cloud = git_populate_project_tagcloud(\%ctags);
+	print git_show_project_tagcloud($cloud, 64);
+}
+
 sub git_project_list_body {
 	# actually uses global variable $project
 	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
 
 	my $check_forks = gitweb_check_feature('forks');
-	my @projects = fill_project_list_info($projlist, $check_forks);
+	my $show_ctags = gitweb_check_feature('ctags');
+	my @projects = fill_project_list_info($projlist, $check_forks, $show_ctags);
 
 	$order ||= $default_projects_order;
 	$from = 0 ...
[ message continues ]

Petr,

After digging into some of the ctags stuff recently looking at it, I 
have some serious concerns over making it a more primary interface 
inside of Gitweb.

1) The mechanism to assign ctags and it's associated documentation is 
cryptic at best.  It took me reverse engineering the code to figure out 
how to add tags to a repository, and even then there are very simple 
means of trivially breaking them (Like put 0 inside of a ctag file, the 
divide by zero errors are kinda concerning for instance).

2) If the repository is cloned the ctag information is not retained, 
which means there is no real way for the original developer to manage or 
move this information between different hosting sites, I.E. repo.or.cz 
and kernel.org (though I'll admit I have it turned off)

So if your going to eliminate the project listing, with the general 
intention of using the tag cloud as more of a primary search mechanism, 
including the search box, I think there's some serious work that needs 
to be put into the ctags system because in it's current state, for the 
likes of kernel.org, it's unusable, unstable and not something I would 
recommend to anyone to run in production.  I like the idea, I just have 
concerns over it's current implementation.

- John 'Warthog9' Hawley


--

[ message continues ]

Hi!


  This is interesting argument, I have always thought about ctags being
a rather site-specific mechanism and I think it would've meet with a lot
of user opposition to e.g. keep ctags in a specific branch; I can think

  This patch is orthogonal to that, I believe. I agree that the ctags
mechanism is somewhat hackish; unfortunately, I personally don't have
the time to fix it up properly. I think it is still good enough for
many users, and the frontpage mechanism would be quite useful even for
people who don't want to use content tags.

-- 
				Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
--

[ message continues ]