LRU tab removing strategy, working?
Using latest PHPStorm (7.1.3) on Ubuntu 12.04
Just checked my options: having 10 tabs/files loaded and shown on screen, when loading another one, PS should replace the LRU (Least recently used) one with that file.
However, and this is pretty annoying, PS removes the MRU (Most recently used!)... So when switching between two files several times, I end up having to click in the file list all the time...
Did I miss an option somewhere? Is it a feature? A bug?
Please sign in to leave a comment.
Looks similar to http://youtrack.jetbrains.com/issue/IDEA-115711, it's fixed in b. 134.975
Can we expect an official release soon?
I'm not aware of the exact timeframe for the new release. Follow us on Twitter:
https://twitter.com/phpstorm or subscribe for our blog: http://blog.jetbrains.com/phpstorm/ to stay informed about our news.Actually, considering the high level of annoyance of this bug + the easiness of the fix* wouldn't it be legitimate to expect an update soon**?
There has been no official update since early February ! (from 7.1.3)
*supposedly easy to fix: assuming it is a easy fix... the LRU algorithm is high-school grade...
**the bug was submitted on November 2013!
So you want an update (new version) for every bug fixed / feature implemented?
The next stable version will be v8.0. Until it will be officially released you can try EAP builds -- stable enough -- PhpStorm EAP
> So you want an update (new version) for every bug fixed / feature implemented?
No. But if your team would perform better regression tests before offering an update, everybody would be more satisfied.
Sorry, but while the version is flagged 7.1.3, there are still a number of annoying bugs, including this one, that show after a few minutes of using PhpStorm.
We probably have a different view of how to manage a project, but my team would never let a production version with obvious (and annoying) bugs unfixed, especially when they would show quickly during anti-regression tests (and when it seems the bug would take a couple of minutes to be fixed (? hopefully)).
Even though we are woking on Java projects, the same guidelines should apply.
Regarding the EAP builds - if they're stable enough, and have less bugs that 7.1.3, i.e. are trustworthy - why not simply push them as an official release?
Why do we have to wait for V8, certainly adorned with new features, but obviously (statistically) flanked with numerous bugs and regression problems?
Maybe because they follow product release cycle?
And maybe because NEW features are not fully implemented yet / still has things to work on (e.g. performance / optimisations etc)?
I wonder -- why MS Windows or Visual Studio (purelly as an example) has public or limited betas, RCs ... why they could not simply publish it as final straight away?
---
Cannot comment on other stuff -- not part of JB in any way.
>Why do we have to wait for V8, certainly adorned with new features, but obviously (statistically) flanked with numerous bugs and regression problems?
The bug that is mentioned in this thread is already fixed and available in EAP (after 134.975 branch).
As Andriy correctly mentioned, we are following release plan. We do not have plans for minor releases before major 8.0 release (see ETA and development roadmap here: http://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Development+Roadmap ).
And can you be more conrete about exact bugs and regressions?
> I wonder -- why MS Windows or Visual Studio (purelly as an example) has public or limited betas, RCs ... why they could not simply publish it as final straight away?
Usually even though they sell a main new version, they keep fixing the main bugs of the previous version.
Of course, there are betas...
But at some time the beta becomes an official release. And it seems the 134.975 will never become an official release.
We're targetting efficiency in development, not a fight.
If the PhPstorm EAP versions are "officially" fine (I would never install an iOS or Ubuntu or ... beta), then fine, I'll use it.
By the way, where do I find 134.975 ?
Checked
http://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Early+Access+Program and "Earlier versions" or
http://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Development+Roadmap
but could not find 7.x.y / 134.975...
> We do not have plans for minor releases before major 8.0 release
(See answer above)
> can you be more conrete about exact bugs and regressions?
I'm used to tolerate (forget) the minor flaws met during a prog session. The "tabs" one was really annoying, thus the posts.
This afternoon for instance, while modifying a method, PS kept adding more '{}' than necessary (after RCs), but it happened 3 times, then I changed the method, reloaded PS and the behavior didn't occur again.
(doesn't have the exact code anymore)
It appeared - and I could be wrong - that the algorithm to decide what to do after RC does seem to be empirical, while its complexity would not even be asked in the qualification round of the "google code jam".
(Eclipse has been doing that well for some time, Emacs a bit less, but not bad either).
But again I can be wrong. And during a dev phase no I don't want to spend time reporting x or y. That was fine after a reload of PS ( / change of code, whatever was the reason), and was minor.
Trsut me or not on this bug - is not my problem. Again only one target: code efficiently.
Thanks for providing me the link with 134.975
That could be a good start.
Well, 136.X build contains all fixes that were in previous builds. I hope, it's clear why. And the latest (yesterday's) build you can find here: http://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Early+Access+Program .
> Well, 136.X build contains all fixes that were in previous builds. I hope, it's clear why
Well, 136 is v8... so I would have preferred the latest v7, I hope it's clear why :-)
133 branch is the latest branch for version 7. This fix is only available in version 8 EAPs.
> 133 branch is the latest branch for version 7. This fix is only available in version 8 EAPs
Oh.. 134 is v8... ok so the puzzle is completed seemingly.
Let's have a look at that 136... Thanks for your patience.
> things to work on (e.g. performance / optimisations
The very first optimization is to program correctly, ie implement the right algorithms.
Would you dare to send me the code that takes care of the "smartness" of PS? The one that adds automatically {} etc... ?
I am sorry, you asked me or Andriy (because you quotated his post)?