After 7.5 years, Firefox finally adds line numbers to view-source:(bugzilla.mozilla.org)
bugzilla.mozilla.org
After 7.5 years, Firefox finally adds line numbers to view-source:
https://bugzilla.mozilla.org/show_bug.cgi?id=246620
83 comments
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).
[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).
Not "immune to criticism", but set up in such a way that criticism always has a specific, useful outcome.
Or turning your question on its head: If it is possible to fix and you would like to see it fixed, why do you insist on criticizing?
And it's not just "here, hack our code to make it work for us", although that is of course preferred. It's already useful to have people report problems or to talk to people who work on the code on forums. It is absolutely conceivable that a lot of the people already working on Firefox simply never thought of adding line numbers to the view source (as mentioned elsewhere, you CAN see the linenumber already, just not constantly on the side) and having the suggestion come up from the community is already a valuable asset. If that's not your thing - no problem. But for some people, it is, and that's how the software grows.
As for the comment about advertising: Mozilla does collect money on Firefox (through Google, mostly, IIRC) and uses the money to advertise it. Advertisement brings more users in who may be interested in participating.
They are simply not your standard software corporation that turns money into software and software into money.
Or turning your question on its head: If it is possible to fix and you would like to see it fixed, why do you insist on criticizing?
And it's not just "here, hack our code to make it work for us", although that is of course preferred. It's already useful to have people report problems or to talk to people who work on the code on forums. It is absolutely conceivable that a lot of the people already working on Firefox simply never thought of adding line numbers to the view source (as mentioned elsewhere, you CAN see the linenumber already, just not constantly on the side) and having the suggestion come up from the community is already a valuable asset. If that's not your thing - no problem. But for some people, it is, and that's how the software grows.
As for the comment about advertising: Mozilla does collect money on Firefox (through Google, mostly, IIRC) and uses the money to advertise it. Advertisement brings more users in who may be interested in participating.
They are simply not your standard software corporation that turns money into software and software into money.
Or turning your question on its head: If it is possible to fix and you would like to see it fixed, why do you insist on criticizing?
Because the time he would spend changing it (and learning how the project codebase is structured, and setting up the environment, etc, etc.) would be orders of magnitude higher than if the same change was done by someone who actively works on the project.
Because even if he writes a patch, it might be rejected and then all his effort will be effectively wasted.
Besides, this is not a valid response anyway. If the code browser should have had line number support and didn't get it for seven years, then clearly there is some problem. Pinning that problem on the person who first spoke about it doesn't really improve anything.
Because the time he would spend changing it (and learning how the project codebase is structured, and setting up the environment, etc, etc.) would be orders of magnitude higher than if the same change was done by someone who actively works on the project.
Because even if he writes a patch, it might be rejected and then all his effort will be effectively wasted.
Besides, this is not a valid response anyway. If the code browser should have had line number support and didn't get it for seven years, then clearly there is some problem. Pinning that problem on the person who first spoke about it doesn't really improve anything.
First - maybe my reversed question wasn't entirely clear. I was asking why he so insists on his right to level as much criticism as he can at a FOSS project when there are clearly ways to get the job done.
What I said was that there already are places to bring your ideas and criticism. You say "the code browser should have had line numbers support" - well, by what right is that a necessity? If it really was such a bad idea to not have line numbers, you'd think people would be all over this for the past 7 years. They weren't, because there already is a way to figure out the line numbers. It might be a matter of taste whether their old solution did the job, but that's why I think it's a sign of how the consensus has shown that it wasn't needed.
Now the tables have turned - somebody went through the trouble to get the code done, enough people were convinced that it's a good idea and it has been accepted. So what's your beef here? The process works just fine.
Just because you or the person you are defending wouldn't go through the trouble doesn't mean that it wouldn't be taken over by other people once a critical mass is built.
It's all fine and well to bitch about hypothetical issues, but I don't see how you can do that in a topic that screams the exact opposite.
What I said was that there already are places to bring your ideas and criticism. You say "the code browser should have had line numbers support" - well, by what right is that a necessity? If it really was such a bad idea to not have line numbers, you'd think people would be all over this for the past 7 years. They weren't, because there already is a way to figure out the line numbers. It might be a matter of taste whether their old solution did the job, but that's why I think it's a sign of how the consensus has shown that it wasn't needed.
Now the tables have turned - somebody went through the trouble to get the code done, enough people were convinced that it's a good idea and it has been accepted. So what's your beef here? The process works just fine.
Just because you or the person you are defending wouldn't go through the trouble doesn't mean that it wouldn't be taken over by other people once a critical mass is built.
It's all fine and well to bitch about hypothetical issues, but I don't see how you can do that in a topic that screams the exact opposite.
Downvotes, really? Is it because I used one of the grown-up words?
[edit]And downvotes yet again. Look - This is growing into yet another HN meta-problem. I think I really did my best in having a discussion - the result is it being abandoned and me being downvoted. At least have the courtesy to give me a reason.
[edit]And downvotes yet again. Look - This is growing into yet another HN meta-problem. I think I really did my best in having a discussion - the result is it being abandoned and me being downvoted. At least have the courtesy to give me a reason.
Ok, I'll give you an opportunity to downvote me back.
You keep turning this into something more melodramatic than it really is by using words like 'insist', and like 'bitch'. That's not conducive to a discussion.
Somebody pointed out what they think is a flaw in some product. In one sentence. Your defensiveness to that sentence is just way out of proportion. It's not unsurprising nobody's responding. A downvote is the appropriate response.
Elsewhere you said:
"you don't need to act surprised.."
That is passive-aggressive. You're insinuating surprise that I can't see. And you're claiming the surprise is pretend. A lie. Who wants to respond to that?
You keep turning this into something more melodramatic than it really is by using words like 'insist', and like 'bitch'. That's not conducive to a discussion.
Somebody pointed out what they think is a flaw in some product. In one sentence. Your defensiveness to that sentence is just way out of proportion. It's not unsurprising nobody's responding. A downvote is the appropriate response.
Elsewhere you said:
"you don't need to act surprised.."
That is passive-aggressive. You're insinuating surprise that I can't see. And you're claiming the surprise is pretend. A lie. Who wants to respond to that?
I cannot downvote you because I don't have that power yet.
I guess my defensiveness stems from me being in a similar field as a FOSS developer. I have seen far too many times that people prefer to "bitch" about an issue instead of even notifying me about it. In fact, people love to "bitch" about issues that aren't even there (as an example, the classic "Firefox is slow" is almost always a matter of somebody who has used and upgraded for a long time, resulting in an application with too much baggage - of course a freshly installed application will outperform 6 years of history, cookies, passwords, extensions etc.).
I really wasn't talking about "the flaw in some product", because whether it's a flaw is subjective and also whether it's a product is subjective. They are trying to force a discussion that goes against the very nature of the subject. That is the reason why the discussion is not appreciated - they cannot have the discussion they want and so they ignore mine.
As for "don't need to act surprised" - sorry, that's really what is happening here. I see a lot of people who are bending over backwards making the case that line numbers should have been there for 7 years ("now! finally they get to it! how crazy to take so long!") and share the cognitive disconnect that they apparently have a desire to moan about the FOSS process being broken while actually being witness to a situation where it worked.
Cue them moaning about whether or not "OSS projects [are] immune to criticism merely because you can fix them, given enough time?". No, they are not. This is an example where it worked. Don't act surprised.
I guess my defensiveness stems from me being in a similar field as a FOSS developer. I have seen far too many times that people prefer to "bitch" about an issue instead of even notifying me about it. In fact, people love to "bitch" about issues that aren't even there (as an example, the classic "Firefox is slow" is almost always a matter of somebody who has used and upgraded for a long time, resulting in an application with too much baggage - of course a freshly installed application will outperform 6 years of history, cookies, passwords, extensions etc.).
I really wasn't talking about "the flaw in some product", because whether it's a flaw is subjective and also whether it's a product is subjective. They are trying to force a discussion that goes against the very nature of the subject. That is the reason why the discussion is not appreciated - they cannot have the discussion they want and so they ignore mine.
As for "don't need to act surprised" - sorry, that's really what is happening here. I see a lot of people who are bending over backwards making the case that line numbers should have been there for 7 years ("now! finally they get to it! how crazy to take so long!") and share the cognitive disconnect that they apparently have a desire to moan about the FOSS process being broken while actually being witness to a situation where it worked.
Cue them moaning about whether or not "OSS projects [are] immune to criticism merely because you can fix them, given enough time?". No, they are not. This is an example where it worked. Don't act surprised.
See why this is an unproductive discussion, and both sides just vote? (With your side happening to be less numerous in this thread, pure accident, doesn't mean anything.)
I don't think the original commenter is trying to accomplish anything. It's such a minor issue. Passing judgment isn't about wanting to effect change at all. Judgment is about deciding between say firefox and chrome. (Now this is a minor dimension, so hopefully nobody's using it as a basis for the decision.)
Let me turn the question around. If you want to accomplish something why would you use confrontational language? I'm certain you too realize that and aren't trying to convince anyone of anything. You just need to vent. So, if both sides are like this, what's the point of discussion?
The only thing to do with judgment is to take it in the chin (maybe correcting gross factual inaccuracies) and move on. Anything else sheds more heat than light. If that seems unfair, remember that I have no users in my open source projects, and would kill for someone to try it long enough to judge it. (links in profile)
I don't think the original commenter is trying to accomplish anything. It's such a minor issue. Passing judgment isn't about wanting to effect change at all. Judgment is about deciding between say firefox and chrome. (Now this is a minor dimension, so hopefully nobody's using it as a basis for the decision.)
Let me turn the question around. If you want to accomplish something why would you use confrontational language? I'm certain you too realize that and aren't trying to convince anyone of anything. You just need to vent. So, if both sides are like this, what's the point of discussion?
The only thing to do with judgment is to take it in the chin (maybe correcting gross factual inaccuracies) and move on. Anything else sheds more heat than light. If that seems unfair, remember that I have no users in my open source projects, and would kill for someone to try it long enough to judge it. (links in profile)
Yeah, I'm afraid you are right - being a FOSS guy talking to people who want their "product to just work!" is a very tiring thing. They want to pass judgment while I want to discuss the process of their judgment. I don't do it often, but this thread was just too tempting, what with it having an example of the process working as it's main subject. Of course, people still get it wrong and then insist on being right. Very hard to deal with in general.
As for your project - phew, that is miles over my head, sorry. Trust me, though, traction can also be a curse. At a certain level, you start to get people who don't criticize your software or code, they criticize you for their own inability to use it.
As for your project - phew, that is miles over my head, sorry. Trust me, though, traction can also be a curse. At a certain level, you start to get people who don't criticize your software or code, they criticize you for their own inability to use it.
"It is absolutely conceivable that a lot of the people already working on Firefox simply never thought of adding line numbers.."
The bug was opened in 2004.
The bug was opened in 2004.
"...line numbers to the view source (as mentioned elsewhere, you CAN see the linenumber already, just not constantly on the side) and having the suggestion come up from the community is already a valuable asset.".
In 2004 it was the same developer-focussed feature that it is today. I suppose it's only that today, the community is more concerned with developers and back then, people didn't mind as much. I still don't, as an n=1 example.
In 2004 it was the same developer-focussed feature that it is today. I suppose it's only that today, the community is more concerned with developers and back then, people didn't mind as much. I still don't, as an n=1 example.
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).
Yes. At least when the codebase is in a paradigm that I'm familiar with. Note: language is not important in exploring a codebase. I probably couldn't do this with, say, GHC. But, I bet I could with Clang or a js library, if I wanted.
While I might not know my way around the codebase, I can certainly use grep to find where I need to go, or just ask someone on irc. In a few hours, I can at least find where I need to be, and be hacking.
The end result might not be good enough to send in as a patch, but it'll certainly fulfill my needs.
Sure, I have some skills that others don't. But, I'm not the only one who can do this, either.
Yes. At least when the codebase is in a paradigm that I'm familiar with. Note: language is not important in exploring a codebase. I probably couldn't do this with, say, GHC. But, I bet I could with Clang or a js library, if I wanted.
While I might not know my way around the codebase, I can certainly use grep to find where I need to go, or just ask someone on irc. In a few hours, I can at least find where I need to be, and be hacking.
The end result might not be good enough to send in as a patch, but it'll certainly fulfill my needs.
Sure, I have some skills that others don't. But, I'm not the only one who can do this, either.
That's really cool. I'd love to see and learn from some of your past patches.
The biggest thing to learn isnt in the patches. It's in the process -- don't be afraid to break things, and dont let "I don't know everything about this" stop you from learning one small corner of it.
Yeah I've tried that many times (I have some experience with vim, gcc, windowmaker, but mozilla was larger than them all, last time I checked) and with some success. It's totally possible. My point is merely that it's labor-intensive. There's a cost to swapping in all that state, and to swapping it out and back in again everytime you find a bug with your hacks.
(Tangent) Lately I find I'm much more likely to hack on codebases with lots of tests. Having a single command tell me when I've broken things makes me less afraid of having to deal with subtle breakage, where my changes break some feature I just happen to not use for the next n weeks/months.
(Tangent) Lately I find I'm much more likely to hack on codebases with lots of tests. Having a single command tell me when I've broken things makes me less afraid of having to deal with subtle breakage, where my changes break some feature I just happen to not use for the next n weeks/months.
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.
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 guess I will boil my argument down to: it's not their fault it's bad, it's your fault you're using it.
This applies equally to Free Software and proprietary software. "Don't like it? Don't use it." Your complaining isn't going to make the software better.
Decide on a course of action that will resolve your complaints, and then act on it. Posting to HN, "look at those l4m3rz at Firefox not implementing my features! They suck!" does not count because the logical conclusion of this action does not lead to increased happiness (either yours, or the wider community). It's like a little kid complaining to his teacher, "Johnnie hit me!", the teacher asking Johnnie "Why'd you hit Bobby?", and Bobby saying "Because Johnnie hit me first". The end result is a couple of sore schoolkids and an irked teacher. As adults, we need not let our actions devolve this way.
So, if this issue bothers you, you need to suck it up and stop using Firefox, or suck it up and implement the damn feature that you obviously care so deeply about. If you don't care about your feature enough to implement it, why should anyone else? Why are other people different from you? Because they've implemented features before? You expect free work from people that have given you a free product, simply because they have proven themselves willing to work for you for free before? Right, that make sense.
The advantage that free software projects have over "don't like it, don't use it" is that any user can change the software and other users will be thankful for the time and effort you put in. That's what being an adult is like.
Ultimately, all free software is based on altruism; people contribute because they want to. If you don't understand the concepts altruism or community and just want to take and complain, then you're not going to get any argument about how you should take ownership of issues that concern you.
This applies equally to Free Software and proprietary software. "Don't like it? Don't use it." Your complaining isn't going to make the software better.
Decide on a course of action that will resolve your complaints, and then act on it. Posting to HN, "look at those l4m3rz at Firefox not implementing my features! They suck!" does not count because the logical conclusion of this action does not lead to increased happiness (either yours, or the wider community). It's like a little kid complaining to his teacher, "Johnnie hit me!", the teacher asking Johnnie "Why'd you hit Bobby?", and Bobby saying "Because Johnnie hit me first". The end result is a couple of sore schoolkids and an irked teacher. As adults, we need not let our actions devolve this way.
So, if this issue bothers you, you need to suck it up and stop using Firefox, or suck it up and implement the damn feature that you obviously care so deeply about. If you don't care about your feature enough to implement it, why should anyone else? Why are other people different from you? Because they've implemented features before? You expect free work from people that have given you a free product, simply because they have proven themselves willing to work for you for free before? Right, that make sense.
The advantage that free software projects have over "don't like it, don't use it" is that any user can change the software and other users will be thankful for the time and effort you put in. That's what being an adult is like.
Ultimately, all free software is based on altruism; people contribute because they want to. If you don't understand the concepts altruism or community and just want to take and complain, then you're not going to get any argument about how you should take ownership of issues that concern you.
> Your complaining isn't going to make the software better.
There are many cases where this is not true. For example, any feature request based on a bug report. It's true that a bug report is in a different forum of complaint. But unless you can point out something that makes feedback from this forum useless and bug forums not useless, I'm pretty convinced this is generally false.
> So, if this issue bothers you, you need to suck it up and stop using Firefox
You can use this same argument to forbid criticism of anything. While I don't want to accuse you of doing this directly, it strikes me that if an argument can as easily be used for something obviously nonsensical as what you're actually using it for, it might not be a very good argument.
There are many cases where this is not true. For example, any feature request based on a bug report. It's true that a bug report is in a different forum of complaint. But unless you can point out something that makes feedback from this forum useless and bug forums not useless, I'm pretty convinced this is generally false.
> So, if this issue bothers you, you need to suck it up and stop using Firefox
You can use this same argument to forbid criticism of anything. While I don't want to accuse you of doing this directly, it strikes me that if an argument can as easily be used for something obviously nonsensical as what you're actually using it for, it might not be a very good argument.
So we're going to call "whine about it until someone gives me free stuff" a good argument then?
The point is simple: Firefox gives you everything you need to decide your own destiny. If you decide on a bad one, why should Firefox be blamed?
The point is simple: Firefox gives you everything you need to decide your own destiny. If you decide on a bad one, why should Firefox be blamed?
I'm not calling anything a good argument. Just pointing out flaws in yours.
You seem to be bending over backwards to make that work, though. Playing the devils advocate is all fine and well, but you do need to know where your argument is headed.
"Just pointing out flaws" is a good thing, too, but it would help to balance that with an equal amount of discussing his argument.
I think his argument is sound even though he doesn't have a pleasant way of arguing it. But similar to the point he is making about FOSS Projects - in that they do tell people "Either you're helping, or using, or you're not helpful", you are not helpful.
If you insist on being a "consumer" of a FOSS project, you insist on being something that they have no use for. That's your decision. You cannot argue that that is their problem.
"Just pointing out flaws" is a good thing, too, but it would help to balance that with an equal amount of discussing his argument.
I think his argument is sound even though he doesn't have a pleasant way of arguing it. But similar to the point he is making about FOSS Projects - in that they do tell people "Either you're helping, or using, or you're not helpful", you are not helpful.
If you insist on being a "consumer" of a FOSS project, you insist on being something that they have no use for. That's your decision. You cannot argue that that is their problem.
I disagree. Someone else boiled it down better: are OSS projects immune to criticism merely because you can fix them, given enough time? No. Doesn't matter whether you can argue it pleasantly or not.
Yes, I think I replied to that branch of the comments as well.
And again: No, they are not immune to criticism, they have just set up a way in which criticism is handled in a particular manner, ie. channeled into discussions or in hands-on fixing. If you don't use either, you don't need to act surprised that they don't appreciate your criticism.
And again: No, they are not immune to criticism, they have just set up a way in which criticism is handled in a particular manner, ie. channeled into discussions or in hands-on fixing. If you don't use either, you don't need to act surprised that they don't appreciate your criticism.
[deleted]
Are you saying criticism of firefox must be restricted to bug reports and mailing lists?
No, but I'm saying that if you care about your criticism actually accomplishing anything, those are certainly the best addresses to ring a bell.
Don't really see how you came to this conclusion. The very bug that's linked in this story was filed in the proper forum more than half a decade ago (i.e. it's a counter-evidence to your assertion).
Replace 'complaint' with 'feedback'.
Is all feedback bad now because you have the opportunity (however unrealistic to many) to just sort it out yourself, or just use different software?
Or do you only dislike the concept of feedback when it's not positive?
Is all feedback bad now because you have the opportunity (however unrealistic to many) to just sort it out yourself, or just use different software?
Or do you only dislike the concept of feedback when it's not positive?
I don't think this discussion is helped by rephrasing some of the core statements until they mean something different.
This entire topic was about people kicking some dirt at Firefox because it didn't have individual line number markers until now. That's not feedback, that's not even just complaining anymore.
Of course feedback isn't bad and even complaints aren't bad - if they are directed at making the situation better. If it's just random people bitching in their own blog or a comment site like HN about how slow, bloated or whatever the criticism-du-jour-X of firefox is, that's their right, but it doesn't get anybody anywhere and they shouldn't pretend like it's Mozillas fault for not having a process for addressing and pleasing them.
If they want to actually see Firefox progress, they need to put their speech where it is heard and put their hands where they help. People who do neither are complaining for its own sake or to show off how much better alternative-option-du-jour-Y is, to them. Both don't get anybody anywhere, so THAT is bad - has always been, will always be, anywhere.
This entire topic was about people kicking some dirt at Firefox because it didn't have individual line number markers until now. That's not feedback, that's not even just complaining anymore.
Of course feedback isn't bad and even complaints aren't bad - if they are directed at making the situation better. If it's just random people bitching in their own blog or a comment site like HN about how slow, bloated or whatever the criticism-du-jour-X of firefox is, that's their right, but it doesn't get anybody anywhere and they shouldn't pretend like it's Mozillas fault for not having a process for addressing and pleasing them.
If they want to actually see Firefox progress, they need to put their speech where it is heard and put their hands where they help. People who do neither are complaining for its own sake or to show off how much better alternative-option-du-jour-Y is, to them. Both don't get anybody anywhere, so THAT is bad - has always been, will always be, anywhere.
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.
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.
Note that Firefox did show the line (and column, which is impossible to get in Chrome) number if you actually clicked on any point in the view-source window. It just didn't have a gutter on the left with the line numbers.
As far as the ruby tag, if you really are interested I'd be very glad to get you up to speed. There's a partial patch, but it has some issues that should really get dealt with before it lands. Of course every single ruby implementation out there is broken as hell in the relevant ways, so maybe it should just land issues and all... In any case, let me know if you do want to get it into shape. I do have to warn that this is not a small-and-simple project unless you really want to learn about the layout engine internals anyway.
As far as the ruby tag, if you really are interested I'd be very glad to get you up to speed. There's a partial patch, but it has some issues that should really get dealt with before it lands. Of course every single ruby implementation out there is broken as hell in the relevant ways, so maybe it should just land issues and all... In any case, let me know if you do want to get it into shape. I do have to warn that this is not a small-and-simple project unless you really want to learn about the layout engine internals anyway.
Thanks for the offer. I would take you up on it but as you say (and I sort of expected) it's not going to be a simple project and I have a lot on my plate right now.
The "switch to something else to fix a bug" strategy is clearly unsustainable. What do you do when you find a bug in chrome then? Switch back to firefox? Switch to opera first before you switch back to firefox? Just change browsers every month in the hope that they all have different bugs?
(chrome has plenty of bugs: the latest update on linux has a tendency to hang and use 100% cpu in some glib functions)
On the other hand to do changes to large code bases on short notice is a big asset to your programming skills. See it as a challenge. It's well something you could put up on your resume.
Often the main challenge is just to find the code, and if you can't do that can you deal with any other non toy code bases? Once you found it a lot problems are easy.
nn -- (who has one patch in Firefox)
(chrome has plenty of bugs: the latest update on linux has a tendency to hang and use 100% cpu in some glib functions)
On the other hand to do changes to large code bases on short notice is a big asset to your programming skills. See it as a challenge. It's well something you could put up on your resume.
Often the main challenge is just to find the code, and if you can't do that can you deal with any other non toy code bases? Once you found it a lot problems are easy.
nn -- (who has one patch in Firefox)
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.
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.
The ruby tag is not related to the ruby language
http://dev.w3.org/html5/spec/Overview.html#the-ruby-element
Seems to be part of the standard...
http://dev.w3.org/html5/spec/Overview.html#the-ruby-element
Seems to be part of the standard...
Alright, I did not actually know that.
i'd say go right ahead.
I'll note also that it's a draft - something that annoys me with HTML5. New drafts are sent every next day or so, so it's not actually very standard. It's a different story though.
i'd say go right ahead.
I'll note also that it's a draft - something that annoys me with HTML5. New drafts are sent every next day or so, so it's not actually very standard. It's a different story though.
Chrome folks believe in .. implement whatever helps Google make money/adverts/lock-in users.
Citation needed.
Citation needed.
I had the hat on.
But for the sake of discussion, please keep entire quotes, instead of rewriting what I wrote initially.
Chrome folks believe in .. implement whatever we think is faster than what we have
For example SPDY is faster. NaCl is faster. That's not bad. It's just not the same focus.
Now, NaCl also helps making money and helps with lock-in for example.
There are several other examples in the -webkit functions and some things which are not part of the actual webkit (only Chrome's version) such as Dart and the like.
But for the sake of discussion, please keep entire quotes, instead of rewriting what I wrote initially.
Chrome folks believe in .. implement whatever we think is faster than what we have
For example SPDY is faster. NaCl is faster. That's not bad. It's just not the same focus.
Now, NaCl also helps making money and helps with lock-in for example.
There are several other examples in the -webkit functions and some things which are not part of the actual webkit (only Chrome's version) such as Dart and the like.
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.
> when Google gets big enough [..] it's going to take Chrome in its own direction
Hasn't Google already taken Chrome in its own direction? Chrome includes lots of non-standard technologies like Flash, NaCl, Pepper, Chrome Apps, and soon a Dart VM. Google believes these technologies are good, but no other browser does, and not even WebKit.
Maybe those are good and useful technologies, that is a separate matter. I'm just pointing out that Google is already well in the process of taking Chrome in the direction Google feels is best, regardless of what the rest of the web thinks.
Hasn't Google already taken Chrome in its own direction? Chrome includes lots of non-standard technologies like Flash, NaCl, Pepper, Chrome Apps, and soon a Dart VM. Google believes these technologies are good, but no other browser does, and not even WebKit.
Maybe those are good and useful technologies, that is a separate matter. I'm just pointing out that Google is already well in the process of taking Chrome in the direction Google feels is best, regardless of what the rest of the web thinks.
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?
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.
Chrome doesn't have nearly enough market dominance for me to make accusations about it; I just want to minimise any future disaster scenarios.
>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.
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 is, but think about it; all the developers that know how to fix this also know how to fix one of the other million bugs in Firefox. And those are probably more important "to developers" than this one.
All bugs and features are important to someone; the reality is that there is an infinite amount of stuff to do that would be of great benefit to everyone, but only a finite (but perhaps large) number of people that are able to act on. The only way to act purely in your own self interest is to do something yourself; then you get one task and one person to implement it that you have full control over. Acting entitled doesn't get you anything other than the ability to stop giving Mozilla money and switching to Chrome. (But I'm guessing that 99% of people wanting Firefox features aren't giving Firefox any significant amount of money. A feature like this probably takes someone skillful 8 hours to implement. At $100/hr, which is a reasonable rate for an employee with overhead, you should be donating $800 to be entitled to a fix. And that's not even how donations work.)
I'm saying that if this enhancement was truly important, it would have been done sooner. What people think is important and what is important are often very different. "Let the market decide," is my philosophy.
All bugs and features are important to someone; the reality is that there is an infinite amount of stuff to do that would be of great benefit to everyone, but only a finite (but perhaps large) number of people that are able to act on. The only way to act purely in your own self interest is to do something yourself; then you get one task and one person to implement it that you have full control over. Acting entitled doesn't get you anything other than the ability to stop giving Mozilla money and switching to Chrome. (But I'm guessing that 99% of people wanting Firefox features aren't giving Firefox any significant amount of money. A feature like this probably takes someone skillful 8 hours to implement. At $100/hr, which is a reasonable rate for an employee with overhead, you should be donating $800 to be entitled to a fix. And that's not even how donations work.)
I'm saying that if this enhancement was truly important, it would have been done sooner. What people think is important and what is important are often very different. "Let the market decide," is my philosophy.
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."
> This is how Free Software projects work
That's simply not true. Maintainers exist to coordinate effort, not to do all the work themselves.
A good example is GNU Emacs. There are two maintainers, but most of the code is written by other people. Even RMS' code doesn't amount to a particularly large percentage of Emacs anymore.
A good example is GNU Emacs. There are two maintainers, but most of the code is written by other people. Even RMS' code doesn't amount to a particularly large percentage of Emacs anymore.
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.
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...]
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...]
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 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.
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
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
Save yourself the time and skip the Soda UI part of the blog post
The dev version has autocomplete http://www.sublimetext.com/dev
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).
* 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).
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.
Is it wrong to think badly of an editor where it's up to the developers to add a colour picker when the users want one? Emacs has a simple colour palette widget available at runtime.
it's a closed-source editor. the dreamweaver-style colour picker that the op is talking about is a gui widget that (unless the developers have gone out of their way to allow users to script the user interface itself with runtime bindings to every possible platform widget) pretty much has to be added into the core by a developer. emacs has gone out of its way to provide an extraordinary level of scriptability (more so than any other editor i know; i can only think of the old dos aurora that came close in the amount of functionality it pushed upwards into the extension-language level), and even they didn't allow for a real palette widget (if you read the wiki, the palette is hacked together from "zillions of tiny space characters, each in a different face", which is ingenious, but not exactly user-optimal).
How do you use it on emacs? I've been trying to use it since a couple weeks (and I really wonder when I'll be productive on it...).
Going pretty far off topic here, but you might enjoy rainbow-mode: http://julien.danjou.info/software/rainbow-mode as a partial alternative (although it's more a preview than a picker)
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.
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?
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?
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.
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.
I don't use line numbers in VS, because clicking on an error message takes me directly to the line I care about.
In Firefox, viewing the source from the error console highlights the line that the error was on.
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.
The wheels of progress turn slowly, to paraphrase someone talking about mozilla.org in 1999.
Seems like some of Blake Ross' code was not touched since his departure many years ago.
1.11 * Blake Ross <[email protected]>
1.12 + * Geoff Lankow <[email protected]>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
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.
I think such ones are usually fixed if you make a public fuss about it.
Sad but true.
And no other feature was implemented in that timespan! Outragealicious!
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.
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.
The line to shout FINALLY! at the top of their lungs starts here.
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.
Having line numbers will be a nice addition when I'm not using Firebug as a simpler way to quickly find something.
Just trying to learn about HN. Commenting why having page numbers will help me is a down votable offence?
>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?"
>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?"
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.