sapling/tests/test-highlight.t

1025 lines
36 KiB
Perl
Raw Normal View History

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
> highlightfiles = **.py and size('<100KB')
2010-09-26 22:41:32 +04:00
> EOF
$ hg init test
$ cd test
$ filterhtml () {
> sed -e "s/class=\"k\"/class=\"kn\"/g" \
> -e "s/class=\"mf\"/class=\"mi\"/g" \
> -e "s/class=\"vm\"/class=\"n\"/g" \
> -e "s/class=\"\([cs]\)[h12]\"/class=\"\1\"/g"
> }
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()
> print("The first %d primes: %s" % (n, list(islice(p, n))))
2010-09-26 22:41:32 +04:00
> EOF
$ 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
$ 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
$ (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" />
<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: 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>
<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>
<li><a href="/bookmarks">bookmarks</a></li>
2010-09-26 22:41:32 +04:00
<li><a href="/branches">branches</a></li>
</ul>
<ul>
<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>
<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>
<ul>
<li><a href="/help">help</a></li>
</ul>
2010-09-26 22:41:32 +04:00
</div>
<div class="main">
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
<h3>
view primes.py @ 0:<a href="/rev/f4fca47b67e6">f4fca47b67e6</a>
<span class="phase">draft</span> <span class="branchhead">default</span> <span class="tag">tip</span>
</h3>
2010-09-26 22:41:32 +04:00
2010-09-26 22:41:32 +04:00
<form class="search" action="/log">
<p><input name="rev" id="search1" type="text" size="30" value="" /></p>
<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">&#116;&#101;&#115;&#116;</td>
</tr>
<tr>
<th class="date">date</th>
<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">
<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>
<pre class="sourcelines stripes4 wrap bottomline"
data-logurl="/log/tip/primes.py"
data-selectabletag="SPAN"
data-ishead="1">
<span id="l1"><span class="sd">&quot;&quot;&quot;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 &nbsp; 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, &nbsp; 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>
<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 &lt;- ns, mod n p /= 0]</span></span><a href="#l4"></a>
<span id="l5"><span class="sd">&quot;&quot;&quot;</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 &nbsp; 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, &nbsp; 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>
<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">&quot;&quot;&quot;Generate all primes.&quot;&quot;&quot;</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">&lt;</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">&quot;__main__&quot;</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>
<span id="l30"> <span class="kn">print</span><span class="p">(</span><span class="s">&quot;The first </span><span class="si">%d</span><span class="s"> primes: </span><span class="si">%s</span><span class="s">&quot;</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>
<span id="l31"></span><a href="#l31"></a>
</pre>
2010-09-26 22:41:32 +04:00
</div>
<script type="text/javascript" src="/static/followlines.js"></script>
2010-09-26 22:41:32 +04:00
</div>
</div>
</body>
</html>
hgweb fileannotate, html
$ (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" />
<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>
<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>
<li><a href="/bookmarks">bookmarks</a></li>
2010-09-26 22:41:32 +04:00
<li><a href="/branches">branches</a></li>
</ul>
<ul>
<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><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>
<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>
<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>
<ul>
<li><a href="/help">help</a></li>
</ul>
2010-09-26 22:41:32 +04:00
</div>
<div class="main">
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
<h3>
annotate primes.py @ 0:<a href="/rev/f4fca47b67e6">f4fca47b67e6</a>
<span class="phase">draft</span> <span class="branchhead">default</span> <span class="tag">tip</span>
</h3>
2010-09-26 22:41:32 +04:00
2010-09-26 22:41:32 +04:00
<form class="search" action="/log">
<p><input name="rev" id="search1" type="text" size="30" value="" /></p>
<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">&#116;&#101;&#115;&#116;</td>
</tr>
<tr>
<th class="date">date</th>
<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>
hgweb: add HTML elements to control whitespace settings for annotate Building on top of the new URL query string arguments to control whitespace settings for annotate, this commit adds HTML checkboxes reflecting the values of these arguments to the paper and gitweb themes. The actual diff settings are now exported to the templating layer. The HTML templates add these as data-* attributes so they are accessible to the DOM. A new <form> with various <input> elements is added. The <form> is initially hidden via CSS. A shared JavaScript function (which runs after the <form> has been rendered but before the annotate HTML (because annotate HTML could take a while to load and we want the form to render quickly) takes care of setting the checked state of each box from the data-* attributes. It also registers an event handler to modify the URL and refresh the page whenever the checkbox state is changed. I'm using the URLSearchParams interface to perform URL manipulation. https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams tells me this may not be supported on older web browsers. Yes, apparently the web API didn't have a standard API to parse and format query strings until recently. Hence the check for the presence of this feature in the JavaScript. If the browser doesn't support the feature, the <form> will remain hidden and behavior will like it currently is. We could polyfill this feature or implement our own query string parsing. But I'm lazy and this could be done as a follow-up if people miss it. We could certainly expand this feature to support more diff options (such as lines of context). That's why the potentially reusable code is stored in a reusable place. It is also certainly possible to add diff controls to other pages that display diffs. But since Mozillians are making noise about controlling which revisions annotate shows, I figured I'd start there. .. feature:: Control whitespace settings for annotation on hgweb /annotate URLs on hgweb now accept query string arguments to influence how whitespace changes impact results. The arguments "ignorews," "ignorewsamount," "ignorewseol," and "ignoreblanklines" now have the same meaning as their [annotate] config section counterparts. Any provided setting overrides the server default. HTML checkboxes have been added to the paper and gitweb themes to expose current whitespace settings and to easily modify the current view. Differential Revision: https://phab.mercurial-scm.org/D850
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">
<thead>
2010-09-26 22:41:32 +04:00
<tr>
<th class="annotate">rev</th>
<th class="line">&nbsp;&nbsp;line source</th>
</tr>
</thead>
<tbody class="stripes2 sourcelines"
data-logurl="/log/tip/primes.py"
data-selectabletag="TR"
data-ishead="1">
<tr id="l1" class="thisrev">
<td class="annotate parity0">
<a href="/annotate/f4fca47b67e6/primes.py#l1">
0
</a>
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l1">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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">&quot;&quot;&quot;Fun with generators. Corresponding Haskell implementation:</span></td>
2010-09-26 22:41:32 +04:00
</tr>
<tr id="l2" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l2">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l3" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l3">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l4" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l4">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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 &lt;- ns, mod n p /= 0]</span></td>
2010-09-26 22:41:32 +04:00
</tr>
<tr id="l5" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l5">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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">&quot;&quot;&quot;</span></td>
2010-09-26 22:41:32 +04:00
</tr>
<tr id="l6" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l6">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l7" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l7">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l8" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l8">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l9" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l9">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l10" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l10">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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">&quot;&quot;&quot;Generate all primes.&quot;&quot;&quot;</span></td>
2010-09-26 22:41:32 +04:00
</tr>
<tr id="l11" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l11">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l12" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l12">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l13" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l13">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l14" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l14">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l15" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l15">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l16" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l16">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l17" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l17">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l18" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l18">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l19" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l19">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l20" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l20">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l21" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l21">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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">&lt;</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>
<tr id="l22" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l22">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l23" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l23">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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">&quot;__main__&quot;</span><span class="p">:</span></td>
2010-09-26 22:41:32 +04:00
</tr>
<tr id="l24" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l24">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l25" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l25">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l26" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l26">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l27" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l27">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l28" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l28">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l29" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l29">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</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>
<tr id="l30" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l30">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</div>
2010-09-26 22:41:32 +04:00
</td>
<td class="source followlines-btn-parent"><a href="#l30"> 30</a> <span class="kn">print</span><span class="p">(</span><span class="s">&quot;The first </span><span class="si">%d</span><span class="s"> primes: </span><span class="si">%s</span><span class="s">&quot;</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>
<tr id="l31" class="thisrev">
<td class="annotate parity0">
<div class="annotate-info">
<div>
<a href="/annotate/f4fca47b67e6/primes.py#l31">
f4fca47b67e6</a>
a
</div>
<div><em>&#116;&#101;&#115;&#116;</em></div>
<div>parents: </div>
<a href="/diff/f4fca47b67e6/primes.py">diff</a>
<a href="/rev/f4fca47b67e6">changeset</a>
</div>
</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>
</tr>
</tbody>
2010-09-26 22:41:32 +04:00
</table>
</div>
</div>
</div>
<script type="text/javascript" src="/static/followlines.js"></script>
2010-09-26 22:41:32 +04:00
</body>
</html>
hgweb fileannotate, raw
$ (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
$ cmp b a || diff -u b a
2010-09-26 22:41:32 +04:00
hgweb filerevision, raw
$ (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
$ cmp b a || diff -u b a
2010-09-26 22:41:32 +04:00
hgweb highlightcss friendly
$ 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
$ 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
$ 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
$ 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
errors encountered
$ cat errors.log
$ killdaemons.py
only highlight C source files
$ cat > .hg/hgrc <<EOF
> [web]
> highlightfiles = **.c
> EOF
hg serve again
$ 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`
$ 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"'
<span id="l11"> def sieve(ns):</span><a href="#l11"></a>
2010-09-26 22:41:32 +04:00
errors encountered
$ cat errors.log
$ cd ..
$ hg init eucjp
$ cd eucjp
$ $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 () {
> killdaemons.py
2010-09-26 22:41:32 +04:00
> echo % HGENCODING="$1" hg serve
> 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
> get-with-headers.py localhost:$HGPORT "file/tip/$2" \
> | 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
We attempt to highlight unknown files by default
$ killdaemons.py
$ cat > .hg/hgrc << EOF
> [web]
> highlightfiles = **
> EOF
$ cat > unknownfile << EOF
> #!$PYTHON
> def foo():
> pass
> EOF
$ hg add unknownfile
$ hg commit -m unknown unknownfile
$ hg serve -p 0 --port-file $TESTTMP/.port -d -n test --pid-file=hg.pid
$ HGPORT=`cat $TESTTMP/.port`
$ 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
$ hg serve -p 0 --port-file $TESTTMP/.port -d -n test --pid-file=hg.pid
$ HGPORT=`cat $TESTTMP/.port`
$ 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>
$ cd ..