18 ms·

After 7.5 years, Firefox finally adds line numbers to view-source:

207 points by ecaron 15y ago

moheeb 15y ago
I never understood this. I believe even Visual Studio defaults to having the line numbers off. 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?
- TheEzEzz 15y ago
  I don't use line numbers in VS, because clicking on an error message takes me directly to the line I care about.
- sur 15y ago
  In Firefox, viewing the source from the error console highlights the line that the error was on.
- zobzu 15y ago
  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.
mmahemoff 15y ago
That's quite a while, but actually I think it represents a trend we're seeing in HTML5/webdev, which is increased attention to developer experience. 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://webintents.org, http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i...]
wavephorm 15y ago
Just in time for the removal of the "View Source" menu item.
- kinetik 15y ago
  It was moved to the "Web Developer" menu, not removed entirely.
  - kijin 15y ago
    I haven't even noticed the move. It's always been Ctrl+U for me.
millzlane 15y ago
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.
DiabloD3 15y ago
The line to shout FINALLY! at the top of their lungs starts here.
- j45 15y ago
  Haha, I just about wrote the same thing but scrolled down. Having line numbers will be a nice addition when I'm not using Firebug as a simpler way to quickly find something.
  - j45 15y ago
    Just trying to learn about HN. Commenting why having page numbers will help me is a down votable offence?
    - itsameta4 15y ago
      >Haha, I just about wrote the same thing but scrolled down. HN response: "Oh, good, another redditor. This is a place for discussion, not conversation. Downvote." >Having line numbers will be a nice addition when I'm not using Firebug as a simpler way to quickly find something. HN response: "No shit?"
gcb 15y ago
and 7.5 years I still think it's not that useful anyway. 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.
FuzzyDunlop 15y ago
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.
- ecaron 15y ago
  I was waiting for that feature for Eclipse too. But I switched to Sublime Text (http://www.sublimetext.com/2 http://www.sublimetext.com/2) and shudder when I think how many hours I wasted waiting for Eclipse to keep up with me.
  - baby 15y ago
    Sublime Text 2 is amazing! I'm using it now. 3 big shortcomings though: * no color picker (I come from dreamweaver) * no auto-completion of php functions * the folders/project bar on the left is getting messy really quick (I think the dreamweaver project bar is pretty clear compared to ST2).
    - zem 15y ago
      a colour picker is likely something the developers would simply never think to add in a product that is not specifically a web-development tool. you should write and suggest it.
thought_alarm 15y ago
The wheels of progress turn slowly, to paraphrase someone talking about mozilla.org in 1999.
scotty79 15y ago
Great. Maybe soon disable-output-encoding if Firefox XSLT processing will get implemented. https://bugzilla.mozilla.org/show_bug.cgi?id=98168 https://bugzilla.mozilla.org/show_bug.cgi?id=98168
- zobzu 15y ago
  I think such ones are usually fixed if you make a public fuss about it. Sad but true.
- bzbarsky 15y ago
  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 15y ago
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.
- moonchrome 15y ago
  >This is how Free Software projects work 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.
stfp 15y ago
And no other feature was implemented in that timespan! Outragealicious!
markokocic 15y ago
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.
tzury 15y ago
Seems like some of Blake Ross' code was not touched since his departure many years ago. 1.11 * Blake Ross <BlakeR1234@aol.com> 1.12 + * Geoff Lankow <geoff@darktrojan.net>

207 points by ecaron 15y ago

I never understood this. I believe even Visual Studio defaults to having the line numbers off. 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?

TheEzEzz 15y ago
I don't use line numbers in VS, because clicking on an error message takes me directly to the line I care about.
sur 15y ago
In Firefox, viewing the source from the error console highlights the line that the error was on.
zobzu 15y ago
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.

mmahemoff 15y ago

That's quite a while, but actually I think it represents a trend we're seeing in HTML5/webdev, which is increased attention to developer experience. 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://webintents.org, http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i...]

wavephorm 15y ago

Just in time for the removal of the "View Source" menu item.

kinetik 15y ago
It was moved to the "Web Developer" menu, not removed entirely.
- kijin 15y ago
  I haven't even noticed the move. It's always been Ctrl+U for me.

millzlane 15y ago

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.

DiabloD3 15y ago

The line to shout FINALLY! at the top of their lungs starts here.

j45 15y ago
Haha, I just about wrote the same thing but scrolled down. Having line numbers will be a nice addition when I'm not using Firebug as a simpler way to quickly find something.
- j45 15y ago
  Just trying to learn about HN. Commenting why having page numbers will help me is a down votable offence?
  - itsameta4 15y ago
    >Haha, I just about wrote the same thing but scrolled down. HN response: "Oh, good, another redditor. This is a place for discussion, not conversation. Downvote." >Having line numbers will be a nice addition when I'm not using Firebug as a simpler way to quickly find something. HN response: "No shit?"

gcb 15y ago

and 7.5 years I still think it's not that useful anyway. 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.

FuzzyDunlop 15y ago

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.

ecaron 15y ago
I was waiting for that feature for Eclipse too. But I switched to Sublime Text (http://www.sublimetext.com/2 http://www.sublimetext.com/2) and shudder when I think how many hours I wasted waiting for Eclipse to keep up with me.
- baby 15y ago
  Sublime Text 2 is amazing! I'm using it now. 3 big shortcomings though: * no color picker (I come from dreamweaver) * no auto-completion of php functions * the folders/project bar on the left is getting messy really quick (I think the dreamweaver project bar is pretty clear compared to ST2).
  - zem 15y ago
    a colour picker is likely something the developers would simply never think to add in a product that is not specifically a web-development tool. you should write and suggest it.

thought_alarm 15y ago

The wheels of progress turn slowly, to paraphrase someone talking about mozilla.org in 1999.

scotty79 15y ago

Great. Maybe soon disable-output-encoding if Firefox XSLT processing will get implemented. https://bugzilla.mozilla.org/show_bug.cgi?id=98168 https://bugzilla.mozilla.org/show_bug.cgi?id=98168

zobzu 15y ago
I think such ones are usually fixed if you make a public fuss about it. Sad but true.
bzbarsky 15y ago
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 15y ago

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.

moonchrome 15y ago
>This is how Free Software projects work 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.

stfp 15y ago

And no other feature was implemented in that timespan! Outragealicious!

markokocic 15y ago

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.

tzury 15y ago

Seems like some of Blake Ross' code was not touched since his departure many years ago. 1.11 * Blake Ross <BlakeR1234@aol.com> 1.12 + * Geoff Lankow <geoff@darktrojan.net>