

After 7.5 years, Firefox finally adds line numbers to view-source: - ecaron
https://bugzilla.mozilla.org/show_bug.cgi?id=246620

======
jrockway
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.

~~~
alinajaf
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.

~~~
zobzu
You can do so, however, note that you still need acceptance for mainline.

Obvious things such as line numbers, are obviously accepted once implemented
properly.

Note: the below comment is actually inaccurate, I though ruby tag was the
language (as the author mentioned js as alternative). Keeping it for the
comments discussing it, but keep in mind I was actually wrong.

Things like a ruby tag might be more complicated than you'd think.

You see, the main difference between Firefox and Chrome (yeah, it's not the
UI! ;P) is ideology.

Firefox folks believe in a standard and compatible web. Chrome folks believe
in .. implement whatever we think is faster than what we have (or /flamebait
hat on, whatever helps Google make money/adverts/lock-in users).

Supporting ruby might fall in the "but it's not standard" "it splits the web"
category.

And that's be correct, in my opinion. So you might want to check on that
before actually getting the code done, unless you plan to fork.

~~~
jrockway
_Chrome folks believe in .. implement whatever helps Google make
money/adverts/lock-in users._

Citation needed.

~~~
cytzol
While I can't provide a citation, I believe that the contrapositive is true:
_if it doesn't help Google, it's not going to be implemented_. Right now,
Google's interests are aligned with a standardised, compatible web, and when
Google gets big enough, or greedy enough, it's going to take Chrome in its own
direction. Opera still fares badly at Google's services, but they consider IE
worth supporting.

~~~
jrockway
I see. So you're blaming Google now for something you imagine they might do in
the future. How could Google defend itself against your accusations?

~~~
cytzol
Not blaming, but worrying about. There is plenty of software that can read
Word's .doc files. Yet I store my data as plain text, as I imagine that the
software will be killed or end-of-lifed in the future, even though I can use
it fine right now. In the same way, I'd rather use a browser designed for an
open, standardised Web.

Chrome doesn't have nearly enough market dominance for me to make accusations
about it; I just want to minimise any future disaster scenarios.

------
mmahemoff
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://dvcs.w3.org/hg/webcomponents/raw-
file/tip/explainer/i...](http://dvcs.w3.org/hg/webcomponents/raw-
file/tip/explainer/index.html)]

------
FuzzyDunlop
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
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.

~~~
easy_rider
I'm probably switching to Sublime, even though it doesn't autocomp. PHP.
whatever, few more lookups in the manual are probably less time-consuming and
stressful than an editor just blatantly crashing all over the place when just
simply...inputting text

~~~
ecaron
Although it'd be nice if Sublime came with autocomp out of the box (or at
least an easier way to config it), the options are there. The blog I followed
to set it up is <http://urbangiraffe.com/2011/08/15/sublime-text-2-for-php/>.
It does make ST a bit more resource intensive than the vanilla version, but it
is still loads lighter than Eclipse and also a small footprint on any modern
machine.

 _Save yourself the time and skip the Soda UI part of the blog post_

------
millzlane
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.

------
moheeb
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?

~~~
zobzu
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.

------
markokocic
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.

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

------
tzury
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>

------
scotty79
Great. Maybe soon disable-output-encoding if Firefox XSLT processing will get
implemented.

<https://bugzilla.mozilla.org/show_bug.cgi?id=98168>

~~~
bzbarsky
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.

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

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

~~~
kinetik
It was moved to the "Web Developer" menu, not removed entirely.

~~~
kijin
I haven't even noticed the move. It's always been Ctrl+U for me.

------
gcb
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.

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

~~~
j45
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
Just trying to learn about HN. Commenting why having page numbers will help me
is a down votable offence?

~~~
itsameta4
>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?"

