This changes line highlight color from a fain yellow (#ffff99) to
a faint blue (#bfdfff), because yellow color is used in comparison view for
inserted lines.
This new color is okay for people with different forms of color blindness
(tested with a simulator):
a) this color looks quite different from other used backgrounds
b) text doesn't lose distinction on this color
This gives all the benefits introduced before for file source view, namely
code selection without line numbers and correct indents, highlighting line
which is linked to, long lines wrapping.
Implementation strategy is also the same as for file source view: all the
lines are put in a sigle pre tag with span's for each line. Correct line
numbering (same as before this patch) is achieved with nested CSS counters.
Introduce stripes2 and stripes4 classes to support different structure.
They will be useful to implement stripes with pure CSS everywhere instead
of current server-side implementation.
This uses classList property, which is well-supported now: both Chromium 8.0+,
Firefox 3.6+ and Opera 11.5+ support it, as well as relatively modern versions
of other browsers.
All the source lines are put in a <pre> tag, which gives correct display and
copy&paste in both Chromium (WebKit) and FireFox: line numbers are not copied,
all the tabs and spaces are kept. This doesn't change the visual appearance
of the view compared to current hgweb version and doesn't use any JS code.
Also, stripes in this view are now generated clientside with CSS.
This implementation is chosen because other variants have important issues:
Strategy FF Chrome
current D,LT,E,T,L D,L
pre S,NW S,NW
pre/div/nbsp LT,E,T,TS,NW TS,NW
pre/div/br LT,E,T,NW NW
ol/li/nbsp LT,E,T,TS,AJ TS,AJ
ol/li/br LT,E,T,AJ AJ
pre/span LV LV
Legend
Strategies:
- current: implemented in hgweb before this patch, i.e. divs for each line,
and line numbers links in the div too
- pre: the whole code in one pre tag with newlines, all line numbers
in another one with 'float: left'
- pre/div/{nbsp,br}: same as just 'pre', but separate divs for each line and
or <br> instead of empty lines (otherwise they are not copied at all)
- ol/li/{nbsp,br}: a single ol with li's and divs for each line,
or <br> same as in previous strategy
- pre/span: this patch
Problems:
D = (very minor) display problems, like wrong width of leading tabs
LT = loses leading/trailing whitespace
E = loses embedded whitespace
B = loses blank lines
T = loses tabs
L = selects line numbers
LV = (only) visually selects line numbers
LVE = (only) visually selects line numbers at empty lines
S = no stripes (and no ability to easily highlight
lines-which-are-linked-at in the future)
TS = space copied instead of empty line
AJ = get anchor links only with JS (they work even without)
NW = no linewrap easily possible (in future)
As for browser versions compatibility, the CSS tricks used are supported in
(according to caniuse.com):
a) line numbers generation with 'content:' property and CSS counters:
IE 8+, all other popular browsers (in pre-WebKit Opera numbers are being copied)
b) stripes ('nth-child' selector):
IE 8+, FF 3.5+, Safari 3.2+, Opera 9.5+, all other popular browsers
c) line numbers are not visually selected ('user-select:' property):
IE 10+, Opera 15.0+, all other popular browsers
This patch is based on a demo implementation by
Martin Geisler <martin@geisler.net>.
There is a new style called phases style.
Usage::
hg log --style phases
Why do we need this new style - in what way is it different from or similar to
existing styles?
The new style is default + phases information. With the new phases feature the
users exhibited their desire for a new style that could help them.
Why do this need a new style - couldn't it be folded into an existing style?
The default style and the new one are about the same, the difference is the
phases tag. The users find both styles useful, this means that the both styles
must exist.
When the web server shows the manifest for a single, non top directory, append
the path to the directory to the archive links. This makes the web server
generate archive files that only include the current directory (and its
subdirectories).
Note that archive links in other pages (e.g. changeset) or at the top of the
manifest are unchanged. Directory archive links have an extra "/" at the end
which does not impact the result of the archive operation. Keeping it there
made the implementation of this feature simpler.
Paper & coal use a sligtly shorter name length of 12em in the log view
than gitweb's 15em. Names too long for 12em is not entirely unheard
of, and hence increasing the length is appropriate; hgweb should
remain usable on 1024x768.
In order to use this, add a [websub] section to your configuration and add
websub expressions such as:
italic = s/\b_(\S+)_\b/<i>\1<\/i>/
bold = s/\*\b(\S+)\b\*/<b>\1<\/b>/
issues = s|issue(\d+)|<a href="http://bts.example.org/issue\1">issue\1</a>|i
bugzilla = s!((?:bug|b=|(?=#?\d{4,}))(?:\s*#?)(\d+))!<a href="http://bz.selenic.com/\2">\1</a>!i
This also adds documentation (proofed by Kevin!) to the config help section.
Without this, repository paths or names containing e.g. & characters or html
tags yielded strange results, possibly allowing cross-site scripting attacks.
More accurately reflects what it will be used for, and is also shorter.
This template is used to change which rev the current rev is diff'd
against. For example, if you're at '/rev/P1:REV', this would link to a
path like '/rev/P2:REV'.
Example usage in a template:
{parent%difffrom}
The user interface introduced in 3ff83729b63f is not considered ready
for prime time yet. The internal code stays in place for custom template
usage. The feature is ultimately wanted and will be re-enabled soon. The
current issue is only related to the visual of the current interface.
This change adds a "URL breadcrumb" to the "title" of the pages on the spartan
template. By title I mean the first line that is shown right below the page
selection row, which shows the name of the page that is being viewed, along with
some additional information.
In doing so it standarizes those "titles" which now follow the pattern:
URL breadcumb / page details
The purpose of this change is to make it much easier to navigate up the
repository tree when the hg web server is used to serve more than one
repository.
A "URL breadcrumb" is a path where each of the path items can be clicked to go
to the corresponding path page.
This lets you go up the folder hierarchy very quickly. For example, when showing
the list of repositories in http://myserver/myteams/myprojects, the following
"breadcrumb" will be shown:
Mercurial > myteams > myprojects
Clicking on "myprojects" reloads the page. Clicking on "myteams" goes up one
folder. Clicking on the leftmost "Mercurial" goes to the server root.
This "breadcrumb" also appears on all repository pages. For example on the
summary page of the repository at http://myserver/myteams/myprojects/myrepo the
following will be shown:
Mercurial > myteams > myprojects > myrepo / summary
This change has been applied to all templates that already had a link to the
main repository page (i.e. gitweb, monoblue, paper and coal) plus to the index
page of the spartan template.
In order to make the breadcumb links stand out the some of the template styles
have been customized.
This is similar to the subscribe links that already exist in other templates.
Rather than the usual RSS and Atom links a single feed icon linking to the
atom-log is shown.
Up until now the templates that show RSS and Atom feeds on the "repository
lists" (i.e. gitweb and monoblue) showed them for all entries, including regular
folders. Clicking on those "folder RSS" links would result in an error page
being shown.
This patch hides those links for regular folders.
There were no RSS nor Atom feeds for the branches page. Different hgweb
templates linked to different feeds on their branches page (some linked to the
tags feed, some to the log feed and some to the unexisting branches feed).
