Feature request: the ability to turn on/off autosave

[Bruno Bord]

The autosave feature is nice, but I'd like to be able to turn it on/off through the parameters dialog. Here's why:

I'm a web developer, and my framework of choice is Django. When I'm hacking on Django, I often use the internal development server, which reloads the project every time a python script has been modified. The problem with autosave is that it often records change while I'm typing something, and it occurs quite frequently that it's when I'm in a middle of a statement. It results of a syntax error, of course.

Here's what happens:
* I'm typing a "if" statement, for example, but I didn't type any instruction in the indented block
* Scribes saves the file
* The dev server detects a file has been modified, reloads the scripts,
* There's a syntax error, the dev server stops.

Of course, I can still go on typing my code until it's correct, but i *have* to manually relaunch the dev server. If autosave was "off", I could make a bunch of edits, see if it's okay, and then manually save them ; the whole scripts would have been automatically reloaded by the dev server without a manual intervention.

Hence, my feature request.
Regards,

[Bruno Bord (brunobord)]

this feature request is a few months old now, so I'm pinging it, just to know. At least, what would be nice would be to see if this is a "wontfix" or if it's targeted for a future released or not.

many thanks

[Mystilleef (mystilleef)]

An option to disable automatic saving. Sounds like a disaster to me. But I don't want to close the bug until I've thought through it carefully. I'm aversed to providing options and your usage scenario sounds like a corner case specific to django development. I don't see why I should modify Scribes behavior to satisfy django. But again let me think things through.

[Jebadiah Moore (jebdm)]

A possible quickfix would be to autosave to a different location than the original file (while editing to asdf.txt, autosave to ~asdf.txt). You'd have to make sure to cleanup on close though, it's obnoxious when programs leave a trail of backup/temporary files behind.

[Bruno Bord (brunobord)]

I may be wrong, but I'm almost sure that some languages are able to load modules "live" (or reload). I think Erlang allows it, hence you may have running programs that would be saved in a "wrong state".

Jebediah's comment is also an alternative. Pyroom project (text editor) behaves exaclty like this, autosaving a temporary file on a different location, and when it's a manual save, it's saved on the actual location.

[Camilo Nova (camilo-nova)]

I think you can run django development server using --noreload option, this is used by NetBeans, Eclipse, or other editors to prevent this behavior, i think scribes is great and autosaving worths a lot.

[Lauri Kainulainen (luopio)]

Another django developer here supporting the idea of a switch button. Not entirely against the tmp-file approach either as long as the files are cleaned afterwards.

[Bruno Bord (brunobord)]

In fact, Django-dev-server-plus-autosave is not the only use case I have in mind.
When Scribes was less stable than it is now, I've often been confronted to this use case :

* open large file for refactoring.
* cut-paste bits from file1 to file2 to have a more modular program
* cut...
* autosave...
* SEGFAULT

now your file1 has been saved in a "not-so-stable" version, and file2 has been saved without the content of your clipboard. You can waste a lot of time trying to rebuild what's has been sent to hyperspace by the segfault.
If autosave is "off", your file1's content is not lost and you can start over again.

It has been one of the reason why I've stopped using Scribes some time ago. Now that's it's a bit more stable, we're less exposed to this kind of bugs, but I've always been very reluctant to use editors / word processors with this autosave feature for that reason.

[Mystilleef (mystilleef)]

There are few things that can be done to improve the saving
experience especially in exceptional situations such as
segfaults and crashes. Like the ability to revert a document
back to an earlier state in its history. It's something I
plan to work on for 0.5.

The benefits of autosave outweigh the drawbacks in my
opinion. Django's server should attempt to restart itself
a couple of times before finally giving up. I don't see why
Scribes should be designed around a corner case of another
application.

[Bruno Bord (brunobord)]

I'm sorry if I looked too controversial... ;op

Well I guess it's a matter of trust. I do not trust autosave, since it replaces content without my consent. And Django is not the key topic here, even if I started using its behaviour as an example. (my fault, then)

