| Re: [platform-ui-dev] Changes to the Editors preference page |
I wrote a benchmark for it, but I must have misremembered where the bottleneck was (or perhaps computers got faster since I profiled it in 2005.) The CTabItem constructor worked reasonably fast for below 1000 tabs, so I didn't file a bug.
Sorry for spamming the list with bad information. (Note that this doesn't mean Eclipse performs well with unlimited numbers of tabs - just that the CTabItem constructor isn't at fault)
At 1000 tabs, there was a noticeable delay when switching tabs (300ms or so spent in CTabFolder). That may be worth investigating if you'd still like me to file something...
- Stefan
Created for the proposal to warn the user about this.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=490353
Stefan, did you create a bug for the O(n^2) performance issue? Warning
is good, but I think we should leverage your performance measurements
to improve this situation in general.
Best regards, Lars
On Thu, Mar 24, 2016 at 12:17 AM, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
> Yes, that one and many others. :-(
>
> ...but if we were to open the notification that Lars suggested above, at
> least users would be aware of why their performance is degrading and be
> aware that there's something they can do about it.
>
> On Wed, Mar 23, 2016 at 2:37 PM Snjezana Peco <snjezana.peco@xxxxxxxxxx>
> wrote:
>>
>> The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=467499 would
>> need to significantly improve performance if there are many opened
>> editors in an Eclipse workspace (at least on Linux and Mac).
>>
>> Snjeza
>>
>> On 3/18/2016 11:00 AM, Lars Vogel wrote:
>> >> What about the other changes I proposed to the preference page?
>> > +1 to https://bugs.eclipse.org/bugs/show_bug.cgi?id=489891
>> >
>> > On Thu, Mar 17, 2016 at 4:04 PM, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>> >> Yes. I suppose an info pop-up would solve the problem, too.
>> >>
>> >> -Stefan
>> >>
>> >>
>> >> On Thu, Mar 17, 2016, 6:24 AM Lars Vogel <lars.vogel@xxxxxxxxxxx>
>> >> wrote:
>> >>> @Stefan, can you open a bug report for the O(n^2) performance in
>> >>> creating
>> >>> N tabs? This sounds definitely wrong. If you already have some tracing
>> >>> data
>> >>> why this happens, please attach it to the bug (or even better upload a
>> >>> fix
>> >>> for this behavior). Maybe more issues like Bug 467499, or maybe also
>> >>> solved
>> >>> with this bug.
>> >>>
>> >>> I personally switch on auto-close of editors whenever I notice a UI
>> >>> delay
>> >>> with my >99+ editors but I agree to the general discussion that
>> >>> setting auto
>> >>> close as default might be distracting for the user.
>> >>>
>> >>> Maybe we could bring up a small info popup the first time we hit more
>> >>> then
>> >>> 99 editors and inform the user about the auto-close performance
>> >>> advantage
>> >>> and allow to activate the setting via this popup?
>> >>>
>> >>> Best regards, Lars
>> >>>
>> >>> Am 15.03.2016 1:32 vorm. schrieb "Stefan Xenos" <sxenos@xxxxxxxxx>:
>> >>>>> the number of apparently open tabs can grow to hundreds with little
>> >>>>> to
>> >>>>> no performance penalty as there are no SWT controls or listeners.
>> >>>> Actually, some of the performance problems occur even with just tabs
>> >>>> --
>> >>>> for example, incrementing the number of tabs requires instantiating a
>> >>>> CTabItem, and creating n CTabItems takes O(n^2) time. It has a low
>> >>>> constant,
>> >>>> but if you create enough tabs (even without realized editors), it
>> >>>> gets very
>> >>>> slow.
>> >>>>
>> >>>> - Stefan
>> >>>>
>> >>>> On Mon, Mar 14, 2016 at 6:15 PM, Jonah Graham
>> >>>> <jonah@xxxxxxxxxxxxxxxx>
>> >>>> wrote:
>> >>>>> Hi Stefan,
>> >>>>>
>> >>>>> (I am pleased that you are pursuing trying to solve this performance
>> >>>>> issue! Solving this kind of bigger problem in Eclipse always seems
>> >>>>> like an uphill battle.)
>> >>>>>
>> >>>>> Perhaps there is a heuristic that can be used to determined when to
>> >>>>> close editors earlier before we worry about the "critical" number of
>> >>>>> active editors. e.g. Only close editors that are AbstractTextEditors
>> >>>>> with no undo buffers?
>> >>>>>
>> >>>>> Also, instead of closing the editor completely, how about replace it
>> >>>>> on the editor stack with an unrestored Editor? That way all the
>> >>>>> editor
>> >>>>> tabs are preserved, the number of apparently open tabs can grow to
>> >>>>> hundreds with little to no performance penalty as there are no SWT
>> >>>>> controls or listeners. This method also preserves cursor
>> >>>>> location/selection. Specifically I am referring to functionality
>> >>>>> org.eclipse.ui.IPersistableEditor adds to an editor.
>> >>>>>
>> >>>>> Doing the the two things above may allow you to free most editor
>> >>>>> resources after only a handful (your 20 number comes to mind) of
>> >>>>> editors are opened.
>> >>>>>
>> >>>>>
>> >>>>> The other approach to dealing with the undo buffer is of course to
>> >>>>> persist it to disk. I think that would be a good feature on its own
>> >>>>> and if you add in autosave to the mix you get better preserved state
>> >>>>> and a more complete restoration of your exact workbench when you
>> >>>>> close
>> >>>>> it. Similar to local history you could have an expiration time /
>> >>>>> size
>> >>>>> / entries. Slightly OT.
>> >>>>>
>> >>>>> Jonah
>> >>>>> ~~~
>> >>>>> Jonah Graham
>> >>>>> Kichwa Coders Ltd.
>> >>>>> www.kichwacoders.com
>> >>>>>
>> >>>>>
>> >>>>> On 15 March 2016 at 00:25, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>> >>>>>> Jonah, that's a pretty compelling use-case. You've convinced me
>> >>>>>> that
>> >>>>>> it's a
>> >>>>>> place where auto-closing editors will produce a bad user
>> >>>>>> experience.
>> >>>>>>
>> >>>>>> However, clearly we can't retain full editor states for an
>> >>>>>> unlimited
>> >>>>>> number
>> >>>>>> of editors. At a certain point, performance degrades intolerably...
>> >>>>>> and at a
>> >>>>>> certain point beyond that, Eclipse crashes due to running out of
>> >>>>>> SWT
>> >>>>>> handles
>> >>>>>> or heap space. If you reach that point you'd also lose your undo
>> >>>>>> stack.
>> >>>>>>
>> >>>>>> Why don't we do some performance measurements, and pick the largest
>> >>>>>> number
>> >>>>>> of editors we possibly can before the performance becomes
>> >>>>>> unbearably
>> >>>>>> slow or
>> >>>>>> anything crashes on a 32-bit VM -- and only close editors at that
>> >>>>>> point.
>> >>>>>>
>> >>>>>> So we could turn on auto-close editors but make the number of
>> >>>>>> editors
>> >>>>>> as big
>> >>>>>> at we can before performance degrades too much, and we can
>> >>>>>> collectively
>> >>>>>> decide what we feel to be "too much". That way you'd normally be
>> >>>>>> able
>> >>>>>> to
>> >>>>>> keep your undo stack, but Eclipse could still resort to discarding
>> >>>>>> an
>> >>>>>> undo
>> >>>>>> stack if it has no other alternatives but to freeze up or crash.
>> >>>>>>
>> >>>>>> - Stefan
>> >>>>>>
>> >>>>>> On Mon, Mar 14, 2016 at 2:39 PM, Jonah Graham
>> >>>>>> <jonah@xxxxxxxxxxxxxxxx>
>> >>>>>> wrote:
>> >>>>>>> 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
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>> _______________________________________________
>> >>> 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
>> >
>> >
>>
>> _______________________________________________
>> 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
--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
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