The link is embedded into a div with class="annotate-info" that only shows up
upon hover of the annotate column. To avoid duplicate hover-overs (this new
one and the one coming from link's title), drop "title" attribute from a
element and put it in the annotate-info element.
hgweb currently offers limited functionality for "classifying"
repositories. This patch aims to change that.
The web.labels config option list is introduced. Its values
are exposed to the "index" and "summary" templates. Custom
templates can use template features like ifcontains() to e.g.
look for the presence of a specific label and engage specific
behavior. For example, a site operator may wish to assign a
"defunct" label to a repository so the repository is prominently
marked as dead in repository indexes.
It was mixing tabs and spaces, and not in a good way.
Indent style of other atom entries seems to be 1 space per level, so let's
apply it here as well.
Since content is of type "text" (and is already escaped), using a CDATA section
is not required.
Looks like this was just an artifact of copying things from rss style in
529b23a26574, because other entries in atom style don't use CDATA in such
places.
It was mixing tabs and spaces, and not in a good way.
Indent style of other rss entries seems to be 4 spaces per level, so let's
apply it here as well.
I.e. when a revision blames a block of source lines, only display the
revision link on the first line of the block (this is identified by the
"blockhead" key in annotate context).
This addresses item "Visual grouping of changesets" of the blame improvements
plan (https://www.mercurial-scm.org/wiki/BlamePlan) which states: "Typically
there are block of lines all attributed to the same revision. Instead of
rendering the revision/changeset for every line, we could only render it once
per block."
* Distinguish the /annotate/<revision>/<file>#<linenumber> link when it would
lead to the current page (i.e. <revision> is the current revision) (style it
gray and undecorated). This indicates more clearly that this is a "dead-end"
in blame navigation.
* Display lines changed in current revision in green.
Change summary webcommand to yield each element of the shortlog instead of the
entire list.
This makes generated json more readable since each entry can be formatted
separately, instead of returning all the shortlog content in a single string.
Modify changelistentry structure to also deliver phase and branch data and use
either 'parents' or 'allparents' depending on what is defined in the view, in
order to reuse it in filelog structure.
Before, copied files were assumed as "A" (added) and listed followed by
non-copy added files. This could double entries of a copy if it had "M"
(modified) state.
So, this patch makes the template check if a file is included in copies dict.
This way, entries should never be doubled.
The output of "log -Tstatus -C" does not always agree with "status -C --change"
due to the bug of "status", which is documented in test-status.t. See also
21a68fa3c757.
Entries prepared in webutil.changelistentry() skip showing parents in the
trivial case when there's only one parent and it's the previous revision. This
doesn't work well for the json-log template, which is supposed to just dump raw
data in an easy-to-parse format, so let's provide all parents as another
keyword: allparents.
Using a lambda function here means that the performance of templates that don't
use allparents won't be affected (see 88bd6697bfad).
This template allows showing the list of all repos in an hgweb instance (in
hgwebdir mode) as json.
The test has "lastchange" globbed because hgweb uses here file modification
time and not the last commit time.
This is necessary to preserve filename encoding over JSON. Instead, this
patch inserts "|utf8" where non-ascii local-encoding texts can be passed
to "|json".
See also the commit that introduced "utf8" filter.
After 313b8d61b548 graph canvas width is decided once on the initial rendering.
However, after graph page gets scrolled down to load more, it might need more
horizontal space to draw, so it needs to resize the canvas dynamically.
The exact problem that this patch solves can be seen using:
hg init testfork
cd testfork
echo 0 > foo
hg ci -Am0
echo 1 > foo
hg ci -m1
hg up 0
echo 2 > foo
hg ci -m2
hg gl -T '{rev}\n'
@ 2
|
| o 1
|/
o 0
hg serve
And then by navigating to http://127.0.0.1:8000/graph/tip?revcount=1
"revcount=1" makes sure the initial graph contains only revision 2. And because
the initial canvas width takes only that one revision into count, after the
(immediate) AJAX update revision 1 will be cut off from the graph.
We can safely set canvas width to the new value we get from the AJAX request
because every time graph is updated, it is completely redrawn using all the
requested nodes (in the case above it will use /graph/2?revcount=61), so the
value is guaranteed not to decrease.
P.S.: Sorry for parsing HTML with regexes, but I didn't start it.
Before this patch, template files for "graph" web page use fixed width
size "480" for canvas element.
This causes pruned lanes and invisible vertexes, if there are 16 or
more vertical lanes at once. In such case, part of graph in right side
area over 480 is invisible, even though corresponded summary text
blocks are visible correctly.
This limitation isn't reasonable for workflow using many branches at
once (e.g. "one branch per issue" workflow).
There were changes below related to width of canvas:
- 6c855f5350cd (templates: widen the graph canvas (issue2683)),
released as a part of Mercurial 1.8.2
According to the description, this assumed that 15 parallel
branches was enough for ordinary workflow, and bumped width of
canvas up from 224 to 480.
- f5506d2a674c (hgweb: make graph data suitable for template usage),
released as a part of Mercurial 2.3
This introduced "canvaswidth" template keyword as a part of
refactoring around graph rendering.
But 'width="480"' of canvas element in template files wasn't
replaced by 'width="{canvaswidth}"' in it (or subsequent one).
This patch uses dynamic value "{canvaswidth}" instead of fixed width
size "480" for canvas element.
This is posted for "stable", because:
- this is re-fixing issue2683
- this is simple enough for stable
- using "{canvaswidth}" doesn't require any additional cost
Calculation of canvaswidth is already implied as a part of "graph"
web command.
Currently, the "helptopics" template assumes it is only used as the
main index and therefore doesn't hyperlink "help" in the navigation
list. Sub-topics will introduce an additional consumer of this
template. So teach the template to hyperlink the "help" navigation
entry when necessary.
In order to support sub-topics, we need to support linking to a full
topic name while displaying the base topic name. Change the {helpentry}
template to grab the display name from an optional seperate variable
(which will be defined in a future patch).
We now have sub-topics in the help system. The "helptopics" template
serves as a mechanism for displaying an index of help topics.
Previously, it was only used to show the top-level list of help topics,
which includes special groupings of topics.
In the near future, we'll adapt "helptopics" for showing the index
of sub-topics. In this patch, we optionally render {earlycommands} and
{othercommands} since they aren't present on sub-topics.
currently "subscribe to atom feed" link in file log page is as follows.
/atom-log/[revision]/[file]
This is invalid, because we could not get newer commit feed than [revision].
To fix this, atom-log feed url should be the following style.
atom-log/tip/[file]
Looks like the function wasn't ever used since its introduction in
083571f47ff6, since setColor() below always used "rgb(255, 255, 255)" notation
which doesn't need hex digits.
Due to how the line links now reside outside of the source lines, hovering over
line numbers doesn't count as hovering over the appropriate source line. It can
be worked around by using a "+" css selector. However, it's necessary to
reorder the elements and put <a> before <span> (which is actually quite
logical). It works without further css tweaks because <a> is already
absolute-positioned and so the order doesn't matter visually.
Due to how the line links now reside outside of the source lines, hovering over
line numbers doesn't count as hovering over the appropriate source line. It can
be worked around by using a "+" css selector. However, it's necessary to
reorder the elements and put <a> before <span> (which is actually quite
logical). It works without further css tweaks because <a> is already
absolute-positioned and so the order doesn't matter visually.
Due to how the line numbers in monoblue are formed (via css counters), the size
of the area with the numbers and the size of the actually clickable links are
not tied together well enough. Before this patch, there were noticeable "gaps"
between line links - clicking on the bottom part of a visible line number did
nothing as opposed to selecting this line.
Let's set font-size for everything in pre.sourcelines so that it also affects
the links and then add a bit of padding to them so compensate for layout
differences.
This way the sizes are still not 100% the same, but should be very close.
In hgweb, some pages have a context of current revision; e.g. changelog and
shortlog show changesets starting from this current revision. However, some
gitweb templates were dropping current revision from some urls _to_ /graph page
and _on_ that page. This patch fixes it.
When users configure the default foreground or background color to
non-default (black on white) values, several hgweb styles lack
contrast for headers and table row items. This patch fixes that by
ensuring that where either foreground or background colors are
specified, both are specified.
This is adapted from 635285e0a942, that was added to paper for 3.5 release.
It adds another way to refer to branches, tags and bookmarks in urls: by name.
It's still possible to navigate to a specific changeset hash, but now you can
get more descriptive urls straight from /summary page, for example.
branchentry template (and so the whole branches table on /summary and
/branches) lost the column that had a plain changeset hash, because tags and
bookmarks don't have this column and also because there is already a way to
address branch by its changeset hash (changeset link just next to it). Maybe we
can instead bring this column with a plain changeset hash to tags and
bookmarks, but this, more terse, new look feels fine.
This is adapted from 635285e0a942, that was added to paper for 3.5 release.
It adds another way to refer to branches, tags and bookmarks in urls: by name.
It's still possible to navigate to a specific changeset hash, but now you can
get more descriptive urls straight from /summary page, for example.
branchentry template (and so the whole branches table on /summary and
/branches) lost the column that had a plain changeset hash, because tags and
bookmarks don't have this column and also because there is already a way to
address branch by its changeset hash (changeset link just next to it). Maybe we
can instead bring this column with a plain changeset hash to tags and
bookmarks, but this, more terse, new look feels fine.
Empty lines in file view could produce an inexplicable margin before the next
line (most noticeable in browsers on webkit/blink engine). That was making
empty lines seem taller than the rest.
Instead of using default vertical align, let's set it to 'top'.
This issue is actually present in paper, and only recently got into gitweb
(0609781075c1) and monoblue (b7a7757577fb). There's a bit more to it in paper,
so that will be dealt with in a future patch.
Recipe to see live: preferably using a webkit/blink browser, such as chromium,
browse a file with empty lines, e.g. https://selenic.com/hg/file/3.5/README#l8
Selecting a block of text that includes empty lines will reveal white "breaks"
in the selection. Highlighted line (#l8) also shows such a break below itself.
This is adapted from 0609781075c1.
It also fixes issue4790 in monoblue; tab characters now have meaningful width on
the modified pages (file view, file diff, changeset).
This is adapted from a46863946982 and 8d7bff75072d.
It also fixes issue4790 in gitweb; tab characters now have meaningful width on
the modified pages (file view, file diff, changeset).
To remove another big chunk of duplication from coal hgweb style, we can move
all visual tweaks to style-extra-coal.css and include it together with
style-paper.css.
Before, coal/map simply had all the templates copied and pasted from paper/map
file. It was easy to make a change to paper that would get into coal only
partially and just sit there until something like 216a95e6094f happened.
Let's remove this duplication from coal/map by using %include to reuse
templates from paper/map directly.
In paper and Coal, basically, div.sourcelast was only used to make a 1px border
on the bottom of file source view (and only there). It's better to use
bottomline class, that also exists for the same purpose (visually), but is used
more widely and works without needing an empty <div>.
Basically, coal style in hgweb is intended to be functionally equivalent (just
different in style) to paper, and does this by reusing almost all templates
from paper (except header.tmpl, where it specifies a different css file). Looks
like everybody forgot this and so many improvements to paper templates, that
should've also made it into coal, were often only half-done there (usually
thanks to template reuse). Let's fix this by bulk-copying missing things from
paper/map and style-paper.css to coal/map and style-coal.css.
There were many improvements to paper that didn't touch coal, and that makes it
hard to untangle the code and split this patch into many, but here are some of
the changes (paper-only), that now get into coal:
a9c9f5ef6abf - hgweb: color line which is linked to in file source view
1555d017cac7 - hgweb: highlight line which is linked to at annotate view
a46863946982 - hgweb: code selection without line numbers in file source view
636594df4244 - hgweb: add line wrapping switch to file source view
cc6bee069ce6 - hgweb: use css margin instead of empty <p> before diffstat table
It also fixes line anchor in annotateline template (#42 vs #l42).
"Tags" and "Bookmarks" sections on this page already have the similar links,
and so does the "Branches" on summary page in gitweb, so let's do the same in
monoblue.
Index page, which shows the list of available repositories, has a column where
the last modification date for each repo is shown. paper, coal and spartan
already show the dates in relative format (e.g. "2 weeks ago"), because these
styles have the required process_dates() js function call in their footer
templates, which are included on every page. But monoblue and gitweb styles
have more things in the footer templates, such as repo name and its atom/rss
links, so they don't include the footer on index page (as this page doesn't
have a single repo context).
Let's call process_dates() without including the footer.
In 064b658181dd, age calculation was made dynamic (i.e. in javascript), but for
some reason bookmarkentry template in monoblue/map got a wrong class. It
resulted in /summary and /bookmarks pages always showing exact dates for
bookmarks, no age calculation was performed. Let's fix this by using "age"
class that is already used in branchentry and tagentry templates in the same
map file.
As usual, the exact date for such elements is still available in title
attribute, so it shows in a tooltip on hover.
Since f9c487618909 and 9d5bd0e29076, when monoblue was introduced, the code
this patch removes was untouched. Presumably, there supposed to be nice
graphics in the screen corners, but there never were due to:
- the css being commented out
- ids of the elements and of the css selectors being different
- and the png files absent
The "corner" elements were unstyled and didn't affect the rest of the page, so
I think it's safe to remove all this.
Just to be consistent with log and shortlog links, graph links should have a
revision context too. And the same goes for the graph page, where it's log and
shortlog links that should have context.
It's sometimes handy to, say, have a url always point to branch head, not just
at the current branch head by node hash. Previously, this was only possible by
manually editing url and replacing node hash with branch/tag/bookmark name. It
wasn't very convenient, or easy - in case the name contained special
characters that needed to be urlencoded.
Let's have /branches, /tags and /bookmarks pages in paper and coal style
provide links both to symbolic revisions and to node hashes.
This feature was wished for in issue3594.
Some installations alter monoblue style and remove margins from body element
(these margins have that dark gray background) to adapt hgweb instance to an
already existing site design. However, the margins hid a quirk in page footer:
a block of text needlessly popped out of the footer, and when margins were
gone, the whole page got a vertical scroll bar because of that.
Live example: https://hg.prosody.im/prosody-modules/
To remove the potential scroll bar, this block of text now uses left padding,
which doesn't make it overflow the footer, but makes it achieve the otherwise
same result visually.
Since "fd4945970469 or b7c98f01667e::be1d0b03b11a" paper style used css for
stripes in background for browsing files, for listing branches/tags/bookmarks,
and so on.
Since coal borrows many paper templates (e.g. shortlogentry.tmpl), it actually
tried to do the same, but it didn't have the needed css classes. You can
compare https://selenic.com/hg?style=coal with
https://selenic.com/hg?style=paper and see how log view in coal style has plain
white background, unlike the one in paper style. This wasn't intended.
Let's copy css classes directly from style-paper.css and remove parity classes
from elements that don't need them anymore. This makes plain white background
have stripes again and makes coal/map even more similar to paper/map (which can
ease porting changes or %including paper/map in future).
Unlike other styles, paper and coal had only one link to current revision: in
the sidebar. Since those links now use symbolic revisions after 4b263b99440b,
it's nice to have a link that allows going from /rev/tip to /rev/<tip hash>,
for instance. Let's make the node hash in the page header that new link.
Let's make paper (and coal, since it borrows so much from paper) templates use
symbolic revision in navigation links.
The majority of links (log, filelog, annotate, etc) still use node hashes.
Some pages don't have permanent links to current node hash (so it's not very
easy to go from /rev/tip to /rev/<tip hash>), this will be addressed in future
patches.
Let's make gitweb templates use symbolic revision in navigation links.
The majority of links (log, filelog, annotate, etc) still use node hashes.
Some pages don't have permanent links to current node hash (so it's not very
easy to go from /rev/tip to /rev/<tip hash>), this will be addressed in future
patches.
Let's make monoblue templates use symbolic revision in navigation links.
The majority of links (log, filelog, annotate, etc) still use node hashes.
Some pages don't have permanent links to current node hash (so it's not very
easy to go from /rev/tip to /rev/<tip hash>), this will be addressed in future
patches.
Let's make spartan templates use symbolic revision in navigation links.
The majority of links (log, filelog, annotate, etc) still use node hashes, and
many pages also have permanent link to current node hash (i.e. you can go from
/rev/tip to /rev/<tip hash> without manual url editing), so it's safe to
update navigation.
Some pages, e.g. bookmarks, help and summary don't have a meaningful revision
context: they always either show information about tip or about the whole repo
(and not about any specific changeset). And error pages can just show hgweb
error messages, not related to any repo or changeset.
Having a hash in the links worked (even when '{node|short}' resolved to an
empty string on error pages), but seeing pages without revision context provide
links with hashes is a bit confusing (unless you keep current tip hash in your
head at all times) and not consistent with other template styles and other
links on the same page: they don't have a hash.
Let's just link to '/file', which is equal to '/file/tip'.
Some pages, e.g. bookmarks, help and summary don't have a meaningful revision
context: they always either show information about tip or about the whole repo
(and not about any specific changeset). And error pages can just show hgweb
error messages, not related to any repo or changeset.
When monoblue style was added in f9c487618909, however, all graph links had
tried to point at some hash, and on such pages as described above it didn't
make sense. On error pages '{node|short}' is empty string anyway.
Of course, it worked, but seeing such pages without revision context provide
links with hashes is a bit confusing (unless you keep current tip hash in your
head at all times) and wasn't consistent with other template styles, other
pages in monoblue and even other links on the same page.
Let's just link to '/graph', which is equal to '/graph/tip'.
The ability to "skip" a chain of empty directories in hgweb was added in
5c045b277096, but monoblue style wasn't updated.
This block is copied from gitweb/map file and just works.
This width property comes from the beginning of the monoblue theme itself, and
was used to stop the action header ("summary", "shortlog", "changelog", etc)
from clashing with the search form. But it still was happening (on smaller
screens, and with more actions added to hgweb over time).
Effectively, the hardcoded width was preventing the header from fitting into
the available screen space, since it always tried to be 900px wide, even if
that meant horizontal scroll on smaller screens and having the actions on two
lines where one should've been enough. For example,
http://selenic.com/hg/log?style=monoblue has the last two actions ("gz" and
"help") in the header on the second line, even when there seems to be enough
space on the first.
This patch makes the form float, which prevents it from overlaying/clashing
with the action header, and allows the latter to resize itself in the best
possible way.
Browse (or manifest) action allows browsing the directory structure at some
specified revision. In gitweb and monoblue styles, the revision header already
has branch/tag/bookmark information for the revision, but in paper style this
header was only showing tags. This patch adds branches and bookmarks.
Branch name needs to be obtained in this special way to be consistent with
regular changeset page, where in paper style default branch is never shown.
This line for filelogentry template is copied from shortlogentry. The
information is already displayed in paper style, so no change to python code is
needed. Tests are unaffected.
There already are branches and tags in file log, now let's add what's been
missing: bookmarks.
Also, since coal borrows this template from paper, this change is effective for
coal as well.
This will ease future patches for the templates.
As a result of this patch, paper style has one visual change in
log/shortlog/file log view: the spacing between commit message and the first
tag (or branch name, or bookmark) is now roughly who spaces wide instead of one
space wide. This spacing is consistent with the one between branch
names/tags/bookmarks themselves, so it looks better.
In gitweb style, the change from non-breakable space to regular space is
consistent with other elements.
In monoblue the change is not noticeable.
This also adds labels to the output, as the tests now show.
I took the liberty to give two labels to the bisection status, just
like revisions get the log.changeset and changeset.phase statuses.
It appears that git users like having a --name-status option on `git
log`. There exist at least three questions on StackOverflow on how to
do this for hg. The desired output is not difficult to build with
templates, and since this is something that svn users might also want,
it seems desirable to have this as another standard template.
This mimics the output of `hg status` and adds it to the log output.
It also follows status's convention of displaying copies with a -C
option. Brief example:
$ hg log -T status -C
changeset: 24883:7d1b9b7ac9fd
bookmark: statustemplate
tag: tip
parent: 24864:a08f05e3a9cf
user: Jordi Gutiérrez Hermoso <jordigh@octave.org>
date: Wed Apr 22 14:05:04 2015 -0400
summary: log: add a status template
files:
A added
A copied
original
M modified
R removed
Of course, everything is also coloured correctly, and there are tests
to prove it.
It's easy to miss the closing </tr> tag when it's not on its own line. Some
neighboring blocks also already use this clearer style.
(In 7e841ecf66c5 I didn't even think grepping for this, but this patch should
now cover every occurrence).
Since e902e55c3d0b, column headers are wrapped by <thead> element, so the first
and only <tbody> contains changelog data. I got the following error without
this patch:
Uncaught TypeError: Cannot read property 'lastElementChild' of null
scrollHandler @ mercurial.js:375
This is a copy of 942d64e0a1ee, but applied to the phases template,
which is itself almost a copy of the default template.
Perhaps we should rewrite these templates to use the %include syntax
afforded by config files. This change seems a bit too big for stable,
though.
Single letter properties are used to keep payload size down, as diff
representation can be quite large and longer property names can create a
lot of extra work for parsers.
Rename is not yet captured. This can be done in a follow-up.
We should consider add HTML rendering of the RST into the response as a
follow-up. I attempted to do this, but there was an empty array
returned by the rstdoc() template function. Not sure what's going on.
Will deal with it later.
These are the same dispatch function under the hood. The only difference
is the default number of entries to render and the template to use. So
it makes sense to use a shared template.
Format for {changelistentry} is similar to {changeset}. However, there
are differences to argument names and their values preventing us from
(easily) using the same template. (Perhaps there is room to consolidate
the templates as a follow-up.)
We're currently not recording some data in {changelistentry} that exists
in {changeset}. This includes the branch name. This should be added in
a follow-up. For now, something is better than nothing.
It's pretty surprising phase wasn't part of this template call already.
We now expose {phase} to the {changeset} template and we expose this
data to JSON.
This brings JSON output in line with the output from `hg log -Tjson`.
The lone exception is hweb doesn't print the numeric rev. As has been
stated previously, I don't believe hgweb should be exposing these
unstable identifiers. (We can add them later if we really want them.)
There is still work to bring hgweb in parity with --verbose and
--debug output from the CLI.
Tags is pretty easy to implement. Let's start there.
The output is slightly different from `hg tags -Tjson`. For reference,
the CLI has the following output:
[
{
"node": "e2049974f9a23176c2addb61d8f5b86e0d620490",
"rev": 29880,
"tag": "tip",
"type": ""
},
...
]
Our output has the format:
{
"node": "0aeb19ea57a6d223bacddda3871cb78f24b06510",
"tags": [
{
"node": "e2049974f9a23176c2addb61d8f5b86e0d620490",
"tag": "tag1",
"date": [1427775457.0, 25200]
},
...
]
}
"rev" is omitted because it isn't a reliable identifier. We shouldn't
be exposing them in web APIs and giving the impression it remotely
resembles a stable identifier. Perhaps we could one day hide this behind
a config option (it might be useful to expose when running servers
locally).
The "type" of the tag isn't defined because this information isn't yet
exposed to the hgweb templater (it could be in a follow-up) and because
it is questionable whether different types should be exposed at all.
(Should the web interface really be exposing "local" tags?)
We use an object for the outer type instead of Array for a few reasons.
First, it is extensible. If we ever need to throw more global properties
into the output, we can do that without breaking backwards compatibility
(property additions should be backwards compatible). Second, uniformity
in web APIs is nice. Having everything return objects seems much saner than
a mix of array and object. Third, there are security issues with arrays
in older browsers. The JSON web services world almost never uses arrays
as the main type for this reason.
Another possibly controversial part about this patch is how dates are
defined. While JSON has a Date type, it is based on the JavaScript Date
type, which is widely considered a pile of garbage. It is a non-starter
for this reason.
Many of Mercurial's built-in date filters drop seconds resolution. So
that's a non-starter as well, since we want the API to be lossless where
possible. rfc3339date, rfc822date, isodatesec, and date are all lossless.
However, they each require the client to perform string parsing on top of
JSON decoding. While date parsing libraries are pretty ubiquitous, some
languages don't have them out of the box. However, pretty much every
programming language can deal with UNIX timestamps (which are just
integers or floats). So, we choose to use Mercurial's internal date
representation, which in JSON is modeled as float seconds since UNIX
epoch and an integer timezone offset from UTC (keep in mind
JavaScript/JSON models all "Numbers" as double prevision floating point
numbers, so there isn't a difference between ints and floats in JSON).
Many have long wanted hgweb to emit a common machine readable output.
We start the process by defining a stub json template.
Right now, each endpoint returns a stub "not yet implemented" string.
Individual templates will be implemented in subsequent patches.
Basic tests for templates have been included. Coverage isn't perfect,
but it is better than nothing.
There's a "p.changeset-age span" css block in style-monoblue.css with quite a
bit of rules, including position. They were all unused, since there weren't
matching span element inside the p.changeset-age.
The span was removed in 064b658181dd (as it seemed meaningless at the time?)
and since then relative changeset age text looked weird and broken.
"age" class is used for calculating relative changeset age in javascript: all
content of such element is replaced with human-friendly text (e.g.
"yesterday"). So the new span gets the age class.
'<a .../>foo</a>' syntax is incorrect, since the first tag just "tries" to
close itself and then the actual content follows. It doesn't work, either
because web browsers know better than this or because there should be a
whitespace before /: '<a />'. So for the hgweb users the links looked
normal anyway, but now they are correct in code as well.
<p> elements can only contain inline elements, so as soon as browser encounters
a block element (e.g. block <div>) "inside" a <p>, it puts an implicit </p>.
It's better to do this explicitly.
coal style uses every template (except header.tmpl) directly from paper style,
but doesn't use paper/map file. Elements defined in such map files are used in
templates as you would expect. For example, paper/search.tmpl contains
'{searchhint}' and template engine replaces that with the actual hint. But when
coal style reuses paper/search.tmpl, it needs to define searchhint in its map
file as well, or template engine will not find it. So let's copy it from
paper/map to coal/map.
Before this change, if the coal style was selected, the hint for the search
field in page header was present, but it was completely empty. Although the
absence of searchhint in coal/map produced no error.