IMHO, save must occur when user wants it, exactly like when you quit the application, by asking the user if he/she wants to save the file or not. The user has to make a choice, to save or cancel save.

With autosave, it's the program that makes arbitrary choices rather than the user, and that's what I said: it does things without my explicit consent. Thus I suggested the ability to turn on/off autosave.

http://library.gnome.org/devel/hig-book/2.30/principles-user-control.html.en

Hope this helps you understand my opinion. For now, I'm fine with this behaviour as long as Scribes doesn't crush things irreversibly.

have a nice day, and keep Scribes rocking!

[Mystilleef (mystilleef)]

Your operating system performs many destructive (i/o)
operations without your consent. :-)

Manually saving is an unnecessary activity. Edits should
always be in a saved state. Always! If users don't care for
their edits, they are at liberty to deliberately "destroy"
them themselves.

What we can't have is users loosing documents because they
forget to save. Or because the cat yanked the power cord.
Or the battery died suddenly. Or as in the case of Scribes
you described above, a segfault.

What we can't have is users wasting their time of trivial
actions when that time could be spent creating content.

Scribes mantra has always been to automate trivial and
repetitive actions so that the user can focus on what really
matters, CONTENT creation! That's the whole experience
Scribes is designed around.

You can launch a Scribes window type an essay on the rise of
Japan as an international economic player, close the
document and not have to implore Scribes to do anything.
Launch, type, close. Seriously, do it. That experience is
literally unavailable in any other editor I know. This
experience should be the norm!

The idea that one has to baby sit applications is a relic of
a misguided past. Today, baby sitting applications is
considered terrible user experience design.

Why should you or I waste our time worrying about saving
our documents when the application's duty is to ensure that
our work is always safe?

We shouldn't.

I have to respectfully disagree with you on autosaving.

[Bruno Bord (brunobord)]

One thing's sure: you're very clever and very persuasive...

Sincerly yours,

[Mystilleef (mystilleef)]

You're very kind. Thank You.

[Kenneth Malac (kennethm777-deactivatedaccount)]

I think the ability to put autosave off would be nice. :)

[Javier Lorenzana (skqr)]

Here's an thought; I'll be willing to bet that the feature can be implemented with less characters of code than the amount used here to argument in its favour.

Any Django developer in here is eager enough to just code it?

One of the core principles of Django is DRY. I like DIY as well.

Launchpad/Bazaar are awesome, and there aren't nearly enough Scribes branches out there.

[Mystilleef (mystilleef)]

For those who want to disable automatic saving in the code
base, it's simple. Go to the following module

$prefix/scribes/SCRIBES/SaveSystem/Manager.py

In build 577 comment out line 28 and 29 like so:

  #from AutomaticSaver import Saver
  #Saver(self, editor)

Once that is commented out, automatic saving will be
disabled.

[apotonick (apotonick)]

One note, again. The autosave is also problematic with some remote mounted filesystems under Linux, not only for Django users ;-)

I encountered strange file states when i had a slow connection, tried to analyze it but no success. Simplest solution was using another editor, so I'd vote for a "Turn-off autosave", since I love scribes.

Nick

[Antony Bobrov (bobrov)]

I have write plugin which disables auto saver.

http://github.com/baverman/scribes-goodies/blob/master/plugins/PluginDisableAutoSave.py

Enjoy!

[Ian van der Neut (ivdneut)]

To add some fuel to this debate. A friend of mine uses TextMate on OS-X. If I remember correctly (not verified) he has it configured it to save automatically when the editor window loses focus. Perhaps this would be an idea for scribes?

[Mystilleef (mystilleef)]

Ian,

Scribes does that too.

[Ian van der Neut (ivdneut)]

Ah, ok... I thought it was some sort of timer. Or is does it do both?

[Ian van der Neut (ivdneut)]

Anwering my own question, autosave seems to happen even when not losing focus. Perhaps just this feature could be turned off in a configuration dialog? It doesn't bother me personally though.

