2014-08-06 20:43:59 +04:00
|
|
|
#require pygments serve
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
$ cat <<EOF >> $HGRCPATH
|
|
|
|
> [extensions]
|
|
|
|
> highlight =
|
|
|
|
> [web]
|
|
|
|
> pygments_style = friendly
|
highlight: add highlightfiles config option which takes a fileset (issue3005)
Highlight extension lacked a way to limit files by size, by extension, and/or
by any other part of file path. A good solution would be to use a fileset,
since it can check file path, extension and size (and more) in one expression.
So this change introduces such an option, highlighfiles, which takes a fileset
and on each request decides if the requested file should be highlighted.
The default "size('<5M')" is, in a way, suggested in issue3005.
checkfctx() limits the amount of work to just one file (subset kwarg in
fileset.matchctx()).
Monkey-patching works around issue4568, otherwise using filesets here while
running hgweb in directory mode would say, for example, "Abort: **.py not under
root", but this fix is very local and probably far from ideal. I suspect there
to be a way to fix this for the whole hgweb and resolve the issue, but I don't
know how to do it.
2015-09-16 17:30:36 +03:00
|
|
|
> highlightfiles = **.py and size('<100KB')
|
2010-09-26 22:41:32 +04:00
|
|
|
> EOF
|
|
|
|
$ hg init test
|
|
|
|
$ cd test
|
|
|
|
|
2016-01-26 17:27:12 +03:00
|
|
|
$ filterhtml () {
|
|
|
|
> sed -e "s/class=\"k\"/class=\"kn\"/g" \
|
2016-01-26 17:33:53 +03:00
|
|
|
> -e "s/class=\"mf\"/class=\"mi\"/g" \
|
2017-01-30 16:50:20 +03:00
|
|
|
> -e "s/class=\"vm\"/class=\"n\"/g" \
|
2016-01-26 17:33:53 +03:00
|
|
|
> -e "s/class=\"\([cs]\)[h12]\"/class=\"\1\"/g"
|
2016-01-26 17:27:12 +03:00
|
|
|
> }
|
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
create random Python file to exercise Pygments
|
|
|
|
|
|
|
|
$ cat <<EOF > primes.py
|
|
|
|
> """Fun with generators. Corresponding Haskell implementation:
|
|
|
|
>
|
|
|
|
> primes = 2 : sieve [3, 5..]
|
|
|
|
> where sieve (p:ns) = p : sieve [n | n <- ns, mod n p /= 0]
|
|
|
|
> """
|
|
|
|
>
|
|
|
|
> from itertools import dropwhile, ifilter, islice, count, chain
|
|
|
|
>
|
|
|
|
> def primes():
|
|
|
|
> """Generate all primes."""
|
|
|
|
> def sieve(ns):
|
|
|
|
> p = ns.next()
|
|
|
|
> # It is important to yield *here* in order to stop the
|
|
|
|
> # infinite recursion.
|
|
|
|
> yield p
|
|
|
|
> ns = ifilter(lambda n: n % p != 0, ns)
|
|
|
|
> for n in sieve(ns):
|
|
|
|
> yield n
|
|
|
|
>
|
|
|
|
> odds = ifilter(lambda i: i % 2 == 1, count())
|
|
|
|
> return chain([2], sieve(dropwhile(lambda n: n < 3, odds)))
|
|
|
|
>
|
|
|
|
> if __name__ == "__main__":
|
|
|
|
> import sys
|
|
|
|
> try:
|
|
|
|
> n = int(sys.argv[1])
|
|
|
|
> except (ValueError, IndexError):
|
|
|
|
> n = 10
|
|
|
|
> p = primes()
|
2017-07-25 07:00:14 +03:00
|
|
|
> print("The first %d primes: %s" % (n, list(islice(p, n))))
|
2010-09-26 22:41:32 +04:00
|
|
|
> EOF
|
2015-07-22 05:19:17 +03:00
|
|
|
$ echo >> primes.py # to test html markup with an empty line just before EOF
|
2010-09-26 22:41:32 +04:00
|
|
|
$ hg ci -Ama
|
|
|
|
adding primes.py
|
|
|
|
|
|
|
|
hg serve
|
|
|
|
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve -p 0 --port-file $TESTTMP/.port -d -n test --pid-file=hg.pid -A access.log -E errors.log
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2010-09-26 22:41:32 +04:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
|
|
hgweb filerevision, html
|
|
|
|
|
2016-01-26 17:27:12 +03:00
|
|
|
$ (get-with-headers.py localhost:$HGPORT 'file/tip/primes.py') | filterhtml
|
2010-09-26 22:41:32 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
|
|
|
|
<head>
|
|
|
|
<link rel="icon" href="/static/hgicon.png" type="image/png" />
|
|
|
|
<meta name="robots" content="index, nofollow" />
|
|
|
|
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
|
2011-04-30 13:16:52 +04:00
|
|
|
<script type="text/javascript" src="/static/mercurial.js"></script>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
<link rel="stylesheet" href="/highlightcss" type="text/css" />
|
2017-07-25 07:00:14 +03:00
|
|
|
<title>test: f4fca47b67e6 primes.py</title>
|
2010-09-26 22:41:32 +04:00
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
|
|
|
|
<div class="container">
|
|
|
|
<div class="menu">
|
|
|
|
<div class="logo">
|
2015-09-30 23:43:49 +03:00
|
|
|
<a href="https://mercurial-scm.org/">
|
2010-09-26 22:41:32 +04:00
|
|
|
<img src="/static/hglogo.png" alt="mercurial" /></a>
|
|
|
|
</div>
|
|
|
|
<ul>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/shortlog/tip">log</a></li>
|
|
|
|
<li><a href="/graph/tip">graph</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/tags">tags</a></li>
|
2014-04-17 04:36:08 +04:00
|
|
|
<li><a href="/bookmarks">bookmarks</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/branches">branches</a></li>
|
|
|
|
</ul>
|
|
|
|
<ul>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/rev/tip">changeset</a></li>
|
|
|
|
<li><a href="/file/tip/">browse</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
</ul>
|
|
|
|
<ul>
|
|
|
|
<li class="active">file</li>
|
|
|
|
<li><a href="/file/tip/primes.py">latest</a></li>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/diff/tip/primes.py">diff</a></li>
|
|
|
|
<li><a href="/comparison/tip/primes.py">comparison</a></li>
|
|
|
|
<li><a href="/annotate/tip/primes.py">annotate</a></li>
|
|
|
|
<li><a href="/log/tip/primes.py">file log</a></li>
|
|
|
|
<li><a href="/raw-file/tip/primes.py">raw</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
</ul>
|
2010-10-10 02:58:48 +04:00
|
|
|
<ul>
|
|
|
|
<li><a href="/help">help</a></li>
|
|
|
|
</ul>
|
2010-09-26 22:41:32 +04:00
|
|
|
</div>
|
|
|
|
|
|
|
|
<div class="main">
|
2013-01-10 05:10:44 +04:00
|
|
|
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
|
2015-06-18 12:06:18 +03:00
|
|
|
<h3>
|
2017-07-25 07:00:14 +03:00
|
|
|
view primes.py @ 0:<a href="/rev/f4fca47b67e6">f4fca47b67e6</a>
|
2017-11-16 17:21:03 +03:00
|
|
|
<span class="phase">draft</span> <span class="branchhead">default</span> <span class="tag">tip</span>
|
2015-06-18 12:06:18 +03:00
|
|
|
</h3>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
<form class="search" action="/log">
|
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
<p><input name="rev" id="search1" type="text" size="30" value="" /></p>
|
2013-09-06 13:30:57 +04:00
|
|
|
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
|
|
|
|
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</form>
|
|
|
|
|
|
|
|
<div class="description">a</div>
|
|
|
|
|
|
|
|
<table id="changesetEntry">
|
|
|
|
<tr>
|
|
|
|
<th class="author">author</th>
|
|
|
|
<td class="author">test</td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<th class="date">date</th>
|
hgweb: fix dynamic date calculation not working under Safari
While Chrome, Firefox, and IE 6+ support the current date format being
passed to Date(), Safari doesn't:
> new Date('Mon Oct 24 13:58:01 2011 +0200')
Invalid Date
However, the rfc822date format--officially supported by
ECMAScript[1]--does work:
> new Date('Mon, 24 Oct 2011 13:58:01 +0200')
Mon Oct 24 2011 04:58:01 GMT-0700 (PDT)
This change replaces all instances of {date|date} in HTML with
{date|rfc822date}. For elements that only have the "age" class,
there's no outward change for users with JavaScript enabled. For
elements with both the "age" and "date" classes, the full date
displayed uses the new format.
Tested in IE 6, Safari 5.1.1, Google Chrome 15, and Firefox 7.0.1.
[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse
2011-10-27 22:57:08 +04:00
|
|
|
<td class="date age">Thu, 01 Jan 1970 00:00:00 +0000</td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<th class="author">parents</th>
|
|
|
|
<td class="author"></td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<th class="author">children</th>
|
|
|
|
<td class="author"></td>
|
|
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
<div class="overflow">
|
2013-07-12 15:58:13 +04:00
|
|
|
<div class="sourcefirst linewraptoggle">line wrap: <a class="linewraplink" href="javascript:toggleLinewrap()">on</a></div>
|
2010-09-26 22:41:32 +04:00
|
|
|
<div class="sourcefirst"> line source</div>
|
2017-06-21 18:07:51 +03:00
|
|
|
<pre class="sourcelines stripes4 wrap bottomline"
|
|
|
|
data-logurl="/log/tip/primes.py"
|
|
|
|
data-selectabletag="SPAN"
|
|
|
|
data-ishead="1">
|
|
|
|
|
2017-06-20 15:44:56 +03:00
|
|
|
<span id="l1"><span class="sd">"""Fun with generators. Corresponding Haskell implementation:</span></span><a href="#l1"></a>
|
hgweb: code selection without line numbers in file source view
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>.
2013-07-04 14:18:44 +04:00
|
|
|
<span id="l2"></span><a href="#l2"></a>
|
2017-06-20 15:44:56 +03:00
|
|
|
<span id="l3"><span class="sd">primes = 2 : sieve [3, 5..]</span></span><a href="#l3"></a>
|
|
|
|
<span id="l4"><span class="sd"> where sieve (p:ns) = p : sieve [n | n <- ns, mod n p /= 0]</span></span><a href="#l4"></a>
|
|
|
|
<span id="l5"><span class="sd">"""</span></span><a href="#l5"></a>
|
|
|
|
<span id="l6"></span><a href="#l6"></a>
|
|
|
|
<span id="l7"><span class="kn">from</span> <span class="nn">itertools</span> <span class="kn">import</span> <span class="n">dropwhile</span><span class="p">,</span> <span class="n">ifilter</span><span class="p">,</span> <span class="n">islice</span><span class="p">,</span> <span class="n">count</span><span class="p">,</span> <span class="n">chain</span></span><a href="#l7"></a>
|
hgweb: code selection without line numbers in file source view
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>.
2013-07-04 14:18:44 +04:00
|
|
|
<span id="l8"></span><a href="#l8"></a>
|
2017-06-20 15:44:56 +03:00
|
|
|
<span id="l9"><span class="kn">def</span> <span class="nf">primes</span><span class="p">():</span></span><a href="#l9"></a>
|
|
|
|
<span id="l10"> <span class="sd">"""Generate all primes."""</span></span><a href="#l10"></a>
|
|
|
|
<span id="l11"> <span class="kn">def</span> <span class="nf">sieve</span><span class="p">(</span><span class="n">ns</span><span class="p">):</span></span><a href="#l11"></a>
|
|
|
|
<span id="l12"> <span class="n">p</span> <span class="o">=</span> <span class="n">ns</span><span class="o">.</span><span class="n">next</span><span class="p">()</span></span><a href="#l12"></a>
|
|
|
|
<span id="l13"> <span class="c"># It is important to yield *here* in order to stop the</span></span><a href="#l13"></a>
|
|
|
|
<span id="l14"> <span class="c"># infinite recursion.</span></span><a href="#l14"></a>
|
|
|
|
<span id="l15"> <span class="kn">yield</span> <span class="n">p</span></span><a href="#l15"></a>
|
|
|
|
<span id="l16"> <span class="n">ns</span> <span class="o">=</span> <span class="n">ifilter</span><span class="p">(</span><span class="kn">lambda</span> <span class="n">n</span><span class="p">:</span> <span class="n">n</span> <span class="o">%</span> <span class="n">p</span> <span class="o">!=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ns</span><span class="p">)</span></span><a href="#l16"></a>
|
|
|
|
<span id="l17"> <span class="kn">for</span> <span class="n">n</span> <span class="ow">in</span> <span class="n">sieve</span><span class="p">(</span><span class="n">ns</span><span class="p">):</span></span><a href="#l17"></a>
|
|
|
|
<span id="l18"> <span class="kn">yield</span> <span class="n">n</span></span><a href="#l18"></a>
|
|
|
|
<span id="l19"></span><a href="#l19"></a>
|
|
|
|
<span id="l20"> <span class="n">odds</span> <span class="o">=</span> <span class="n">ifilter</span><span class="p">(</span><span class="kn">lambda</span> <span class="n">i</span><span class="p">:</span> <span class="n">i</span> <span class="o">%</span> <span class="mi">2</span> <span class="o">==</span> <span class="mi">1</span><span class="p">,</span> <span class="n">count</span><span class="p">())</span></span><a href="#l20"></a>
|
|
|
|
<span id="l21"> <span class="kn">return</span> <span class="n">chain</span><span class="p">([</span><span class="mi">2</span><span class="p">],</span> <span class="n">sieve</span><span class="p">(</span><span class="n">dropwhile</span><span class="p">(</span><span class="kn">lambda</span> <span class="n">n</span><span class="p">:</span> <span class="n">n</span> <span class="o"><</span> <span class="mi">3</span><span class="p">,</span> <span class="n">odds</span><span class="p">)))</span></span><a href="#l21"></a>
|
|
|
|
<span id="l22"></span><a href="#l22"></a>
|
|
|
|
<span id="l23"><span class="kn">if</span> <span class="n">__name__</span> <span class="o">==</span> <span class="s">"__main__"</span><span class="p">:</span></span><a href="#l23"></a>
|
|
|
|
<span id="l24"> <span class="kn">import</span> <span class="nn">sys</span></span><a href="#l24"></a>
|
|
|
|
<span id="l25"> <span class="kn">try</span><span class="p">:</span></span><a href="#l25"></a>
|
|
|
|
<span id="l26"> <span class="n">n</span> <span class="o">=</span> <span class="nb">int</span><span class="p">(</span><span class="n">sys</span><span class="o">.</span><span class="n">argv</span><span class="p">[</span><span class="mi">1</span><span class="p">])</span></span><a href="#l26"></a>
|
|
|
|
<span id="l27"> <span class="kn">except</span> <span class="p">(</span><span class="ne">ValueError</span><span class="p">,</span> <span class="ne">IndexError</span><span class="p">):</span></span><a href="#l27"></a>
|
|
|
|
<span id="l28"> <span class="n">n</span> <span class="o">=</span> <span class="mi">10</span></span><a href="#l28"></a>
|
|
|
|
<span id="l29"> <span class="n">p</span> <span class="o">=</span> <span class="n">primes</span><span class="p">()</span></span><a href="#l29"></a>
|
2017-07-25 07:00:14 +03:00
|
|
|
<span id="l30"> <span class="kn">print</span><span class="p">(</span><span class="s">"The first </span><span class="si">%d</span><span class="s"> primes: </span><span class="si">%s</span><span class="s">"</span> <span class="o">%</span> <span class="p">(</span><span class="n">n</span><span class="p">,</span> <span class="nb">list</span><span class="p">(</span><span class="n">islice</span><span class="p">(</span><span class="n">p</span><span class="p">,</span> <span class="n">n</span><span class="p">))))</span></span><a href="#l30"></a>
|
2017-06-21 18:07:51 +03:00
|
|
|
<span id="l31"></span><a href="#l31"></a>
|
|
|
|
</pre>
|
2010-09-26 22:41:32 +04:00
|
|
|
</div>
|
2017-03-29 23:26:16 +03:00
|
|
|
|
2017-04-03 11:02:55 +03:00
|
|
|
<script type="text/javascript" src="/static/followlines.js"></script>
|
2017-03-29 23:26:16 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
</html>
|
|
|
|
|
|
|
|
|
|
|
|
hgweb fileannotate, html
|
|
|
|
|
2016-01-26 17:27:12 +03:00
|
|
|
$ (get-with-headers.py localhost:$HGPORT 'annotate/tip/primes.py') | filterhtml
|
2010-09-26 22:41:32 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
|
|
|
|
<head>
|
|
|
|
<link rel="icon" href="/static/hgicon.png" type="image/png" />
|
|
|
|
<meta name="robots" content="index, nofollow" />
|
|
|
|
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
|
2011-04-30 13:16:52 +04:00
|
|
|
<script type="text/javascript" src="/static/mercurial.js"></script>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
<link rel="stylesheet" href="/highlightcss" type="text/css" />
|
|
|
|
<title>test: primes.py annotate</title>
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
|
|
|
|
<div class="container">
|
|
|
|
<div class="menu">
|
|
|
|
<div class="logo">
|
2015-09-30 23:43:49 +03:00
|
|
|
<a href="https://mercurial-scm.org/">
|
2010-09-26 22:41:32 +04:00
|
|
|
<img src="/static/hglogo.png" alt="mercurial" /></a>
|
|
|
|
</div>
|
|
|
|
<ul>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/shortlog/tip">log</a></li>
|
|
|
|
<li><a href="/graph/tip">graph</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/tags">tags</a></li>
|
2011-03-13 17:10:01 +03:00
|
|
|
<li><a href="/bookmarks">bookmarks</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/branches">branches</a></li>
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
<ul>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/rev/tip">changeset</a></li>
|
|
|
|
<li><a href="/file/tip/">browse</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
</ul>
|
|
|
|
<ul>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/file/tip/primes.py">file</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/file/tip/primes.py">latest</a></li>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/diff/tip/primes.py">diff</a></li>
|
|
|
|
<li><a href="/comparison/tip/primes.py">comparison</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li class="active">annotate</li>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/log/tip/primes.py">file log</a></li>
|
2016-12-29 01:48:17 +03:00
|
|
|
<li><a href="/raw-file/tip/primes.py">raw</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
</ul>
|
2010-10-10 02:58:48 +04:00
|
|
|
<ul>
|
|
|
|
<li><a href="/help">help</a></li>
|
|
|
|
</ul>
|
2010-09-26 22:41:32 +04:00
|
|
|
</div>
|
|
|
|
|
|
|
|
<div class="main">
|
2013-01-10 05:10:44 +04:00
|
|
|
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
|
2015-06-18 12:06:18 +03:00
|
|
|
<h3>
|
2017-07-25 07:00:14 +03:00
|
|
|
annotate primes.py @ 0:<a href="/rev/f4fca47b67e6">f4fca47b67e6</a>
|
2017-11-16 17:21:03 +03:00
|
|
|
<span class="phase">draft</span> <span class="branchhead">default</span> <span class="tag">tip</span>
|
2015-06-18 12:06:18 +03:00
|
|
|
</h3>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
<form class="search" action="/log">
|
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
<p><input name="rev" id="search1" type="text" size="30" value="" /></p>
|
2013-09-06 13:30:57 +04:00
|
|
|
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
|
|
|
|
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</form>
|
|
|
|
|
|
|
|
<div class="description">a</div>
|
|
|
|
|
|
|
|
<table id="changesetEntry">
|
|
|
|
<tr>
|
|
|
|
<th class="author">author</th>
|
|
|
|
<td class="author">test</td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<th class="date">date</th>
|
hgweb: fix dynamic date calculation not working under Safari
While Chrome, Firefox, and IE 6+ support the current date format being
passed to Date(), Safari doesn't:
> new Date('Mon Oct 24 13:58:01 2011 +0200')
Invalid Date
However, the rfc822date format--officially supported by
ECMAScript[1]--does work:
> new Date('Mon, 24 Oct 2011 13:58:01 +0200')
Mon Oct 24 2011 04:58:01 GMT-0700 (PDT)
This change replaces all instances of {date|date} in HTML with
{date|rfc822date}. For elements that only have the "age" class,
there's no outward change for users with JavaScript enabled. For
elements with both the "age" and "date" classes, the full date
displayed uses the new format.
Tested in IE 6, Safari 5.1.1, Google Chrome 15, and Firefox 7.0.1.
[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse
2011-10-27 22:57:08 +04:00
|
|
|
<td class="date age">Thu, 01 Jan 1970 00:00:00 +0000</td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<th class="author">parents</th>
|
|
|
|
<td class="author"></td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<th class="author">children</th>
|
|
|
|
<td class="author"></td>
|
|
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
2017-09-30 11:01:36 +03:00
|
|
|
|
|
|
|
<form id="diffopts-form"
|
|
|
|
data-ignorews="0"
|
|
|
|
data-ignorewsamount="0"
|
|
|
|
data-ignorewseol="0"
|
|
|
|
data-ignoreblanklines="0">
|
|
|
|
<span>Ignore whitespace changes - </span>
|
|
|
|
<span>Everywhere:</span>
|
|
|
|
<input id="ignorews-checkbox" type="checkbox" />
|
|
|
|
<span>Within whitespace:</span>
|
|
|
|
<input id="ignorewsamount-checkbox" type="checkbox" />
|
|
|
|
<span>At end of lines:</span>
|
|
|
|
<input id="ignorewseol-checkbox" type="checkbox" />
|
|
|
|
</form>
|
|
|
|
|
|
|
|
<script type="text/javascript">
|
|
|
|
renderDiffOptsForm();
|
|
|
|
</script>
|
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
<div class="overflow">
|
|
|
|
<table class="bigtable">
|
2015-02-06 10:52:55 +03:00
|
|
|
<thead>
|
2010-09-26 22:41:32 +04:00
|
|
|
<tr>
|
|
|
|
<th class="annotate">rev</th>
|
|
|
|
<th class="line"> line source</th>
|
|
|
|
</tr>
|
2015-02-06 10:52:55 +03:00
|
|
|
</thead>
|
2017-06-21 18:17:17 +03:00
|
|
|
<tbody class="stripes2 sourcelines"
|
|
|
|
data-logurl="/log/tip/primes.py"
|
|
|
|
data-selectabletag="TR"
|
|
|
|
data-ishead="1">
|
2013-07-13 17:43:45 +04:00
|
|
|
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l1" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l1">
|
2016-07-12 16:07:37 +03:00
|
|
|
0
|
2016-06-28 12:42:42 +03:00
|
|
|
</a>
|
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l1">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l1"> 1</a> <span class="sd">"""Fun with generators. Corresponding Haskell implementation:</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l2" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l2">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l2"> 2</a> </td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l3" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l3">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l3"> 3</a> <span class="sd">primes = 2 : sieve [3, 5..]</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l4" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l4">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l4"> 4</a> <span class="sd"> where sieve (p:ns) = p : sieve [n | n <- ns, mod n p /= 0]</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l5" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l5">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l5"> 5</a> <span class="sd">"""</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l6" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l6">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l6"> 6</a> </td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l7" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l7">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l7"> 7</a> <span class="kn">from</span> <span class="nn">itertools</span> <span class="kn">import</span> <span class="n">dropwhile</span><span class="p">,</span> <span class="n">ifilter</span><span class="p">,</span> <span class="n">islice</span><span class="p">,</span> <span class="n">count</span><span class="p">,</span> <span class="n">chain</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l8" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l8">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l8"> 8</a> </td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l9" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l9">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l9"> 9</a> <span class="kn">def</span> <span class="nf">primes</span><span class="p">():</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l10" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l10">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l10"> 10</a> <span class="sd">"""Generate all primes."""</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l11" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l11">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l11"> 11</a> <span class="kn">def</span> <span class="nf">sieve</span><span class="p">(</span><span class="n">ns</span><span class="p">):</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l12" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l12">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l12"> 12</a> <span class="n">p</span> <span class="o">=</span> <span class="n">ns</span><span class="o">.</span><span class="n">next</span><span class="p">()</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l13" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l13">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l13"> 13</a> <span class="c"># It is important to yield *here* in order to stop the</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l14" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l14">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l14"> 14</a> <span class="c"># infinite recursion.</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l15" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l15">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l15"> 15</a> <span class="kn">yield</span> <span class="n">p</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l16" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l16">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l16"> 16</a> <span class="n">ns</span> <span class="o">=</span> <span class="n">ifilter</span><span class="p">(</span><span class="kn">lambda</span> <span class="n">n</span><span class="p">:</span> <span class="n">n</span> <span class="o">%</span> <span class="n">p</span> <span class="o">!=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ns</span><span class="p">)</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l17" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l17">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l17"> 17</a> <span class="kn">for</span> <span class="n">n</span> <span class="ow">in</span> <span class="n">sieve</span><span class="p">(</span><span class="n">ns</span><span class="p">):</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l18" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l18">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l18"> 18</a> <span class="kn">yield</span> <span class="n">n</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l19" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l19">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l19"> 19</a> </td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l20" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l20">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l20"> 20</a> <span class="n">odds</span> <span class="o">=</span> <span class="n">ifilter</span><span class="p">(</span><span class="kn">lambda</span> <span class="n">i</span><span class="p">:</span> <span class="n">i</span> <span class="o">%</span> <span class="mi">2</span> <span class="o">==</span> <span class="mi">1</span><span class="p">,</span> <span class="n">count</span><span class="p">())</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l21" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l21">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l21"> 21</a> <span class="kn">return</span> <span class="n">chain</span><span class="p">([</span><span class="mi">2</span><span class="p">],</span> <span class="n">sieve</span><span class="p">(</span><span class="n">dropwhile</span><span class="p">(</span><span class="kn">lambda</span> <span class="n">n</span><span class="p">:</span> <span class="n">n</span> <span class="o"><</span> <span class="mi">3</span><span class="p">,</span> <span class="n">odds</span><span class="p">)))</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l22" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l22">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l22"> 22</a> </td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l23" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l23">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l23"> 23</a> <span class="kn">if</span> <span class="n">__name__</span> <span class="o">==</span> <span class="s">"__main__"</span><span class="p">:</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l24" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l24">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l24"> 24</a> <span class="kn">import</span> <span class="nn">sys</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l25" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l25">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l25"> 25</a> <span class="kn">try</span><span class="p">:</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l26" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l26">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l26"> 26</a> <span class="n">n</span> <span class="o">=</span> <span class="nb">int</span><span class="p">(</span><span class="n">sys</span><span class="o">.</span><span class="n">argv</span><span class="p">[</span><span class="mi">1</span><span class="p">])</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l27" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l27">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l27"> 27</a> <span class="kn">except</span> <span class="p">(</span><span class="ne">ValueError</span><span class="p">,</span> <span class="ne">IndexError</span><span class="p">):</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l28" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l28">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l28"> 28</a> <span class="n">n</span> <span class="o">=</span> <span class="mi">10</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l29" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l29">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l29"> 29</a> <span class="n">p</span> <span class="o">=</span> <span class="n">primes</span><span class="p">()</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l30" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l30">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</td>
|
2017-07-25 07:00:14 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l30"> 30</a> <span class="kn">print</span><span class="p">(</span><span class="s">"The first </span><span class="si">%d</span><span class="s"> primes: </span><span class="si">%s</span><span class="s">"</span> <span class="o">%</span> <span class="p">(</span><span class="n">n</span><span class="p">,</span> <span class="nb">list</span><span class="p">(</span><span class="n">islice</span><span class="p">(</span><span class="n">p</span><span class="p">,</span> <span class="n">n</span><span class="p">))))</span></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
</tr>
|
2016-06-02 17:26:50 +03:00
|
|
|
<tr id="l31" class="thisrev">
|
2016-07-16 09:49:07 +03:00
|
|
|
<td class="annotate parity0">
|
2016-06-07 13:10:01 +03:00
|
|
|
|
2016-06-28 12:42:42 +03:00
|
|
|
<div class="annotate-info">
|
2016-07-12 16:09:07 +03:00
|
|
|
<div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/annotate/f4fca47b67e6/primes.py#l31">
|
|
|
|
f4fca47b67e6</a>
|
2016-07-12 16:09:07 +03:00
|
|
|
a
|
|
|
|
</div>
|
2016-07-12 16:07:37 +03:00
|
|
|
<div><em>test</em></div>
|
2016-06-28 12:42:42 +03:00
|
|
|
<div>parents: </div>
|
2017-07-25 07:00:14 +03:00
|
|
|
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
|
|
|
|
<a href="/rev/f4fca47b67e6">changeset</a>
|
2016-06-28 12:42:42 +03:00
|
|
|
</div>
|
2015-07-22 05:19:17 +03:00
|
|
|
</td>
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
<td class="source followlines-btn-parent"><a href="#l31"> 31</a> </td>
|
2015-07-22 05:19:17 +03:00
|
|
|
</tr>
|
2013-07-13 17:43:45 +04:00
|
|
|
</tbody>
|
2010-09-26 22:41:32 +04:00
|
|
|
</table>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
2017-06-21 18:17:17 +03:00
|
|
|
<script type="text/javascript" src="/static/followlines.js"></script>
|
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
</html>
|
|
|
|
|
|
|
|
|
|
|
|
hgweb fileannotate, raw
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ (get-with-headers.py localhost:$HGPORT 'annotate/tip/primes.py?style=raw') \
|
2010-09-26 22:41:32 +04:00
|
|
|
> | sed "s/test@//" > a
|
|
|
|
$ echo "200 Script output follows" > b
|
|
|
|
$ echo "" >> b
|
|
|
|
$ echo "" >> b
|
|
|
|
$ hg annotate "primes.py" >> b
|
|
|
|
$ echo "" >> b
|
|
|
|
$ echo "" >> b
|
|
|
|
$ echo "" >> b
|
|
|
|
$ echo "" >> b
|
2014-02-20 01:46:49 +04:00
|
|
|
$ cmp b a || diff -u b a
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
hgweb filerevision, raw
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ (get-with-headers.py localhost:$HGPORT 'file/tip/primes.py?style=raw') \
|
2010-09-26 22:41:32 +04:00
|
|
|
> > a
|
|
|
|
$ echo "200 Script output follows" > b
|
|
|
|
$ echo "" >> b
|
|
|
|
$ hg cat primes.py >> b
|
2014-02-20 01:46:49 +04:00
|
|
|
$ cmp b a || diff -u b a
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
hgweb highlightcss friendly
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'highlightcss' > out
|
2010-09-26 22:41:32 +04:00
|
|
|
$ head -n 4 out
|
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
/* pygments_style = friendly */
|
|
|
|
|
|
|
|
$ rm out
|
|
|
|
|
|
|
|
errors encountered
|
|
|
|
|
|
|
|
$ cat errors.log
|
2015-06-08 22:55:40 +03:00
|
|
|
$ killdaemons.py
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
Change the pygments style
|
|
|
|
|
|
|
|
$ cat > .hg/hgrc <<EOF
|
|
|
|
> [web]
|
|
|
|
> pygments_style = fruity
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
hg serve again
|
|
|
|
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve -p 0 --port-file $TESTTMP/.port -d -n test --pid-file=hg.pid -A access.log -E errors.log
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2010-09-26 22:41:32 +04:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
|
|
hgweb highlightcss fruity
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'highlightcss' > out
|
2010-09-26 22:41:32 +04:00
|
|
|
$ head -n 4 out
|
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
/* pygments_style = fruity */
|
|
|
|
|
|
|
|
$ rm out
|
|
|
|
|
highlight: add highlightfiles config option which takes a fileset (issue3005)
Highlight extension lacked a way to limit files by size, by extension, and/or
by any other part of file path. A good solution would be to use a fileset,
since it can check file path, extension and size (and more) in one expression.
So this change introduces such an option, highlighfiles, which takes a fileset
and on each request decides if the requested file should be highlighted.
The default "size('<5M')" is, in a way, suggested in issue3005.
checkfctx() limits the amount of work to just one file (subset kwarg in
fileset.matchctx()).
Monkey-patching works around issue4568, otherwise using filesets here while
running hgweb in directory mode would say, for example, "Abort: **.py not under
root", but this fix is very local and probably far from ideal. I suspect there
to be a way to fix this for the whole hgweb and resolve the issue, but I don't
know how to do it.
2015-09-16 17:30:36 +03:00
|
|
|
errors encountered
|
|
|
|
|
|
|
|
$ cat errors.log
|
|
|
|
$ killdaemons.py
|
|
|
|
|
|
|
|
only highlight C source files
|
|
|
|
|
|
|
|
$ cat > .hg/hgrc <<EOF
|
|
|
|
> [web]
|
|
|
|
> highlightfiles = **.c
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
hg serve again
|
|
|
|
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve -p 0 --port-file $TESTTMP/.port -d -n test --pid-file=hg.pid -A access.log -E errors.log
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
highlight: add highlightfiles config option which takes a fileset (issue3005)
Highlight extension lacked a way to limit files by size, by extension, and/or
by any other part of file path. A good solution would be to use a fileset,
since it can check file path, extension and size (and more) in one expression.
So this change introduces such an option, highlighfiles, which takes a fileset
and on each request decides if the requested file should be highlighted.
The default "size('<5M')" is, in a way, suggested in issue3005.
checkfctx() limits the amount of work to just one file (subset kwarg in
fileset.matchctx()).
Monkey-patching works around issue4568, otherwise using filesets here while
running hgweb in directory mode would say, for example, "Abort: **.py not under
root", but this fix is very local and probably far from ideal. I suspect there
to be a way to fix this for the whole hgweb and resolve the issue, but I don't
know how to do it.
2015-09-16 17:30:36 +03:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
|
|
test that fileset in highlightfiles works and primes.py is not highlighted
|
|
|
|
|
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/tip/primes.py' | grep 'id="l11"'
|
2017-06-20 15:44:56 +03:00
|
|
|
<span id="l11"> def sieve(ns):</span><a href="#l11"></a>
|
highlight: add highlightfiles config option which takes a fileset (issue3005)
Highlight extension lacked a way to limit files by size, by extension, and/or
by any other part of file path. A good solution would be to use a fileset,
since it can check file path, extension and size (and more) in one expression.
So this change introduces such an option, highlighfiles, which takes a fileset
and on each request decides if the requested file should be highlighted.
The default "size('<5M')" is, in a way, suggested in issue3005.
checkfctx() limits the amount of work to just one file (subset kwarg in
fileset.matchctx()).
Monkey-patching works around issue4568, otherwise using filesets here while
running hgweb in directory mode would say, for example, "Abort: **.py not under
root", but this fix is very local and probably far from ideal. I suspect there
to be a way to fix this for the whole hgweb and resolve the issue, but I don't
know how to do it.
2015-09-16 17:30:36 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
errors encountered
|
|
|
|
|
|
|
|
$ cat errors.log
|
|
|
|
$ cd ..
|
|
|
|
$ hg init eucjp
|
|
|
|
$ cd eucjp
|
2014-10-15 23:35:59 +04:00
|
|
|
$ $PYTHON -c 'print("\265\376")' >> eucjp.txt # Japanese kanji "Kyo"
|
2010-09-26 22:41:32 +04:00
|
|
|
$ hg ci -Ama
|
|
|
|
adding eucjp.txt
|
|
|
|
$ hgserveget () {
|
2015-06-08 22:55:40 +03:00
|
|
|
> killdaemons.py
|
2010-09-26 22:41:32 +04:00
|
|
|
> echo % HGENCODING="$1" hg serve
|
2018-02-08 22:19:42 +03:00
|
|
|
> HGENCODING="$1" hg serve -p 0 --port-file .p -d -n test --pid-file=hg.pid -E errors.log
|
|
|
|
> HGPORT=`cat .p`
|
|
|
|
> rm .p
|
2010-09-26 22:41:32 +04:00
|
|
|
> cat hg.pid >> $DAEMON_PIDS
|
|
|
|
>
|
|
|
|
> echo % hgweb filerevision, html
|
2015-06-08 22:44:30 +03:00
|
|
|
> get-with-headers.py localhost:$HGPORT "file/tip/$2" \
|
2010-11-08 03:41:42 +03:00
|
|
|
> | grep '<div class="parity0 source">'
|
2010-09-26 22:41:32 +04:00
|
|
|
> echo % errors encountered
|
|
|
|
> cat errors.log
|
|
|
|
> }
|
|
|
|
$ hgserveget euc-jp eucjp.txt
|
|
|
|
% HGENCODING=euc-jp hg serve
|
|
|
|
% hgweb filerevision, html
|
|
|
|
% errors encountered
|
|
|
|
$ hgserveget utf-8 eucjp.txt
|
|
|
|
% HGENCODING=utf-8 hg serve
|
|
|
|
% hgweb filerevision, html
|
|
|
|
% errors encountered
|
|
|
|
$ hgserveget us-ascii eucjp.txt
|
|
|
|
% HGENCODING=us-ascii hg serve
|
|
|
|
% hgweb filerevision, html
|
|
|
|
% errors encountered
|
2012-06-11 03:40:51 +04:00
|
|
|
|
2015-10-15 04:22:16 +03:00
|
|
|
We attempt to highlight unknown files by default
|
|
|
|
|
|
|
|
$ killdaemons.py
|
|
|
|
|
|
|
|
$ cat > .hg/hgrc << EOF
|
|
|
|
> [web]
|
|
|
|
> highlightfiles = **
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
$ cat > unknownfile << EOF
|
2017-06-15 21:27:52 +03:00
|
|
|
> #!$PYTHON
|
2015-10-15 04:22:16 +03:00
|
|
|
> def foo():
|
|
|
|
> pass
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
$ hg add unknownfile
|
|
|
|
$ hg commit -m unknown unknownfile
|
|
|
|
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve -p 0 --port-file $TESTTMP/.port -d -n test --pid-file=hg.pid
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2015-10-15 04:22:16 +03:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/tip/unknownfile' | grep l2
|
|
|
|
<span id="l2"><span class="k">def</span> <span class="nf">foo</span><span class="p">():</span></span><a href="#l2"></a>
|
|
|
|
|
|
|
|
We can prevent Pygments from falling back to a non filename-based
|
|
|
|
detection mode
|
|
|
|
|
|
|
|
$ cat > .hg/hgrc << EOF
|
|
|
|
> [web]
|
|
|
|
> highlightfiles = **
|
|
|
|
> highlightonlymatchfilename = true
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
$ killdaemons.py
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve -p 0 --port-file $TESTTMP/.port -d -n test --pid-file=hg.pid
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2015-10-15 04:22:16 +03:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/tip/unknownfile' | grep l2
|
|
|
|
<span id="l2">def foo():</span><a href="#l2"></a>
|
|
|
|
|
2012-06-11 03:40:51 +04:00
|
|
|
$ cd ..
|