<div dir="ltr"><div><div>Mechanical reformatting makes "hg annotate" output more difficult to use, but it's not fatal. When the line you're interested in was affected by a reformatting changeset, you can note the changeset number <N>, and then look at "hg annotate -R <N-1>". (Emacs, at least, has an annotation viewing mode that has "annotate the changeset prior to the one that touched this line" a single keystroke.)<br><br></div>It seems like it should be possible to change 'hg annotate' to simply skip certain changesets. This would cause 'hg annotate" output to no longer correspond to the text of any actual revision - it would be a mix of different revisions - but if one is specifically skipping changesets that have no semantic effect (like reformatting), the mixed-revision source should be equivalent to the original.<br><br></div>Perhaps this is something we could add to Mercurial. But it doesn't seem like an adequate reason to never fix up the sources.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 9:48 AM, Dan Mosedale <span dir="ltr"><<a href="mailto:dmose@mozilla.org" target="_blank">dmose@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>* We should be able to write custom "linter" rules
              looking for common issues with Mozilla code (e.g. usage of
              nsIFile over OS.File)<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Right. So as Boris said, most of this just needs parsing and "glue"
    to process the AST and hook up to our custom processing
    scripts/specifications (for refactors/reformatting/linting).<br>
    <br>
    Do you have evidence that a significant number of the above problems
    have ready-made "glue" that will work with ES6 once we get rid of
    the SM-specific stuff? Because we already have a working parser and
    AST generator - Reflect.parse. Its output format, last I checked, is
    largely compatible with the existing toolset. The main problem was
    ES6 stuff like "let", "const", "yield", generators, for...of, and
    destructuring expressions. Ditching SM-specific things wouldn't
    bridge that gap. Maybe I've been looking at the wrong tools, though?<br></div></blockquote><div><br></div></span><div>Have a look at ESlint <<a href="http://eslint.org/docs/about/" target="_blank">http://eslint.org/docs/about/</a>>.  It's moving very fast to support ES6 stuff on an opt-in basis; <<a href="http://eslint.org/docs/configuring/" target="_blank">http://eslint.org/docs/configuring/</a>> has details.  It already has a very large chunk of the es6 features we use; see <<a href="http://eslint.org/docs/configuring/" target="_blank">http://eslint.org/docs/configuring/</a>>.  It's also designed to be pluggable so that we can add rules to match our own prevailing style usages.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Dan</div></font></span></div></div></div>
<br>_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div>