[Mystilleef (mystilleef)]

Ian,

It does both.

I've described ways to disable this above.

[encompass (encompass)]

Autosave is nice when close it and when it's local. But I work with a lot of remote files. I am simply decided to use another editor in place of it because I get too many writes to the file. And saving when the window loses focus is bad as many users use hover to focus on a window. (Common setting in gnome.)

[Gerry (gerry-spm+lnchpad)]

> Why should you or I waste our time worrying about saving our documents when the application's duty is to ensure that our work is always safe?

Because saving in the middle of an edit can break stuff. If somebody is doing a basic edit on a script or config file or whatever on something that others are using, those users will see each of those unintended mid edit autosaves as a program/server break. In cases such as these and others Scribes only adds pain.

Ok, so an alternative that might keep most of the functionality you want, while not inflicting too much pain. If a user starts a new file then autosaves are no problem, however if they are editing a file then autosaves should go to a temp file as #3 suggested, and only on closing scribes is this file then overwritten. This idea could be improved upon further with the addition of the version control you mentioned in #8.

[Mystilleef (mystilleef)]

@Gerry

Those are extremely rare corner cases. Saving config files or scripts or whatever should _NOT_ break anything and in practice rarely ever does.

And if it does break an application then a bug report should be filed for the application in question. WELL DESIGNED applications will not run a broken config file or script they'll revert to a default sane value and spit an error to STDERR. If they don't the application is broken, not Scribes. Scribes merely exposed a bug. There are well established ways to handle the very common problems of misconfiguration, especially for applications that listen for configuration changes.

Bad user input should NEVER break an application. This is software engineering 101.

However, don't listen to me. I'm old and boring. If you really want to disable saving, there are tweaks and patches in this very thread that will help you with that.

[jcapinc (jeffs-linux)]

I would like to submit that breaking packages mid-edit is not a corner case but actually happens all the time. I have both problems.

I work on live websites all the time (and don't criticise, it is not my choice and I am migrating my team away from that), and I would like to be able to make sweeping edits and save once to experience as little downtime as possible.

As I am working on live websites, I am also working on a netwark. Often I get "could not save errors" in the middle of editing, completely breaking my concentration and what I am trying to do.

Live saving is good. No question - but there are instances where it is detramental, and there are enough of them that it merits configuration. I understand the desire to limit configuration as much as possible to give a simplified user experiance. But one little checkbox in the advanced configuration would make everyone happy and would not be extrenious or difficult to code.

I will do it myself for you if it would influence your decision.

[Mystilleef (mystilleef)]

If you send a patch that works. I'll accept it.

[Joe Bob (fishes2004)]

All Crisis's aside, I'd like to see the autosave work with the backup file simply for a much simpler reason. I open tons of blank instances in order to paste some "temporary" data, be it code or plain text. I simply close the document when I don't need this data anymore (when working with code this can be after a few secs or mins) and I find that I'm spending much more time than I'd like deleting tons and tons of these files that are autosaving. Now obviously the autosave is a good feature in case of crashes but I think the backup save file being destroyed on manual save or exist is the best solution to all the problems mentioned above as well as mine.

By the way, Koodos to Mystilleef and Scribes, thanks for the great editor and keep up the good work!

[Joe Bob (fishes2004)]

Hmm, I didn't see a way to "edit" the post above but it was suppose to read:
"on manual save or exit"

[Nicolas (mwksaz-deactivatedaccount)]

What about this (see attachment)? I can write the patch if nobody else wants to do it.

[Timmie (timmie)]

Please include an option for changing default save directory.

See also:
Default Document Save Directory
https://answers.launchpad.net/scribes/+question/151868

[Heimen Stoffels (vistaus)]

I commented out the mentioned lines but it still autosaves. Meh, that is really yuck. I mean, when editing a file it's okay. But when creating a file I don't want it to save it to some random name (eg. if I type "this is a test" then that becomes the name of the file).

Too bad, because aside from that i really like Scribes (especially with the Cobalt theme).