Re: [platform-ui-dev] Changes to the Editors preference page

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Personally I think auto-closing editors is a bad idea. The simple
reason is that if you do that you dump the Undo stack of that editor.
That means this flow (which is pretty normal for me) would be broken:

1) Make an edit
2) Explore around 20+ files trying to figure out exactly which method
did what in what call hierarchy, etc.
3) Press Ctrl-Q (last edit position)
4) Press Ctrl-Z because at step 2 I realized the very last thing I
typed in Step 1 was wrong.

Dumping of my Undo buffer is not a good user experience.

In addition, for graphical editors, the state is not restored well
when using Alt-Left / Alt-Right. i.e. you may end up back in the
correct editor, but not the correct scroll bar position, zoom level,
etc depending on the editor.

Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 14 March 2016 at 20:52, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>> 4. Auto closing editors is highly distracting during a complex debig
>> session, because the
>> important context / knowledge gets lost.
>
> What is it about the behavior that is distracting and what specific
> knowledge is lost?
>
>
> On Mon, Mar 14, 2016 at 1:08 PM, Andrey Loskutov <loskutov@xxxxxx> wrote:
>>
>> See my answers inlined
>>
>> Am 14. März 2016 19:59:08 MEZ, schrieb Stefan Xenos <sxenos@xxxxxxxxx>:
>> >> FYI, I pretty often end up with "99+" (mostly Java) editors in my
>> >IDE,
>> >and indeed it
>> >> consumes some memory, but never to a point that prevents me from
>> >closing
>> >them
>> >> and getting back into a good performance state.
>> >
>> >Okay, so you've discovered the "close all editors" action and
>> >understand
>> >that you can use it to correct Eclipse slowness when you encounter it.
>> >New
>> >users haven't discovered the action yet and almost certainly haven't
>> >made
>> >the connection between the slow performance they're seeing and the
>> >number
>> >shown in their editor chevron. The defaults should be appropriate for
>> >new
>> >users.
>>
>> I'm not sure if this is the right way to solve the performance issue.
>> We should identify, report and address each problem causing performance
>> degradation for many opened editors case.
>> If you have identified some hotspots, please open bugs for them. Simply
>> auto-closing editors because we are unable to manage performance is not a
>> solution.
>>
>> >I've received a bunch of support tickets from users reporting sluggish
>> >performance and who just had too many editors open. The "fix" is to ask
>> >them to close all editors and enable the preference. They often respond
>> >with comments like "why doesn't Eclipse just do this by default?"...
>> >and
>> >it's a legitimate complaint. Changing the default would both improve
>> >the
>> >user experience and reduce the support costs for folks who need to
>> >answer
>> >this question over and over.
>>
>> This is a wrong conclusion - the users don't want that Eclipse closes
>> editors automatically (I'm unaware about any editor which does this by
>> default) - the users want that performance is not related to the opened
>> editors count.
>>
>> BTW one possible problem with many opened editors performance could be
>> that editor rulers for all editors are repainted on each annotation model
>> change (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=467499#c20).
>>
>> >> What I'd miss with editors closing up automatically is that I
>> >actually
>> >use the order of editors
>> >> as a breadcrumb or a stack current context(s)
>> >
>> >The preference I'm talking about has nothing to do with the history
>> >stack
>> >and the back button. The history stack is based on editor inputs and it
>> >works just as well even if you enable the "close automatically"
>> >preference
>> >and set the number of editors to 1.
>> >
>> >It really sounds like you're confusing the "close editors
>> >automatically"
>> >preference in the editors page with the "reuse editors" preference in
>> >the
>> >search page. That one does interfere with the history stack.
>>
>> Same as Mickael, I do not confuse the preference, I use editor tabs list
>> on the top right side of the tab area.
>>
>> >So far you've raised three objections to the preference change:
>> >
>> >1. That it would cause editors to disappear unexpectedly. Response: The
>> >editors we're talking about have already disappeared from the tabs. If
>> >you're not referring to the tabs, please state specifically which part
>> >of
>> >the UI you expected to see the editor in but could not find it.
>>
>> The editor tab schevron with the editor list. It is useful and exists
>> exact dor tha purpose of visualisation of opened but not visible editors.
>>
>> >2. That it would interfere with the editor navigation history.
>> >Response: It
>> >wouldn't.
>>
>> Sure it would. I use editors list to navigate between opened editors, and
>> since MRU can be switched off, my editors are always in exact same order
>> I've opened them. Automatically closing the editors will break the opening
>> order again and make me crazy searching for them.
>>
>> >3. That there is actually no performance problem if you have a large
>> >number
>> >of realized editors. Response: Confirmed via profiler output, end-user
>> >reports, and static analysis of the code involved.
>> >
>>
>> You mean you confirm that *there IS* a performance problem?
>> No doubt, but I personally doubt that the auto-close preference is the way
>> to go.
>>
>> >I believe I've addressed 1 and 2 quite well. However, if you're still
>> >unconvinced about 3 I would be happy to offer some data to back up my
>> >claim. Unfortunately, I can't share my support tickets with you, but I
>> >could offer profiler output and code references to code which performs
>> >linear operations on the number of editors. What would you find most
>> >compelling?
>>
>> I think you should jave identified some "top five" performance issues -
>> please open bugs for them.
>>
>> There is point 4. which you do not have yet on the list.
>>
>> 4. Auto closing editors is highly distracting during a complex debig
>> session, because the important context / knowledge gets lost.
>>
>> IMHO auto closing the editors is one of the reasons why Mylin is not
>> activated/used by default. This os one of the highly polarizing preferences
>> where people either love or hate it. It happened to me ro be Mylyn
>> incompatible too, and in our lab I don't know anyone using it even if we
>> pre-install Mylyn because of Jira connector.
>>
>> I found really interesting Mickael's proposal to dispose inactive hidden
>> editors but let them be on the opened edotor list - so that they are
>> automatically restored if user clicks the tab again.
>> I've filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=489593
>>
>> >  - Stefan
>> >
>> >On Mon, Mar 14, 2016 at 4:35 AM, Mickael Istria <mistria@xxxxxxxxxx>
>> >wrote:
>> >
>> >> On 03/14/2016 09:17 AM, Stefan Xenos wrote:
>> >>
>> >> > If we have known performance issues with many editors, we should
>> >better
>> >> investigate and fix them one by one.
>> >>
>> >> I'm not sure how you would fix it. How would you keep an unbounded
>> >number
>> >> of realized editors in memory without consuming an unbounded amount
>> >of
>> >> memory?
>> >> You could lazily destroy editors, remember their inputs, and recreate
>> >the
>> >> actual widgets the next time it's brought to foreground... but that's
>> >> pretty much what "close editors automatically" does.
>> >> The performance problems are all over the place. Editors contain a
>> >ton of
>> >> widgets, and most stuff in SWT gets slower with more widgets since
>> >it's
>> >> filled with depth-first-searches over the widget hierarchy. Editors
>> >> register lots of listeners, and sending events to listeners is linear
>> >in
>> >> terms of number of listeners. Many editors also allocate SWT
>> >resources
>> >> which eventually results in the SWT out of handles error. Then
>> >there's the
>> >> working copies, workbench activation history, and tons of other stuff
>> >> editors do that scales linearly (in runtime and memory) with the
>> >number of
>> >> editors.
>> >>
>> >> FYI, I pretty often end up with "99+" (mostly Java) editors in my
>> >IDE, and
>> >> indeed it consumes some memory, but never to a point that prevents me
>> >from
>> >> closing them and getting back into a good performance state. So I do
>> >not
>> >> believe there is a performance problem with the simple amount of open
>> >> editors growing. However, there are definitely some editors that
>> >consume a
>> >> lot of resource when open and that it's better to close whenever
>> >they're
>> >> not used, but I don't believe it's a problem that requires Platform's
>> >> attention nor that is strong enough to introduce a new behaviour.
>> >> Also, I wouldn't like editors to close automatically by default,
>> >since
>> >> some actions such as debugging often require to open a lot of files
>> >> (debugging some complex things can request to open more that 20 files
>> >> sometimes).
>> >>
>> >> Sure, there probably ARE users that would miss the old behavior, are
>> >> willing to pay the performance penalties, and don't mind restarting
>> >due to
>> >> the occasional OOME.
>> >>
>> >> As I mentioned above, I never face the need to restart because of an
>> >OOME
>> >> caused by too many open editors. Is there a bug report on this topic?
>> >Am I
>> >> the only lucky one to not suffer from it?
>> >>
>> >> What I'd miss with editors closing up automatically is that I
>> >actually use
>> >> the order of editors as a breadcrumb or a stack current context(s),
>> >and I
>> >> find it very important to keep this organization as I take very often
>> >> advantage of it. I guess many developers do the same thing. Closing
>> >some
>> >> editors randomly would make this usage not fully possible.
>> >> --
>> >> Mickael Istria
>> >> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
>> >> My blog <http://mickaelistria.wordpress.com> - My Tweets
>> >> <http://twitter.com/mickaelistria>
>> >>
>> >> _______________________________________________
>> >> platform-ui-dev mailing list
>> >> platform-ui-dev@xxxxxxxxxxx
>> >> To change your delivery options, retrieve your password, or
>> >unsubscribe
>> >> from this list, visit
>> >> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>> >>
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >_______________________________________________
>> >platform-ui-dev mailing list
>> >platform-ui-dev@xxxxxxxxxxx
>> >To change your delivery options, retrieve your password, or unsubscribe
>> >from this list, visit
>> >https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>
>> --
>> Kind regards,
>> Andrey Loskutov
>>
>> http://google.com/+AndreyLoskutov
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev