Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Patch for Asynchronous Auto-Save of file buffers
It seems kinda similar, but I'm not familiar with OCL or Xtext to know that.
I do agree that trying to fix a signification limitation of some layer (Xtext in this case) in a layer above (OCL?) usually works pretty badly, if at all.

I actually had a very similar problem here. Originally I wanted the Platform-Text changes to be very minimal: only to expose the minimal save code of the the text buffers as a method (ie, the part of the save code that could be executed outside the UI). Then, I could create an Auto-Save Manager externally (outside of Platform-Text). However it was soon apparent that doing it this way would have severe design flaws and unfixable concurrency bugs. A correct implementation of an asynchronous auto-save needs to have it built-in Platform-Text, the text buffer itself needs to know about it.

I don't know what's the deal with XText, but I noticed something peculiar in the stack-trace: XText is still using org.eclipse.ui.editors.text.FileDocumentProvider. I was wondering about this class quite recently, asked in Platform-UI ML what's the deal with that ( https://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg06902.html )
FileDocumentProvider actually duplicates a lot of the code in the AbstractFileBuffer subclasses, which is the code I had to rework for my contribution.

Now I wonder why XText is using FileDocumentProvider.


On 22 March 2016 at 18:32, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

Sounds promising.

A closely related bug/limitation that I (or rather AERI) has identified is the need for Editors to open on a worker thread. Basic editors open fine but as soon as editor loading gets more complicated e.g. a UML model, there is a serious UI freeze.

Is this sufficiently adjacent to your current achievement to be handled similarly ?

For the OCL Xtext editors I tried to cure the UI freeze with a worker threead but since I was layered on a lyayer on a layer, it all worked reather badly. Arguably the fix was worse than the problem.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=450481
https://bugs.eclipse.org/bugs/show_bug.cgi?id=471629
https://bugs.eclipse.org/bugs/show_bug.cgi?id=473825

Many other Bugzillas too.

    Regards

        Ed Willink


On 22/03/2016 18:11, Bruno Medeiros wrote:
Hi everybody.

Just to let people know - as this might also be of interest to other IDEs out there - I've submitted a Gerrit patch with my first draft of an asynchronous Auto-Save implementation I've been working on: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487653#c16

To recap from the last discussion on Auto-Save, I mentioned I was looking specifically at the ability to automatically save editor buffers *immediately* after the editor is modified. This in turn implied that such an auto-save needed to be done asynchronously: the UI-thread could not block on the save, as it currently does. The motivation for this was to be able to use external tools for on-the-fly compilation (in IDEs such as RustDT, Goclipse, DDT, etc). You can see an example demo this on-the-fly external compilation here:
https://twitter.com/brunodomedeiros/status/712327368157876225
(note that even though the editor shows the dirty sign, it is actually being saved to the disk automatically)

I'm hoping to get feedback on the patch, so that any issues can be addressed. It is a very complex patch, it changes a lot of core Eclipse code, and potentially breaks things (even if auto-save is not enabled), but there is no way this functionality could be implemented without big changes. I've made sure the current Platform Text tests pass on it, and also added my own tests, but for more than that, I need feedback and other people trying/testing it. The patch will also need some very simple follow-up changes to PlatformUI projects, but I want get started on validating the core implementation.

Cheers


_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev


_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev



--

Back to the top