On another note, the comment uses IntelliJ as an example. Wow, that was 17 years ago! Happy to see my favorite editor be around for so long.
"Nearly half my age," said Emacs.
In fact, Emacs was first implemented as a plugin (a set of macros in the language of the time) for a now forgotten editor called Teco, which was one of the first, if not the first, programmable editor ever.
What do you use these days?
Sounds like the culture in the CMU CS department was pretty great.
Thank you for sharing this historical gem with us.
 why on earth would they go through the traumatic change of reprogramming their muscle memory after so many years? it would be like a wizard that voluntarily gives their power away. like a father sacrificing his own child.
Gosh, "old timer" :(
Here in South Africa we typically use "old-timer" to refer to someone who is very experienced.
My comment was expressed with the utmost respect I assure you :)
Why fix what ain't broke? /s
But, I've since switched to intellij for Java (and later, lightweight editors like Sublime Text for JS, until a while later JS finally got modules and editors added more support for JS), and nowadays I'm using it for everything; I'm currently managing a 200KLOC application (it's too much but my employer isn't hiring, sigh) in at least four languages (JS, PHP, TS and Go, it's an older application and a rebuild I'm working on), and intellij has no qualms with it whatsoever.
I even set it to PHP 5.2 mode so it warns me when I try to use `` to initialize an array.
I live in fear they will be removed from PyCharm - every time I update one of the Jetbrains editors and the Netbeans bindings aren't there, I'm lost.
Remember, people learn dvorak after a life time of qwerty... and I'm sure they aren't (all) masochists.
What do you think is the biggest difference between the two?
I do a lot more Python work than Java nowadays so I use PyCharm much more than IntelliJ, though they share a lot in common. Aside from those, the only IDE I really ever use is GNAT Studio for work. I suppose I used Android Studio for a while, but that's basically just IntelliJ with some Android-specific features bolted on.
It's funny to look at how many editors one comes across over the years. My first one was Borland C++ as a kid. Then came a mix of Visual C++ and Bloodshed Dev C++ during high school. During university I tried a bunch of things but mainly nano, gedit, Visual Studio, and Eclipse. In my early career (2013) I finally got into Vim and haven't looked back since.
I did try out Rider a little over a year ago. It was really good and I'm impressed with some of its features. But it wasn't enough to make me switch.
I find it a great way to combine the strengths of Vim with the strengths of a full IDE.
Looking at you, every random GitHub project ever.
Anyway, that taught me not to report something that's not a game-ender. Which is probably what they want too, so I guess we're all in some sort of equilibrium.
(edit: _jal beat me to it.)
Few things are as infuriating as taking the time to write a great bug report just for it to be ignored or autoclosed.
The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.
Sometimes the overhead of that maintenance work isn't worth it, particularly for a bug that's been explicitly categorized as 'low priority' for years. The fact that a bug can stay at low priority for years is a reasonable sign that it's not too important to spend a lot of effort either tracking it or fixing it.
With that point of view, closing the defect as unfixed and explaining the reasons why is in some ways more honest than just keeping the thing open ad infinitum just because somebody, at some point in the past, thought there was an issue. And if closing it was wrong, you'll run into the issue again, and can either re-open the defect or submit a new defect with a back link to the original, and an explanation of what's changed that's brought it back into relevance.
(Personally speaking in the last few months, I've gotten several good solutions from reading the commentary on defects that were closed as unfixed.)
As a project maintainer, I don't want to close unfixed issues because they become much harder to find (hidden by default), which results in duplicate reports if it turns out the issue is not fixed. Also it can be rude, if it was a high effort bug report.
At the same time, I don't want to leave open years-old issues about a part of the program which has been heavily modified, because they are likely outdated, and low priority to begin with.
The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it.
But it would be really nice if bug trackers created three visual bins to dump things into, where the middle bin is this nebulous "stuff" that's not quite groomed well enough to be actionable but also not finished enough to be closed. (Note: also, "closed" should be subdivided into "implemented" and "rejected" with different visual statuses, like Merge Requests often are distinctly coloured by merged vs closed -- but this is not a separate bin).
When I got this role, I instated a culture of never closing old bugs, despite some of my managers wanting me to do that many times, and one of them even going on a rampage once and closing some of them (which I reversed as soon as he left). Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs.
To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Which helps a lot with the upkeep and with planning ahead. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed.
I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant.
Unfortunately. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. We also have too many internal users for our own good.
It's tough. But the dude abides.
Closing bugs just to make dashboards/metrics look better is wrong; either adjust the dashboard or fix the bugs.
But in game development with dedicated QA I feel such scrubs are necessary because when they're not done you end up wasting days just confirming that old bugs can no longer be reproduced and flagging them to be closed. Most bugs which linger are symptoms of other bugs which have been addressed.
If they're still there they will almost certainly be found again by QA the moment you close it. In fact, old bugs often even have newer duplicates.
We're on our 3rd or 4th now.
I'm lost for words. Can't you just put a tag and park it? What is this obsession about keeping the issue count low?
The rationale was that they only did that sporadically every few years, when some other change mooted the issue. If they ignored feature requests on a schedule, it would better manage external expectations.
See also, The CADT Model (but copy-paste the link in to your browser bar to avoid a bit of unrelated commentary):
Take a look at the root pages html source
> The CADT Model
>© 2003 Jamie Zawinski <firstname.lastname@example.org>
>In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows:
>>Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
>This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
>I'm so totally impressed at this Way New Development Paradigm. Let's call it the *"Cascade of Attention-Deficit Teenagers"* model, or *"CADT"* for short.
>It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?
>But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
[random GIF of a compass, that links to the homepage]
> I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.
Sounds like the content is just as mature and insightful as the HN ddos redirect image. I see why objecting to being linked an image of a hairy ball in a 2011 image macro was wrong of me.
As much as it pains me (I’m still tracking multiple bugs I reported) to say this, but all tickets with no activity for some reasonable time period must simply be closed. Things are _already_ out of control.
No, any open source project needs someone (or multiple people) triaging tickets; either keep them open and make sure they are implemented in a reasonable time, or close them as a 'wontfix'.
Of course, then you'll have the issue of people opening up new tickets for the same thing, and the triagers will have to either point them to the old ticket, or the discussion about whether or not to do it has to be restarted.
There’s just this thing called “reality” and unless your ticket by coincidence ends up catching the eye of someone who can actually do something about it, it will be left to rot. And because nobody will bother looking at the oldest ticket known to man™, the close-bot may as well close it. Tens of thousands of untriaged reports aren’t helping anyone.
I've literally had issues I filed that the maintainer verified as an actual bug be closed due to lack of activity. I can understand that an unpaid maintainer doesn't have the time or motivation to fix it, but closing issues you know are valid seems insane to me.
> someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
I don't understand this part. Aside from the fact that it's trivial to exclude certain tags (it's the same config file, and it's in the first example they give), doing this effectively makes your issue tracker useless as an issue tracker. Why not completely disable the issue tracker instead then?
1. Release a project on GitHub
2. Get busy with other things / deluged in issues
3. “I don't have time for this. Let me install the auto-close bot!”
4. Issues get closed
5. [sometimes never] “I better configure the auto-close bot to only act on untriaged issues”
But all in all, I'm pretty happy with Firefox. This is a very minor thing for me.
Basically, they are not at all the same.
This is likely a separate ticket, but Firefox ignores macOS' built-in text replace which I use for expanding text like my email address.
For its time it was a great little browser. I was going to do some bug fixing on it. But then I saw that it required Corba ORB to build. So I let out a long, low moan and, shivering uncontrollably, filed that dream under never going to happen.
It’s probably .com because it’s for Mozilla Corporation as opposed to Mozilla Foundation.
My heart goes out to those wretched souls.
There are two entities: the Mozilla Foundation--which is what everyone thinks of when they hear "Mozilla" and think Mozilla is a non-profit--and the Mozilla Corporation--which is what actually comprises the bulk of Mozilla's operations.
The Foundation does practically nothing. Your donations to the Foundation don't go towards development of Firefox, they mostly go to pay the salaries of the Foundation employees, who mostly work to... raise money for the Foundation to pay their salaries. This is a problem with a large number of non-profits in general--that most of the money raised is just spent on maintaining the fundraising apparatus. But in particular at Mozilla, it's a drop in the bucket of what Mozilla Corporation needs to keep operating.
The vast majority of the actual software development work is done under the corporation. And the vast majority of funding that the corporation has comes through a search advertising deal that Mozilla struck with Google.
* check own RSS feeds *
Nope, still alive
I use Firefox exclusively and this is the single most annoying change they made for no apparent reason. So annoying.
I hate that behavior. When I click in the address bar, it's because I want to edit the URL. If I want to go somewhere else, I'll open a new tab, or use a bookmark, or click a link on a page. In the rare case that I want to type a whole new URL, but keep the same tab, I can easily triple-click or [Cmd]+A before I begin typing.
Notably Ctrl+C/Ctrl+V operate on the clipboard, while selection and middle-click operate on (at least) selection1.
Which is my main use case for clicking in the location bar, copying the URL. So I appreciate that single-click selects all, so I can then copy with a keyboard shortcut.
I'm confused by your comment "when I want to copy it I have to triple-click anyway" -- I'm guessing you are on linux(?)... does triple-click or select alone automatically copy on Linux? (If select alone normally copies to clipboard, then I'd say it's a bug that it "looks selected" but hasn't copied to clipboard?)
This may be a thing where different behavior is appropriate for different OSes. Perhaps the FF devs who rejected the feature are also Linux users? I think FF wants to get market share beyond what can be achieved focusing on Linux users though.
I think they should make this configurable though, I can see both sides of it.
Ctrl+Click -> insert
CTRL+L would be the shortcut, but often I browse without my hand on the keyboard, just the trackpad or mouse.
You'd think after so long, I'd get used to the behavior and just single-click it. But apparently Pavlov would have me culled from his experiment :)
I would wager almost anything that this is the case for the vast majority of regular users because most of the ones I've interviewed (N = 31) for a uni UX study didn't even know how to read URLs for the most part - especially not after the ? query part.
I doubt many people type much into the omnibar other than input for advertising platforms.
They should probably replace
today I want to buy...
Sure, these extensions and workarounds are dangerous and inconvenient, but I do love well behaved web browsers.
I'm with you on this. But to me the worst annoyance is how it tends to revert to a previous URL when the new URL fails to load, either because it truly failed to load due to an error or because it timed out while I'm walking through breakpoints.
When I manually entered a URL, the edit should stick even if it doesn't load, dammit.
But it's difficult to click the leftmost or rightmost character to position the cursor.
So after clicking, I usually tap Ctrl+A (Cmd+A) to "select all" anyway, and then tap left-arrow or right-arrow to deselect and jump to the chosen end of the URL.
Cursor keys only junp to the end if it's selected. My keyboard doesn't have dedicated home/end keys, but I'd probably use the select-all-then-arrow trick anyway.
The use of Cmd instead of Ctrl for CUA shortcuts (and the resulting ability to use Emacs-style shortcuts without issue) is one of the few macOS features that I wish would propagate to other operating systems. The only other OS that comes close with this sort of usability is Haiku (which allows configuring either Ctrl or Alt for the CUA modifier, with Alt by default).
When they added the omnibar they just ripped out the feature flag because reasons.
Unfortunately, Alt+D is also sometimes overridden by JS applications. This is especially annoying in Google Sheets.
Ctrl+L will still work.
The comments on the bug report point out that the new behavior makes Firefox on Linux different from other Linux applications, including some browsers. The devs said they want Firefox to be consistent across platforms, whereas the Linux users want Firefox to be consistent with the rest of their system.
The new behavior is also different from the behavior of text boxes rendered by Firefox.
Editing strings in `about:config` seems to behave identical to the URL bar, and Ctrl+F behaviour is similar (but other search bars, like in settings, do not highlight all). Possibly more, just did a quick check of the text boxes I remember Firefox's UI having.
I also know that I'm in the minority, and that maybe the size of my cohort is too small to add yet another thing to check during regression testing.
But I'm still mad about it :) Firefox always seemed like the browser for people who want to configure weird things, or extend it in all sorts of crazy ways. More and more it's becoming a me-too browser, and the only reason I'm sticking with it is out of a sense of duty to fight a Chrome monoculture.
> It is possible to do both. The answer is customization
Err well that’s not doing both then is it? That’s having customisation. I don’t want customisation. So that’s not doing both at all that’s just doing it your way and ignoring me.
Unfortunately, that dumpster-fire of a bug-report/thread is a horrible abomination that shows massive hubris on the part of the developers; and I say this as a developer myself --- and one who fights against this sort of thing far too often to count. Change the defaults if you really want, but never remove the choice.
(The argument that it has "costs" is stupid --- yes, everything has costs, but they actually have perceived value in this case, unlike working on something else, often of much greater complexity and cost, that your users never even asked for in the first place!)
> it [single clicking not selecting all] was a special behavior only implemented for Linux, it was not consistent with Firefox on other OSes, and with other browsers on Linux itself. The prefs were causing broken edge cases complicate to handle, taking into account all the possible pref combinations (for example under certain combinations it was not possible to select a word), and having to execute more tests for them. Not removing the prefs would have not saved many resources, since we still need to maintain them.
Why can’t you just have both options?
> Most of the tests should then be able to run with both setups, everytime we touch something around that we'll have to check not breaking it, and so on. Yes, even the simplest pref skipping a line has a cost, and that's why they must be weighted with a benefit.
> Apart from what I already said regarding the will to unify the behavior for the more commonly found case of users moving across OS and browsers, and the cost of options in general, I'd like to explain a further reason why it's not just matter of reintroducing a pref; the change we made here will allows us to experiment more broadly with the unfocused Address Bar contents, for both UX and security reasons.
Keeping browser.urlbar.clickSelectsAll around would make experiments a lot more problematic, and at a certain point we may have to remove the pref regardless, because it would block landing improvements. So we'd end up causing you frustration twice.
We totally understand your point of view on this matter, unfortunately sometimes changes must happen, to be able to evolve things.
Shame you cant "give the devs opinion" on bugzilla.
> Is a wontfix with lots of comments more expensive, than a wontfix with comments blocked?
Yes, it is more expensive. When 100 developers are CC'd on a bug that is generating regular "but did you consider this argument?" comments, it's a lot of overhead.
You could argue that everyone CC'd should remove themselves from the CC list when this happens, but by that time we'd already have taken the hit.
These bugs are not fun for anybody, dev or unhappy user alike.
Then fix them.
If I opened an issue asking Firefox to switch their rendering engine to Blink you better bet it would be closed wontfix and stay that way for a long ass time.
I don't remember it doing that before but maybe i have a bad memory
So news.ycombinator.com it goes to the right of https:// and www.reddit.com it goes to the right of https://www.
Personally, my preferred way of displaying a URL and interacting with it is a full, unmolested URL, in a regular UI edit control.
FWIW, this is fixed in Firefox 3.6; you should probably upgrade.
However I can relate: When I tried to use chromium I got really annoyed that clicking and dragging the selection with the mouse up or down would not automatically select the complete text in front or behind the cursor in the url bar.
Firefox still allows to do that under Linux. Hopefully they will not change that as well.
I don't really care about consistency with other browsers - I don't use other browsers very much. I care about consistency with everything else on my desktop.
(It's not just about the option - I didn't even use the browser.urlbar.clickSelectsAll option myself. The clickSelectsAll=false behaviour - the one that was removed - had been the default on Linux.)
This may just be laptop/touchpad users complaining, and mouse users not comprehending what the big deal is.
The one that grinds my gears is that when you select the URL bar in Chrome it shifts the whole thing to the right, so if you want to edit text you have to reposition the cursor, you can’t just click, pause, then click again.
No longer shows up here, because it's now 135 votes.
Now both firefox and chrome dont allow you to change the adress easily to manually remove amp.
I wonder if some Firefox developer was bribed
I don't see what the single-click functionality has to do with removing something from a URL (as almost all users would perform selection with click-and-drag or a double-click). The primary use case would be for adding text.
Not sure I like the idea that a "feature request" can be "fixed". It's a feature, not a bug. It's a request, not some sort of obligation of the development team.
Still though, it's good to see a process work over a 17 year long period, in an industry where things oftentimes seem to be thrown out in a matter of a few years.
You can set browser.quitShortcut.disabled=true in about config starting with Firefox 87.
Coincidentally, when Mozilla's blog post about shipping a big cookie separation feature was on the front page recently, the first thing I thought was "but when will they let you disable CTRL+Q? It'd be so much easier to do than this." In the age of Chromium, issues like this will lead to death by a thousand cuts for Firefox. The cost of switching is marginal for most people, as Chrome has become too well-architected as a browser which ends up connecting you to Google. I myself was almost tempted to switch because of this and other relatively minor issues that ended up snowballing together, and I'm a person that makes a deliberate effort to like Firefox. I have to wonder why nothing changed in 2002, when so many people were making so much noise about this.
I don't think I can explain the extent to which this simple papercut has been vicious and painful to me.
So many times, I've started writing some long post in a text field and accidentally lost it due to pressing some wrong keyboard shortcut (oops, you pressed backspace outside a text field! oops, we bound this key to 'reload the page', oops you closed the form by pressing ESC!). It's always a particular type of sinking feeling to have to start writing all over again.
Now there are extensions for this, and some of them even work. But what's my natural instinct when I have data in a text field I really don't want to lose because I would feel terrible losing it?
Well, ^A ^C and go paste it in a notepad, maybe even finish editing it there.
... and then Firefox quits, maybe because my layout switched between AZERTY and QWERTY by accident, maybe because my finger slipped between A and Q. And I get to stare at my desktop, crushed and defeated, having lost my data at the exact worst possible time...
I was seriously starting to consider maintaining my own Firefox fork, and I _cannot thank you enough_!
For me it's often ctrl+w to delete one word, which terminals have gotten me used to. I don't want the shortcut removed because I use it all the time to close tabs outside a text box, but it also still working while focused in one is annoying.
My FF is configured to delete all history upon exit, so I have lost SO MANY interesting browsing sessions over the years due to CTRL+Q!
Thank you very much for finally resolving this!
Thank you so much fpr actually fixing bugs!
If my impression of Mozilla is correct you must have both done the work and possibly also fought hard to be allowed to merge it.
(Now, if any Mozillan feel inspired I'd love to get my real extensions back, particularly TST without top tab bar and also Scrapbook.)
Another favorite of mine: `browser.tabs.closeWindowWithLastTab` set to `false`. This lets me cmd-w as many times as i want but it won't close the window I have open.
Only drawback (maybe) is that every open project in VSCode warns when trying to close the entire app.
Wayland probably providers tighter coupling, but then you'll need cooperation with applications... GNOME has gone toward this direction, but applications not developed by GNOME basically ignore their efforts to make applications and window manager feel like a cohesive whole.
Firefox is still a fantastic browser but it can be frustrating in many small ways.
It is older!