Skip to content
Snippets Groups Projects
  1. Feb 28, 2025
  2. Jan 30, 2025
    • Matt Harbison's avatar
      py3: update the remaining shebang lines (mostly tests) to `python3` · f8f14e6d032b
      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.
      f8f14e6d032b
  3. Jan 25, 2023
    • Anton Shestakov's avatar
      42baf12efd21
    • Anton Shestakov's avatar
      tests: make sure pygments can detect python script without extension · 37de1a154472
      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.
      37de1a154472
  4. Jan 18, 2020
  5. Nov 05, 2019
    • Gregory Szorc's avatar
      tests: write out file using bytes I/O · e7eb67eab53f
      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
      e7eb67eab53f
  6. Feb 17, 2019
    • Katsunori FUJIWARA's avatar
      tests: use NO_CHECK_EOF as heredoc limit mark to omit checking code fragments · 9d39671adadb
      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.
      9d39671adadb
  7. Oct 18, 2018
  8. Sep 19, 2018
  9. May 03, 2018
  10. Nov 16, 2017
    • Anton Shestakov's avatar
      hgweb: show commit phase if it's not public · a1de4ffaa7a8
      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
      a1de4ffaa7a8
  11. Nov 15, 2017
    • Anton Shestakov's avatar
      hgweb: move changeset "tags" to a template in map file (paper and coal) · 9acc0360ff67
      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.
      9acc0360ff67
  12. Sep 30, 2017
    • Gregory Szorc's avatar
      hgweb: add HTML elements to control whitespace settings for annotate · 6797f1fbc642
      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
      6797f1fbc642
  13. Jul 25, 2017
  14. Jul 03, 2017
    • Denis Laxalde's avatar
      hgweb: re-implement followlines UI selection using buttons · 32331f54930c
      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.
      32331f54930c
  15. Jun 21, 2017
    • Denis Laxalde's avatar
      hgweb: plug followlines action in annotate view · 1c97df5e3b46
      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).
      1c97df5e3b46
    • Denis Laxalde's avatar
      hgweb: parameterize the tag name of elements holding followlines selection · 7c82bfd55d47
      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.
      7c82bfd55d47
  16. Jun 15, 2017
  17. Jun 20, 2017
  18. Jun 09, 2017
    • Gregory Szorc's avatar
      hgweb: consolidate search form for paper · cba4461aa0a0
      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.
      cba4461aa0a0
  19. Apr 24, 2017
  20. Apr 03, 2017
  21. Mar 29, 2017
    • Denis Laxalde's avatar
      hgweb: expose a followlines UI in filerevision view · 04ec317b8128
      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).
      04ec317b8128
  22. Jan 30, 2017
  23. Jan 11, 2017
    • Gregory Szorc's avatar
      hgweb: call process_dates() via DOM event listener · eb7de21b15be
      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.
      eb7de21b15be
  24. Dec 28, 2016
    • Gregory Szorc's avatar
      hgweb: link to raw-file on annotation page (BC) · 011122b3b1c4
      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.
      011122b3b1c4
  25. Jul 16, 2016
  26. Jul 12, 2016
  27. Jun 14, 2016
  28. Jun 28, 2016
    • Denis Laxalde's avatar
      hgweb: add link to parents of annotated revision in annotate view · 9c37df347485
      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.
      9c37df347485
  29. Jun 07, 2016
    • Denis Laxalde's avatar
      hgweb: display blamed revision once per block in annotate view · f694e20193f2
      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."
      f694e20193f2
  30. Jun 02, 2016
    • Denis Laxalde's avatar
      hgweb: highlight data of the current revision in annotate view · 6b77adc2c7b5
      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.
      6b77adc2c7b5
  31. Jan 26, 2016
  32. Oct 15, 2015
    • Gregory Szorc's avatar
      highlight: add option to prevent content-only based fallback · 7a3f6490ef97
      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.
      7a3f6490ef97
  33. Sep 30, 2015
  34. Sep 16, 2015
    • Anton Shestakov's avatar
      highlight: add highlightfiles config option which takes a fileset (issue3005) · 3166bcc0c538
      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.
      3166bcc0c538
Loading