3 ms·
One of the practical issues here is, if your code fails to compile in CI with an error like /home/ci/src/foo.c:123:45: error: use of undeclared identifier
by geofft 5y ago
One of the practical issues here is, if your code fails to compile in CI with an error like
/home/ci/src/foo.c:123:45: error: use of undeclared identifier 'a'
or
/home/ci/src/bar.py:50: syntax error in type comment
or crashes in production with an error like
java.lang.NullPointerException
at com.example.Baz.doThings(Baz.java:1337)
you really want to be able to find line 123 column 45, line 50, or line 1337 in your editor, and have that be the same line as what your CI compiled and deployed.
On its own, tabs vs. spaces only affects columns, and you can probably figure things out without columns (although it's a shame to lose it). But different tab sizes affect how long your lines are, and line wrapping is a thing that people care about at least as much as tabs vs. spaces (people with different size monitor or fonts will easily see too-long or too-short lines on their display; if your spaces are equivalent to the tab stop, the distinction is literally invisible). And once you start rewrapping lines, everyone's line numbers are different.
I think it's possible to solve this by using some sort of AST-based index into the file and teaching IDEs to let you seek based on that, but it's suddenly a more complex problem.
- ratww 5y agoThis is already a very common problem with a solution: transpiled JS already needs source maps to display errors correctly.
- geofft 5y agoNo, I don't think that's the same problem / the same solution. A source map translates between a layout checked into the code and a format generated at build time. I'm talking about translating between a layout in a developer's local workspace and the layout checked into the code. Since the developer can choose whatever formatting options they want, there isn't a single source map that can be referenced in the compiled version of the code, so backtraces etc. So the transformation cannot be done at the point the error is displayed (compiler output or backtrace output), it has to be done in the context of the developer's local workspace. I think source maps could probably be inspiration for solving this problem, but I don't think they would work directly - and even if they did, the real problem here is not designing a solution, it's getting everyone's IDEs to work properly with it. Source maps work largely because the major browsers know how to deal with source maps in JS. You'd have to extend this to all the other ecosystems, at the very least.
- ratww 5y agoNo, it's literally the same thing. We don't ship source maps on production apps. This is for JS apps but also similar with executables and debug files. All the logging is done trough some service like Sentry, but exactly where the error happened is opaque in the client-side. Sentry is responsible for doing the sourcemap translation. The only difference is that with "personalized" formatting, the source mapping would be done based on the user that is logged to Sentry. That's it. Of course there are other workflows such as support getting errors displayed directly to customers via copy-paste, or reading server logs to look for those errors, but for apps where you have a logging solution you don't need to rely on those.