This is second part of gitweb wishlist and TODO list, this one about features which are present in gitweb-xmms2 http://git.xmms.se/?p=gitweb-xmms2.git but not yet in gitweb. (Features which were ported include: snapshots, separate CSS file, navbar refactoring.) Since gitweb-xmms2 was forked, gitweb received better binary files support, nicer commitdiff and blobdiff view, history for directories (shortlog), better performance... but it also needs newer gi (git-for-each-ref, git-rev-list --full-history). I know that because gitweb-xmms2 was created for specific set of repositories and for one installation the features didn't need to be generic. Sent to Petr Baudis who uses newest gitweb at http://repo.or.cz and Sham Chukoury of gitweb-xmms2. 3. gitweb-xmms2 features * Committags support Contrary to what is done in gitweb-xmms2 the consensus (for now) is to process committags sequentially, one by one, marking parts not for further parsing. HTML escaping is done at the end. The problem lies not with implementing committags parsing (although correctly making links from committags in subject line in shortlog-like views, where subject line itself is a link, requires some thought) but with configuring committags. We can divide committags into the following broad categories (below _link_ denotes hyperlink): - project dependent committags, which include: * bugtracker support, be it _BUG(n)_ and _FEATURE(n)_ of Mantis (as implemented in gitweb-xmms2), or _bug n_ or _bug #n_ as used in Bugzilla * message-id, linking to some mailing list archive, e.g. Message-ID: <_200609200739.48732.alan@xxxxxxxxxxxxxxxxxxxxxx> * "version" tag links, e.g. _v1.4.2-rc1_ * release announcement links, e.g. _RELEASE 1.4.2_ - global committags, which include: * sha1 or shortened sha1 of an object, e.g. _1b0e5f5e_ * plain text URL, e.g. _http://repo.or.cz_ * spam protection of emails, e.g. "linux () horizon ! com" - syntax highlighting and log reformatting; we probably need to implement them as committags if we move from parsing commit message or tag message line by line to parsing it as a whole * syntax highlighting signoff lines * syntax highlighting PGP signature block in tags * empty lines simplification: collapsing 2 or more empty lines into one, removing leading and trailing empty lines Do you have ideas for further committags? The gitweb-xmms2 could do without because committag support there was tailored for a set of common projects, sharing for example bugtracker. Usually both committag options (like th URL to bugtracker, or the mailing list archive used) depend on repository, and the fact if committag is enabled depends on repository. Additionally, both sequence in which commitags are deployed is important, and for what which committags are used is needed. For example we might not want to have link-creating committags in subject lines, we know that syntax highlighting and log reformatting has no place in subject lines; we might want to do empty lines simplification only for "log" and "commitdiff" views, and syntax highlighting of PGP signature only for "tag" view. And this also might be overridable per repository. I don't have definite ideas about how to configure this. Perhaps gitweb.committag.<name> for options, subsequent variables with the same names creatin list (array) of default options. Perhaps gitweb.committags_subject or gitweb.committags_enable.subject for sequence of commitags for subject line, etc. What do you think about this scheme? * Project categories support This I think requires native config file parsing, because I don't want to add yet another file to repository layout, although perhaps we should fallback on a file and support category from a file as legacy support for gitweb-xmms2. Perhaps if there is no gitweb/category, nor $GIT_DIR/category then perhaps first part of pathname (relative to $projectroot) should serve as category? The problem with categories is that they interfere a bit with sorting. When sorting by repository name, by description, by owner, by last change, do keep categories sorted alphabetically, or perhaps sorted with the repositories (for example when sorting by last change, first would be category with repository with most recent change, etc.)? Or perhaps keep categories sorted alphabetically and sort within categories, but add option to turn categories support on and off? How to show division into categories? I think what is at http://git.xmms.se can be improved. Any ideas? * Syntax highlighting for "blob" view (in general: blob output filter) For syntax highlighting gitweb needs (to not have to use temporary files) a program which outputs line-by-line HTML and can be used as a filter. gitweb-xmms2 uses Highlight by André Simon from http://www.andre-simon.de/. Other similar tool is GNU Source Highlight, http://www.gnu.org/software/src-highlite/. Or instead of external utility we can use some Perl module for syntax highlighting, like Beautifier, http://www.beautifier.org/ or one of Syntax::Highlight modules. Do you know any other highlighter, either Perl module or "filter" highlighter gitweb can use? gitweb-xmms2 has Highlight hardcoded, and has style for highlighting in main gitweb CSS file gitweb.css; gitweb should have blob output filter (syntax highlighter) configureable, and have separate CSS for syntax highlighting. Another thing to be configured is how to find which style to use (for what programming language), based on file name and perhaps file contents. gitweb-xmms2 has it hardcoded in %highlight hash; we should probably use mimetype_guess, perhaps with the mimetype to style translation if the program or module in question doesn't accept mimetypes to select style. But perhaps it would be better to have it hardcoded like %features. What do you think? * Etags based anchors to function definitions. This needs temporary file, either file to scan for tags, or tags file itself. gitweb-xmms2 uses Exuberant Ctags, http://ctags.sourceforge.net in filter mode to read (so it needs blob saved in a file) and parse TAGS file to get tags location for anchors. GNU Highlight has support for ctags to generate references (although I haven't tested that yet). But perhaps we better use TAGS pre-generated, like git.git html and man pages and generate ancgors only if it is present? Or use some Perl module to find tags to make anchors of them? The idea is (I think) to be able to refer to given tag (e.g. function) at given revision. What need to be ported for gitweb-xmms2 to consider using generic gitweb? -- 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