Well, nobody sent them a patch until two months ago, nobody added tests until a month ago, and nobody fixed the broken tests until yesterday. So the title should be more like, "Firefox adds line numbers to view-source the day after someone implemented them correctly."
This is how Free Software projects work; people that want a feature implement it. It's great that you want something and it's possible that your desires will line up with those of someone who can easily implement them ("oh yeah, great idea, i want line numbers too"), but more often than not, the people with experience on some project are more interested in some deeper problem. If you're hacking on the JS JIT, line numbers just aren't important to you; you never "view source" in the browsers and may not even run the browser all that often. It's likely that your "extracurricular hacking" will be on something like a better test harness or better Emacs integration with your development workflow.
It is hard to go from being a user of software to a developer of that software, especially in this day and age of easily-downloadable TV shows, movies, and /b/ memes. That's why it takes 7.5 years to find someone interested in hacking on this feature, them getting themselves up to speed on Mozilla, and then finally implementing an acceptable patch. It would be nice if someone got paid to work on this sort of stuff, but users are comparing Firefox to its competition with things like Javascript benchmarks and WebGL conformance, not whether the browser has line numbers in view source. That's not to say they're not important, but rather very easy to deprioritize when the people that know how to implement that quickly also know how to implement "bigger wins" more quickly.
Ultimately, a free software project lacks feature X because you haven't added it yet. Remember that when you submit complainy titles to HN. Don't rely on someone else to make your life better because you're going to be pretty disappointed when you realize that you don't matter much to the world at large. Everyone else has other things to do too.
Please provide a criticism of open source software which you can't answer with "If you don't like it, fix it."[1] I wager you can't. If that's true, you're basically claiming that open source projects are immune to criticism[2].
[1] It's really, "If you don't like it, learn programming, then download the source code, then learn to build it, then learn to read it, then make your change, then build it, then use it, then champion getting it merged."
[2] Complaint, whine, we can call it whatever you want. I'm a grown man secure in my whining.
---
Do you really go hack on random large codebases at a moment's notice when something about them irks you? If so, please know that nobody else on the planet can do this without spending weeks of time (conservatively). It's utterly disingenuous to so ignore the fixed costs inherent in programming.
---
Is this the same firefox that can afford to advertise in the NYTimes? How much of its development is really on a volunteer basis anymore? Let's decide once and for all whether this is a mature codebase that's encouraging us to use it for mission-critical work in the world. If it is, it's open to criticism (yes, even trivial criticism).
Depends on which Firefox you are talking about. If you're talking about "the community of people and organizations that develop the browser called Firefox," then your post is correct.
On the other hand, if you are looking at Firefox from the perspective of a consumer deciding between browsers, then the complaint is valid, assuming line numbers are important to you. They are kind of basic, and the product has gone long without having them.
> Ultimately, a free software project lacks feature X because you haven't added it yet.
This is also true of proprietary projects. I can edit the machine code or clone it. This fact doesn't invalidate observations of behind-the-times features in proprietary projects. In OSS, the barrier to entry is lower, but still substantial. Likewise, it's reasonable for us, as consumers, to observe when OSS projects don't implement things we want. I don't hold them to different standards merely because I have been invited to spend my valuable hours working on them.
I think your point is that if you want a feature implemented in an OS project, you should implement it yourself. In practice, we're web developers, and it's much easier to just pick up google chrome than it is to get set up with developing firefox, getting into the code and implementing the change.
That being said, I'm seriously considering cowboying up and contributing to get the ruby tag implemented in firefox. This is not because I use Firefox myself, but my users do, and faking it with js/css is brittle as hell.
Isn't Mozilla a non-profit org with a hefty budget ? I guess it isn't unreasonable to expect improvements from the core team. Sure you can't demand them but I guess once you have a paid team working on the project you expect some polish, especially when it coincides with their goals of helping/enabling developers.
It sounds like you're saying that the entity called "Firefox" shouldn't be blamed for aissing feature, because it's up to people to write the code. That's a strange definition of what "Firefox" is. I think Firefox is its community of developers, both those that work on the product full time and those that volunteer. A lack of such an obvious feature is in my eyes a problem with "Firefox."
I'd argue that was the opposite how Firefox project worked when Blake Ross was still guiding it. Clear vision and direction, not passive wait for someone to submit something.
Without this any project just becomes a mess of patches.
By this logic, it is impossible to evaluate any open source project, because all that ends up being evaluated is the reviewer's personal failure to implement whatever qualities they were looking for.
Next on the long-awaited feature list: word wrap in Eclipse.
I can't say I even noticed line numbers on the page source in Chrome either. The formatting of source on a rendered page can be a bit messed up when the request is served, with tabbing and whitespace ended up all over the place, especially with loops. Then there's minified source if you're using someone else's code.
Most of the time it's easier to note the error, try and identify where it occurred, then find it in your editor. And with things like Chrome's developer console, sometimes using view-source is redundant when you have a DOM inspector and a number of ways to traverse it.
And even then, with a good linter you can avoid making basic mistakes like typos or missing parentheses or whatever, and in some cases even have undeclared variables or functions highlighted (Sublime Text 2 has one that in some places can appear quite fascist in how strict it enforces its policies, particularly with Python). At that point, usage of the browser for debugging code is most useful for capturing errors you couldn't reproduce elsewhere, and errors that only appear in minified code.
Not that I'm saying the browser tools aren't a great productivity boost. Because they obviously are. Just that I rarely find myself using the view source feature, really.
I was waiting for that feature for Eclipse too. But I switched to Sublime Text (http://www.sublimetext.com/2) and shudder when I think how many hours I wasted waiting for Eclipse to keep up with me.
They've always shown up in the status bar if you put the cursor on a line. You can also press Ctrl+L to goto a specific line number. Just in case someone didn't know.
Because you can just "go to line" and the current line is also displayed already.
having the line numbers in a side column is redundant, so its far from critical (that's why the bug didnt get fixed).
Personally i also prefer to have the line number in the status bar, because side bar adds visual clutter and isn't really useful.
It's the same with VIM btw. Default setup doesn't have line numbers but you see them in the status bar. Some people like to have line numbers on the side tho.
The title is a bit misleading. It's not that they were trying to add them for 7.5 years, but weren't able to do it, as the title suggests. It's just that hey didn't have intention of adding line numbers, but changed their minds recently.
Given that it requires a complete rewrite of how XSLT works in Firefox, that the rewrite would make the XSLT much slower, and that the use cases for XSLT on the web that actually want this feature are few and far between, the chances of this happening are low.
[+] [-] jrockway|14 years ago|reply
This is how Free Software projects work; people that want a feature implement it. It's great that you want something and it's possible that your desires will line up with those of someone who can easily implement them ("oh yeah, great idea, i want line numbers too"), but more often than not, the people with experience on some project are more interested in some deeper problem. If you're hacking on the JS JIT, line numbers just aren't important to you; you never "view source" in the browsers and may not even run the browser all that often. It's likely that your "extracurricular hacking" will be on something like a better test harness or better Emacs integration with your development workflow.
It is hard to go from being a user of software to a developer of that software, especially in this day and age of easily-downloadable TV shows, movies, and /b/ memes. That's why it takes 7.5 years to find someone interested in hacking on this feature, them getting themselves up to speed on Mozilla, and then finally implementing an acceptable patch. It would be nice if someone got paid to work on this sort of stuff, but users are comparing Firefox to its competition with things like Javascript benchmarks and WebGL conformance, not whether the browser has line numbers in view source. That's not to say they're not important, but rather very easy to deprioritize when the people that know how to implement that quickly also know how to implement "bigger wins" more quickly.
Ultimately, a free software project lacks feature X because you haven't added it yet. Remember that when you submit complainy titles to HN. Don't rely on someone else to make your life better because you're going to be pretty disappointed when you realize that you don't matter much to the world at large. Everyone else has other things to do too.
[+] [-] akkartik|14 years ago|reply
[1] It's really, "If you don't like it, learn programming, then download the source code, then learn to build it, then learn to read it, then make your change, then build it, then use it, then champion getting it merged."
[2] Complaint, whine, we can call it whatever you want. I'm a grown man secure in my whining.
---
Do you really go hack on random large codebases at a moment's notice when something about them irks you? If so, please know that nobody else on the planet can do this without spending weeks of time (conservatively). It's utterly disingenuous to so ignore the fixed costs inherent in programming.
---
Is this the same firefox that can afford to advertise in the NYTimes? How much of its development is really on a volunteer basis anymore? Let's decide once and for all whether this is a mature codebase that's encouraging us to use it for mission-critical work in the world. If it is, it's open to criticism (yes, even trivial criticism).
[+] [-] jamesaguilar|14 years ago|reply
On the other hand, if you are looking at Firefox from the perspective of a consumer deciding between browsers, then the complaint is valid, assuming line numbers are important to you. They are kind of basic, and the product has gone long without having them.
> Ultimately, a free software project lacks feature X because you haven't added it yet.
This is also true of proprietary projects. I can edit the machine code or clone it. This fact doesn't invalidate observations of behind-the-times features in proprietary projects. In OSS, the barrier to entry is lower, but still substantial. Likewise, it's reasonable for us, as consumers, to observe when OSS projects don't implement things we want. I don't hold them to different standards merely because I have been invited to spend my valuable hours working on them.
[+] [-] alinajaf|14 years ago|reply
That being said, I'm seriously considering cowboying up and contributing to get the ruby tag implemented in firefox. This is not because I use Firefox myself, but my users do, and faking it with js/css is brittle as hell.
[+] [-] moonchrome|14 years ago|reply
Isn't Mozilla a non-profit org with a hefty budget ? I guess it isn't unreasonable to expect improvements from the core team. Sure you can't demand them but I guess once you have a paid team working on the project you expect some polish, especially when it coincides with their goals of helping/enabling developers.
[+] [-] baddox|14 years ago|reply
[+] [-] rimantas|14 years ago|reply
[+] [-] saturn|14 years ago|reply
[+] [-] mmahemoff|14 years ago|reply
While fancy components and CSS eye candy will continue to roll out, we're seeing even more work on development/debugging tools, the JavaScript language, and with web intents and web components, the seeds of a more robust reuse model. [http://webintents.org, http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i...]
[+] [-] FuzzyDunlop|14 years ago|reply
I can't say I even noticed line numbers on the page source in Chrome either. The formatting of source on a rendered page can be a bit messed up when the request is served, with tabbing and whitespace ended up all over the place, especially with loops. Then there's minified source if you're using someone else's code.
Most of the time it's easier to note the error, try and identify where it occurred, then find it in your editor. And with things like Chrome's developer console, sometimes using view-source is redundant when you have a DOM inspector and a number of ways to traverse it.
And even then, with a good linter you can avoid making basic mistakes like typos or missing parentheses or whatever, and in some cases even have undeclared variables or functions highlighted (Sublime Text 2 has one that in some places can appear quite fascist in how strict it enforces its policies, particularly with Python). At that point, usage of the browser for debugging code is most useful for capturing errors you couldn't reproduce elsewhere, and errors that only appear in minified code.
Not that I'm saying the browser tools aren't a great productivity boost. Because they obviously are. Just that I rarely find myself using the view source feature, really.
[+] [-] ecaron|14 years ago|reply
[+] [-] millzlane|14 years ago|reply
[+] [-] moheeb|14 years ago|reply
So even though errors are reported as to which line number they are on the line number is not displayed on screen by default!?
Is there reasoning behind this?
[+] [-] zobzu|14 years ago|reply
Personally i also prefer to have the line number in the status bar, because side bar adds visual clutter and isn't really useful.
It's the same with VIM btw. Default setup doesn't have line numbers but you see them in the status bar. Some people like to have line numbers on the side tho.
[+] [-] TheEzEzz|14 years ago|reply
[+] [-] sur|14 years ago|reply
[+] [-] markokocic|14 years ago|reply
[+] [-] thought_alarm|14 years ago|reply
[+] [-] tzury|14 years ago|reply
[+] [-] scotty79|14 years ago|reply
https://bugzilla.mozilla.org/show_bug.cgi?id=98168
[+] [-] bzbarsky|14 years ago|reply
[+] [-] zobzu|14 years ago|reply
[+] [-] stfp|14 years ago|reply
[+] [-] wavephorm|14 years ago|reply
[+] [-] kinetik|14 years ago|reply
[+] [-] gcb|14 years ago|reply
you could always go to a specific line (edit>go to line, or Ctrl+L), which is over 9000% more useful from anyway you look at it.
you also could have seem the line number on the statusbar.
[+] [-] DiabloD3|14 years ago|reply
[+] [-] j45|14 years ago|reply
Having line numbers will be a nice addition when I'm not using Firebug as a simpler way to quickly find something.