I am in the distinctly unfortunate circumstance of working in an environment which worries little of the deep evil known as "trailing whitespace"... But, alas, the enlightened Mercurial persists in warning me, by means of red highlights in diffs, that code I will be checking in contains this unholy thing.
So, is there any way to tell Mercurial to ignore trailing whitespace in diffs?
I've tried all the obvious --ignore-* commands, and they seem to do nothing.
Thanks!
Put in your hgrc file:
[color]
diff.trailingwhitespace = none
Read more about customizing color schemes on the ColorExtension wiki page
https://www.mercurial-scm.org/bts/issue127 tracks the fact that the -w option does not work as you might expect.
Related
I am using
METEOR#1.4.4.2
WebStorm#2017.1.1
Chrome#58.0.3029.110 (64-bit)
macOS Sierra 10.12.5
ecmascript#0.7.3
ecmascript-runtime#0.3.15
Recently, the debugger started to stop at wrong lines but only visually, mostly it is like 8-14 lines behind the actual breakpoint.
e.g.
*the orange bar indicates the breakpoint in google chrome
console output:
Also, as you can see, some lines are darkened, which means that I can not set a breakpoint there from the browser.
The behavior is the same within the WebStorm internal debugger. So I think it is not Chrome's fault. It looks like the source mapping is broken. I do not know if it is WebStorm, or Meteor that is the cause. Under this conditions it is very hard to debug...
It is difficult to say for sure, but it seems that the issue that you are experiencing is related to a bug that causes Meteor to generate incorrect source maps.
source maps
This is not your browser's "fault". It simply displays the code and the position that is delivered to it by the source maps in your project.
The app.js file and the source map (app.js.map) are generated by the Meteor build process and are served from the .meteor/local/build/programs/web.browser/app directory.
The .map file is responsible of telling the browser how to display the original source, and which segments in the generated app.js file are mapped to which segments in the original source code.
A great explanation about the technical aspects of source maps can be found here.
You can visualize your source maps online and see what maps where using this tool (choose custom... and drag/drop both .js and .map files.
the suspected bug
As a part of the build process, Meteor uses the babel-compiler Meteor package. At some point, a bug caused invalid maps to be produced after babel transformations.
The bug is currently tracked on GitHub and the Meteor folks seem to be closing in on the cause.
what can you do?
At the moment, there is no quick and easy fix.
You can either:
Watch the bug thread and wait for it to be resolved and debug without source maps for now (probably best, if the bug will be fixed soon).
Hack away with local clones of the relevant Meteor packages (could work, I haven't dug into the dependency issues and don't really recommend it, but here's a way of doing it).
Run Meteor from a git checkout in a known good state until a fix is released.
The last option is what #hwilson did in order to begin pinpointing the bug via a git bisect.
You can refer to the Meteor developer document for detailed information regarding the method of running the meteor tool from checkout, but the gist of the things is as follows:
First, make sure that your code, including the .meteor/versions and .meteor/packages are checked out into source control, as you will likely need to mess them up temporarily and will want to restore them once the bug is fixed.
git clone --recursive https://github.com/meteor/meteor.git to a directory of your choosing (e.g, /home/yourname/src/remote.
cd meteor.
git checkout 25a89b5 to get the last known good commit.
git submodule update --init --recursive to make sure everything is still golden after the checkout.
./meteor --help to have the checked out version start
In your project, remove the version info from the .meteor/packages file, as they will likely be incompatible with the ones offered by your checkout.
In your project dir, run /home/yourname/src/remote/meteor/meteor run.
This will run the checked out Meteor version. You may need to do a meteor reset (warning: this clears the local mongo database) or at least clean some of .meteor/local, (e.g, the source maps) for this to work, but this may be unnecessary.
This is quite a lot of effort for a bug which I assume will be resolved in the near future, but I decided to include this info partly in order to be used as documentation for future sourcemap-related issues.
It's hard to say for certain. On a cursory google search it would appear you're not the only one seeing this. As #MasterAM mentioned, it's probably because of source maps from transpilation. I don't think you can do a whole lot about it, but you can try clearing the browser and IDE caches which appears to have worked for some.
Javascript Stops at a line without a breakpoint in remote debug mode
Clearing Webstorm's cache
It is three years too late, but if somebody steel has this problem.
The problem is in the different interpretation of line separators by IDE and compiler, which generates .map files.
For example on the windows in the WebStorm and Angular-Project - the TypeScript compiler ignores line separators, if they are Unix-Style (only LF).
In this case if code formatter transforms too long line to couple of shorter lines and splits these lines by only LF, then in .map file this originally single line will be interpreted as single line, but WebStorm displays by LF separated lines as different lines.
Solution - change line separator to CR+LF and problem will be solved!
P.S. I thin this is a bug in TypeScript compiler
Not sure about this scenario but have faced a similar situation while debugging java with eclipse. It happens when the source code and the compiled/interpreted code that is being debugged - differ.
Try debugging a simple js code to validate if there is something wrong with chrome's js debugger itself. If it works, then an explanation for the lines of code not 'debug-enabled' would be that they are all on the same line (till statement that logs '7'). This could have also offset the line number in the browser.
This is one possible explanation.
I will add that sometimes the Pretty-print of the minified js file add offset in debugging mode between the real line in your code and the shifted line(do to Pretty-print).
So Avoid Pretty-print in mode debug and you will hang to the right line.
Each time I need anything beyond the standard search, I find myself trying several things, searching Google and in the end terribly failing. Apparently, the Hg search syntax is pretty extensive and I would like to use its power, but I don't seem to be able to find a good reference.
For instance, quite often I want to find all changes in the repository related to a partial path match. I know that the following works:
file('path:full/path/file.txt')
But I would like to search for files by partial match, and neither of the following worked:
jquery -- seems to find everything
file(jquery*) -- finds nothing
file('jquery*') -- finds nothing
file('path:jquery.*') -- finds nothing
file('name:jquery.*') -- finds nothing
file('path:jquery.js') -- finds every revision, it seems
From the popup in TortoiseHg I see that there are a gazillion options, but no hint on how to use them (the help link shows a little bit more, but nothing on what a pattern should look like in file(pattern)):
In the end I usually find what I want using other ways of searching, but it would be so nice to be able to use this power of expression, and it's quite a shame that after so many years, I've never found out how to leverage this.
I can very much advise using the hg help system for this. The most useful pages to look at (in my view):
hg help revsets
hg help filesets
hg help patterns
In the page about patterns, you can find about 'path:':
To use a plain path name without any pattern matching, start it with
"path:". These path names must completely match starting at the current
repository root.
In other words: using 'path:' is not suitable for this purpose. Slightly below, 'glob:' is mentioned:
To use an extended glob, start a name with "glob:". Globs are rooted at
the current directory; a glob such as "*.c" will only match files in the
current directory ending with ".c".
The supported glob syntax extensions are "**" to match any string across
path separators and "{a,b}" to mean "a or b".
In other words, it should be possible to use the pattern file('glob:**jquery*').
In fact, the above pattern would also work without the glob prefix, so: file('**jquery*'). See part of the page about revsets:
"file(pattern)"
Changesets affecting files matched by pattern.
For a faster but less accurate result, consider using "filelog()"
instead.
This predicate uses "glob:" as the default kind of pattern.
Why is changing lines in configuration file considered an anti-pattern in Chef or Puppet?
It's something like bad habit, as I understood. I assume that this file-editing is done in some idempotent way and with advanced tools (augeas for example).
Why is deploying the whole files, with ERB templates, considered a preferred method?
You can find a lot of examples where dev-ops are suggesting usage of templates instead of file-editing. For example here, here, here, etc.
Actually there is a large part of the DevOps community that sees accepting system/package defaults for config files and only modifying what you need through augeas as the preferred method, Github devops would be one of them(if you happened to catch them at Puppet Conf 2012).
I think having a default pattern of always using templates creates too high of a maintenance load and almost always requires you lock in specific versions for everything across your stack or you risk having an incompatible template against a newer version of that resource.
There's use cases for both options but in general I favor the "own as little as possible" practice vs the "own everything even if you don't have to" practice.
In terms of setting the your system to a known state, deploying whole files is better than editing, because you are sure the file is exactly as intended when you are done.
If you are tinkering around finding potential solutions to a problem and hand edit some configuration file, you don't have to worry about the hand edit you made staying around as an uncontrolled part of your environment. The next time you run chef-client, you know that the state will be exactly as specified in the Chef recipe, and won't include your edit.
Also, it is just in general harder and more complicated to robustly edit a file than it is to just generate one. You might write something that is idempotent in the basic case, but if the file contains a syntax error or something invalid, than your editing no longer works.
As always though, sometimes you don't have a choice, and editing is the only way to go.
Suppose, I have the following pattern in a comment in my code - $REV$. I would like to have a client side hook, which would replace it with something like $REV[$ d3d004be40c5 $]REV$. Any subsequent commits would assume that there is a revision between $REV[$ and $]REV$ and replace it accordingly.
I want to use a client side hook, because I do not want an extra commit for this mangling, hence it must be done on the client as part of the commit.
I reckon a precommit hook in python should be apt for the job, but I've just thought to seek for an advice before delving into it. Maybe there is a better way to do it like using an existing extension, for instance. If anyone has done anything similar - please share.
Thanks.
P.S.
I know this may seem strange to embed the revision within the source code, but please indulge me.
keyword extension does what you want (though usefulness of this is really, really low).
Are there any microscopic reasons at all (beyond superstition), to add an extra return after </html> in (X)HTML documents?
Is there any significant reason at all, not to stop this habit of mine? (To me, it looks a lot cleaner with the last line number being the same as the last bit of code, but I'm curious to know if there are any known consequences/possible effects between keeping or not keeping the extra return, such as the last line not being interpreted or something like that.)
It's just superstition. If I remember correctly, one of the earlier IE versions (2 or 3) would throw an error if you didn't have an extra line break there, but I think that hasn't mattered for quite some time.
One reason is because some lazily-programmed parsers are programmed to read a line at a time using linefeed or carriage-return-line-feed, and if the data stream just ends then it either won't parse the last line or it will just fail. I have experienced some C compilers and some versions of Make will complain if the last line doesn't contain a linefeed. Obviously these are not HTML, but the reason holds.
I always add an extra linefeed out of habit for this reason.
Are you using a VCS? Historically, some version control systems moan about a missing line end at end-of-file; I believe this may be due to diff and patch being (originally) a bit fussy about this.
Not exactly superstition; perhaps we could classify it as an obsolete urban legend (plenty of those in this business).
I always end my files with a linefeed.
At one time I had a automatic tool that would concatenate all JavaScript files in a directory into a single file (to save HTTP requests). This would break if a file didn't end in a newline and also didn't end with a semicolon.
Ever since then I've ended files with a newline.
Also, if you use a command line shell like bash, and you cat a file; The new prompt will appear after the last character in the file, so it looks a lot better if that's a newline.
It makes no difference
Nope, like Patrick says it doesn't matter. The entire page can be on one line if you want.
One thing's for sure, no modern well-known browser is going to care. Indeed in HTML, as opposed to XHTML, the </html> tag is superfluous too.
However, in your first sentence you ask for microscopic reasons and I have one. Some editors (I think notepad used to be one, I haven't checked lately) will automatically add a CR/LF to the last line of a file on save if the line is not empty, probably to fix problems such as the ones DevelopersDevelopersDevelopers describes. This used to be a real irritation when editing DOS batch files as an extra line could adversely affect the way the script terminated.
As a result, if you create your HTML in one editor which doesn't do this, and you don't manually add the final CR/LF, then later someone opens the file in a editor which does, doesn't change anything and saves, you get an erroneous difference that can show up in when searching for real changes or in version control logs.
In your second sentence, you ask for significant reasons. This is not, IMO, a significant reason, and I certainly would bother about such an edge case.
I don't think there is any good reason. Maybe without the return less data is transmitted so you can save traffic. But I don't think this matters at all ;-)