- Feb 28, 2025
-
-
Anton Shestakov authored
Let's repeat 42baf12efd21.
-
- Jan 30, 2025
-
-
Matt Harbison authored
I noticed this when running `py hghave` on a system that still has Python2- the Windows launcher attempts to honor the version of python in the shebang, but `hghave` recently gained py3 type annotations, so that resulted in a SyntaxError. I guess CI has the compat shim installed to redirect `python` to `python3`, and maybe that's why nobody noticed. These were located by grepping for `#!.+python\b`. The remaining handful of cases are tests trying to find python files, which is fine as-is. The one thing to call out here is that apparently the RPM building hasn't worked with Python3 (or we've been getting lucky). `contrib/hg-ssh` has had a python3 shebang line since late 2020, which means the EOL anchor would have caused it to not match and not be replaced with `%{pythonexe}`. OTOH, it looks like that variable was used prior to the `hg-ssh` update in order to default to python3 (as opposed to using a specific /path/to/pythonX), and maybe the update to `hg-ssh` simply broke python2 builds. I'm not going to worry about this for now, since there are also direct calls to `setup.py`, which no longer work as of this release cycle. Somebody interested in RPMs can figure out all of the issues at once.
-
- Jan 25, 2023
-
-
Anton Shestakov authored
-
Anton Shestakov authored
This .t file was failing for me when running run-tests.py with python3.11. Then I tried to run it with python3.10 and it failed anyway, even though it's the default python3 interpreter. But with `python3 ./run-tests.py` it worked fine. And this is what I found while looking at the way pygments lexer checks if a file without extension is likely to be a python script: shebang_matches(text, r'pythonw?(3(\.\d)?)?') Take guess why it doesn't work for python >= 3.10. To work around this issue, we can simply hardcode an "easier" shebang for pygments. This path to python interpreter obviously doesn't need to be accurate, since we're not running this script.
-
- Jan 18, 2020
-
-
Gregory Szorc authored
Output changed slightly in pygments 2.5. I thought it was easier to copy the line and add a version check than to add a regular expression because the line has some special characters. I also like tests explicitly calling out where they vary. Differential Revision: https://phab.mercurial-scm.org/D7943
-
- Nov 05, 2019
-
-
Gregory Szorc authored
The encoding of sys.stdout varies between Python versions. So using a one-liner to write a file from a Unicode string is not deterministic. This commit writes out the file using bytes I/O to ensure we have exactly the bytes we want in the file. This change fixes a test failure in Python 3.5/3.6. Differential Revision: https://phab.mercurial-scm.org/D7226
-
- Feb 17, 2019
-
-
Katsunori FUJIWARA authored
This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts. "primes.py" embedded in test-highlight.t causes an error of check-commit.py below: don't use .next(), use next(...) But changing embedded primes.py is painful, because it is committed in test script, and affects hash IDs. On the other hand, primes.py itself is never executed in test script. Therefore, this patch uses NO_CHECK_EOF as heredoc limit mark in order to omit any checking on this code fragments.
-
- Oct 18, 2018
-
-
Matt Harbison authored
The hash changes are because the *.py file is committed to the repo.
-
- Sep 19, 2018
-
-
Matt Harbison authored
Python3 defaults to installing under "Program Files".
-
- May 03, 2018
-
-
Gregory Szorc authored
This restores the styling that was accidentally removed by the previous change to these files. Differential Revision: https://phab.mercurial-scm.org/D3438
-
Gregory Szorc authored
The use of inline href="javascript:" undermines CSP policies that don't allow inline javascript. This commit changes the registering of the diffstat and line wrapping toggle handlers to the the global DOMContentLoaded handler, thus eliminating all inline javascript from the paper template. Differential Revision: https://phab.mercurial-scm.org/D3437
-
- Nov 16, 2017
-
-
Anton Shestakov authored
In spartan theme phase is shown on its own table row, because there's no single line of "tags". Everywhere else phase is prepended to the list of "tags" of a changeset. Its element has a purple-ish color in gitweb and monoblue, and a dotted line under it and no color in paper and coal (as these themes are frugal with colors). This patch intentionally doesn't touch graph, because it needs a rewrite. I'll get to it pretty soon and in the process will add phase and everything that's still coming (e.g. obsolescence and instabilities). .. feature:: hgweb now displays phases of non-public changesets
-
- Nov 15, 2017
-
-
Anton Shestakov authored
This patch puts all these changeset "tags" into one template shared everywhere in paper and coal themes. But it should be noted that some of the templates had different sets of tags, in some cases it was intended, in others - most likely not. First, what's up with all these different ways to get changeset's branch. There are actually 3 ways to do it in hgweb, they can all be seen in this patch; "branches", "inbranch" and "branch". They are all lists that consist of 1 or 0 items: - "branches" has ctx.branch() if current changeset is the tip of that branch - "inbranch" has ctx.branch() if current changeset is _not_ the tip of that branch and the branch is not "default" - "branch" aka "changesetbranch" has ctx.branch() if the branch is not "default" The majority of cases (7 vs 2 + /graph) in paper theme used only option 3, which meant that "default" was never displayed. But other parts of the theme disagreed with this and used option 1 and option 2 together. For example, the default view (log) displays "default" on the branch tip (can be seen right about now on m-s.o/repo/hg), but it disappears when you click on the commit. Also, using option 3 alone meant that there was no way to tell if a changeset is the tip of its branch or not (it was always assumed that it's not, see how some css classes change from "branchname" to the correct "branchhead" in tests) -- so the two different css styles that exist in paper just for this were underused. I think this patch improves the situation, even though it changes the old (even if inconsistent) behavior. The new behavior matches that of gitweb and monoblue.
-
- Sep 30, 2017
-
-
Gregory Szorc authored
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
-
- Jul 25, 2017
-
-
Augie Fackler authored
This is easier than trying to do some sort of check-code shenanigans. Differential Revision: https://phab.mercurial-scm.org/D278
-
- Jul 03, 2017
-
-
Denis Laxalde authored
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.
-
- Jun 21, 2017
-
-
Denis Laxalde authored
Add the followlines.js script and corresponding parameters as data attribute on <tbody class="sourcelines"> element. Extend CSS rules so that they also match the DOM structure of annotate view. As previously, only address paper and gitweb styles (other styles do not have followlines at all).
-
Denis Laxalde authored
While plugging followlines.js into "annotate" view, we'll need to walk a different DOM structure from that of "filerevision" view. In particular, the selectable source line element is a <tr> in annotate view (in contrast with a <span> in filerevision view). So make this tag name a parameter of followlines.js script by passing its value as a "selectabletag" data attribute of <pre class="sourcelines"> element. As <pre class="sourcelines"> tags are getting quite long in templates, rewrite them on several lines.
-
- Jun 15, 2017
-
-
Augie Fackler authored
-
- Jun 20, 2017
-
-
Augie Fackler authored
It's about to be a source of trouble, but removing it changes a ton of test lines, so doing this change as a standalone commit.
-
- Jun 09, 2017
-
-
Gregory Szorc authored
AFAICT this was mostly a bunch of copy pasta. The only variation is some pages defined a "value" attribute. The "query" variable will just be empty on pages that don't accept it. So let's consolidate the template and remove the redundancy.
-
- Apr 24, 2017
-
-
Denis Laxalde authored
When on a filelog head, we are certain that there will be no descendant so the target of the "descending" link will lead to an empty log result. Do not display the link in this case.
-
- Apr 03, 2017
-
-
Denis Laxalde authored
So that the file name matches both the feature name and user facing vocabulary (e.g. the revset function).
-
- Mar 29, 2017
-
-
Denis Laxalde authored
In filerevision view (/file/<rev>/<fname>) we add some event listeners on mouse clicks of <span> elements in the <pre class="sourcelines"> block. Those listeners will capture a range of lines selected between two mouse clicks and a box inviting to follow the history of selected lines will then show up. Selected lines (i.e. the block of lines) get a CSS class which make them highlighted. Selection can be cancelled (and restarted) by either clicking on the cancel ("x") button in the invite box or clicking on any other source line. Also clicking twice on the same line will abort the selection and reset event listeners to restart the process. As a first step, this action is only advertised by the "cursor: cell" CSS rule on source lines elements as any other mechanisms would make the code significantly more complicated. This might be improved later. All JavaScript code lives in a new "linerangelog.js" file, sourced in filerevision template (only in "paper" style for now).
-
- Jan 30, 2017
-
-
Yuya Nishihara authored
The test failed on Debian sid because of new class="vm".
-
- Jan 11, 2017
-
-
Gregory Szorc authored
All the hgweb templates include mercurial.js in their header. All the hgweb templates have the same <script> boilerplate to run process_dates(). This patch factors that function call into mercurial.js as part of a DOMContentLoaded event listener.
-
- Dec 28, 2016
-
-
Gregory Szorc authored
Every other template has the "raw" link load "raw-file." However, fileannotate.tmpl's "raw" link loads "raw-annotate." This feels inconsistent and wrong. As far as I can tell, linking to the "raw annotate" view has occurred since 2006.
-
- Jul 16, 2016
-
-
Anton Shestakov authored
-
- Jul 12, 2016
-
-
Denis Laxalde authored
The link pointing the annotate view at this revision, just like the one in the left-column but accessible from anywhere.
-
Denis Laxalde authored
And display the full author information since there is enough space there.
-
- Jun 14, 2016
-
-
Denis Laxalde authored
-
- Jun 28, 2016
-
-
Denis Laxalde authored
The link is embedded into a div with class="annotate-info" that only shows up upon hover of the annotate column. To avoid duplicate hover-overs (this new one and the one coming from link's title), drop "title" attribute from a element and put it in the annotate-info element.
-
- Jun 07, 2016
-
-
Denis Laxalde authored
I.e. when a revision blames a block of source lines, only display the revision link on the first line of the block (this is identified by the "blockhead" key in annotate context). This addresses item "Visual grouping of changesets" of the blame improvements plan (https://www.mercurial-scm.org/wiki/BlamePlan) which states: "Typically there are block of lines all attributed to the same revision. Instead of rendering the revision/changeset for every line, we could only render it once per block."
-
- Jun 02, 2016
-
-
Denis Laxalde authored
* Distinguish the /annotate/<revision>/<file>#<linenumber> link when it would lead to the current page (i.e. <revision> is the current revision) (style it gray and undecorated). This indicates more clearly that this is a "dead-end" in blame navigation. * Display lines changed in current revision in green.
-
- Jan 26, 2016
-
-
Yuya Nishihara authored
It appears that several classes have 'h', '1', '2' suffixes on Pygments 2.1, which is the current version on Debian sid.
-
Yuya Nishihara authored
-
Yuya Nishihara authored
We had two variants for unknown reason, s/mf/mi/g and s/mi/mf/g. This patch unifies them to s/mf/mi/g so that we can introduce a utility function.
-
- Oct 15, 2015
-
-
Gregory Szorc authored
When Mozilla enabled Pygments on hg.mozilla.org, we got a lot of weirdly colorized files. Upon further investigation, the hightlight extension is first attempting a filename+content based match then falling back to a purely content-driven detection mode in Pygments. Sounds good in theory. Unfortunately, Pygments' content-driven detection establishes no minimum threshold for returning a lexer. Furthermore, the detection code for a number of languages is very liberal. For example, ActionScript 3 will return a confidence of 0.3 (out of 1.0) if the first 1k of the file we pass in matches the regex "\w+\s*:\s*\w"! Python matches on "import ". It's no coincidence that a number of our extension-less files were getting highlighted improperly. This patch adds an option to have the highlighter not fall back to purely content-based detection when filename+content detection failed. This can be enabled to render unlighted text instead of taking the risk that unknown file types are highlighted incorrectly. The old behavior is still the default.
-
- Sep 30, 2015
-
-
Matt Mackall authored
-
- Sep 16, 2015
-
-
Anton Shestakov authored
Highlight extension lacked a way to limit files by size, by extension, and/or by any other part of file path. A good solution would be to use a fileset, since it can check file path, extension and size (and more) in one expression. So this change introduces such an option, highlighfiles, which takes a fileset and on each request decides if the requested file should be highlighted. The default "size('<5M')" is, in a way, suggested in issue3005. checkfctx() limits the amount of work to just one file (subset kwarg in fileset.matchctx()). Monkey-patching works around issue4568, otherwise using filesets here while running hgweb in directory mode would say, for example, "Abort: **.py not under root", but this fix is very local and probably far from ideal. I suspect there to be a way to fix this for the whole hgweb and resolve the issue, but I don't know how to do it.
-