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

[Patrik Suzzi <psuzzi@xxxxxxxxx>]

If we remove explicit save, someone will start screaming loud.

On the other side, Doug is right: if you save often the History is unuseful.

In my case, I save often. and, when I'm using history, I get back a
file using a specific date/time, i.e. "version of yesterday before
12.00"
(most of times is unuseful, as I would need to get history at a
specific events on time)

If I start coding a new autosave mechanism, I would start on a
"parallel" track, by considering all the opened files "as a whole",
and considering "save points" as nodes of a graph, where:
when the user adds a new file, a new "save point" is created (a new
node on the graph)
when the user start editing an existing file, that is not "under
edit", you'll add a new "save point"
Then with some basics of graph theory, you could provide a good
graphic abstraction that is more relevant than the current "plain
history"

Why don't you start by adding a new save event, and let the user
choose by preferences whether he wants to use "the old save" or "the
new one" ?
For users who choose the new one, you could provide, better "graph"
history, and autosave.

What about it?

Kind Regards,

Patrik Suzzi
R&D Software Engineer.
https://about.me/psuzzi



On Wed, Nov 11, 2015 at 11:27 PM, Konstantin Komissarchik
<konstantin.komissarchik@xxxxxxxxxx> wrote:
> 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
>
>
>
>
>
>
> _______________________________________________
> 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