Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Implicit editor saving and Auto Building in Eclipse

The length of history should be something that the user can configure. Typically you’d limit by some combination of frame age and frame count. I am not sure what the value proposition for limiting based on validation state would be. Consider that all previous states and the new states may have validation errors (you are working on a length task from scratch) or that an editor may have validation errors that are ignored by the user because they represent a deficiency in tooling or configuration rather than something that would present a problem at runtime.

 

- Konstantin

 


From: Maarten Meijer
Sent: Wednesday, November 11, 2015 2:11 PM
To: Discussions about the IDE
Subject: Re: [ide-dev] Implicit editor saving and Auto Building in Eclipse

 

 

Should a persisted undo stack be able to rewind to previous inconsistent states, ie non compiling with errors or warnings?

I think not. only the last saved state should possibly be inconsistent.

 

Kind regards/vriendelijke groeten

 

Maarten Meijer

+31 6 22451360

Sent from iPhone

 

> Op 11 nov. 2015 om 23:00 heeft Torkild Ulvøy Resheim <torkildr@xxxxxxxxx> het volgende geschreven:

>

> Hi all,

>

> I also think adding a persisted undo stack to automatic saves is the way to go. If this could be implemented so that a diff would work in a sensible way, one could get rid of the local history. Simply rewinding using “undo” is not an option. I and probably others are quite conscious about when we save and would like to keep the prospect of picking parts of saved code using the diff editor.

>

> So yes, +1 to what Konstantin writes.

>

> I’m not so sure that everyone will be happy about such a change though. It holds the promise of altering workflow quite a bit. Maybe not in a good way for everyone.

>

> Best regards,

> Torkild

>> 11. nov. 2015 kl. 22.28 skrev Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>:

>>

>> It’s all one big issue, though. People will be inclined to trust auto-save if they feel that it will not inadvertedly harm them. The way to show them that it will not is through a robust system that allows them to backtrack past the saves. The undo stack is part of the answer, but it doesn’t survive past Eclipse (editor?) shutdown, so it’s not a complete answer. An “ideal” solution would be a persisted undo stack that you can rewind to an arbitrary point (something other than pressing CTRL+Z a number of times)  and diff doc state at arbitrary stack frames. That would eliminate the need for local history as currently implemented and would not require answering the question of when to take a snapshot in the auto-save environment.

>>

>> - Konstantin

>>

>>

>>

>> From: Doug Schaefer

>> Sent: Wednesday, November 11, 2015 12:55 PM

>> To: Konstantin Komissarchik;Discussions about the IDE

>> Subject: Re: [ide-dev] Implicit editor saving and Auto Building in Eclipse

>>

>>

>> I think that raises a whole different issue on whether auto-save is a good thing or not, independent of local history. If that’s a big issue for you and you don’t trust it, you should probably turn it off.

>>

>> Mind you, I’ve trained myself to hit the save keys after every few keystrokes anyway so I essentially self auto-saving. And it’s made local history pretty useless to me since saves happen so often. But each to their own.

>>

>> :D

>>

>> From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>

>> Date: Wednesday, November 11, 2015 at 3:44 PM

>> To: Doug Schaefer <dschaefer@xxxxxxx>, Discussions about the IDE <ide-dev@xxxxxxxxxxx>

>> Subject: RE: [ide-dev] Implicit editor saving and Auto Building in Eclipse

>>

>> I would think that local history is more critical with auto-save in the picture as you now run the risk of unintentionally saving something that wasn’t meant to be saved.

>>

>> - Konstantin

>>

>>

>>

>> From: Doug Schaefer

>> Sent: Wednesday, November 11, 2015 12:28 PM

>> To: Discussions about the IDE

>> Subject: Re: [ide-dev] Implicit editor saving and Auto Building in Eclipse

>>

>>

>> From: <ide-dev-bounces@xxxxxxxxxxx> on behalf of Eric Moffatt <emoffatt@xxxxxxxxxx>

>> Reply-To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>

>> Date: Wednesday, November 11, 2015 at 3:22 PM

>> To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>

>> Subject: Re: [ide-dev] Implicit editor saving and Auto Building in Eclipse

>>

>> Bruno, nice to hear this, I'm currently working with Orion and one of the things I like is 'auto-save' which I leave on all the time...

>>

>> Just a heads up that when looking at implementing this be aware that you are going to have to come up with a strategy that can auto-save *without* losing the ability to refer to / compare changes in the local files (also quite useful). Not sure what the answer is but I don't think simply spamming the current mechanism with tons of saves will be sufficient...

>> It’s worth opening up that question. How useful is local history? It has it’s moments I guess. But if it gets in the way...

>>

>>

>> Regards,

>> Eric

>>

>>

>> <graycol.gif>Bruno Medeiros ---11/11/2015 09:32:15 AM---I was considering participating in the FEEP proposal "Implement Auto-Save of Editors" (

>>

>> From: Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx>

>> To: ide-dev@xxxxxxxxxxx

>> Date: 11/11/2015 09:32 AM

>> Subject: [ide-dev] Implicit editor saving and Auto Building in Eclipse

>> Sent by: ide-dev-bounces@xxxxxxxxxxx

>> <4968C35CC19A41258C2E58DFE9497F9D.png>

>>

>>

>>

>> I was considering participating in the FEEP proposal "Implement Auto-Save of Editors" ( https://projects.eclipse.org/development_effort/implement-auto-save-editors ), as this is something I was already contemplating contributing to.

>>

>> However, my interest in this feature is not simply to have an auto-backup of dirty editors, I'd like to be able to entirely remove the concept of explicitly-saving (and of dirty editors as a consequence), but instead implicitly save editors to their original files, not to a temporary copy somewhere else. IntelliJ follows this behavior.

>>

>> So, I've originally posted about this here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076#c89 , but I'd like to bring up this issue with a wider audience that just those listening to the bug. Especially with regards to how this relates to Auto Building, and the question about the usefulness of Auto Building (please see that bugzilla comment).

>>

>> --

>> Bruno Medeiros

>> https://twitter.com/brunodomedeiros_______________________________________________

>> 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

>>

>> ---------------------------------------------------------------------

>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

>>

>>

>> ---------------------------------------------------------------------

>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

>>

>>

>> <graycol.gif><4968C35CC19A41258C2E58DFE9497F9D.png>_______________________________________________

>> 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

_______________________________________________

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