text editor with auto-save feature

Tom Metro tmetro-blu-5a1Jt6qxUNc at public.gmane.org
Fri May 22 02:58:14 EDT 2009


Greg Rundlett wrote:
> Have you tried Quanta?

No, hadn't heard of it.


> ...it's suffering from very slow development to get onto the KDE4
> bandwagon.

As I'm using GNOME, that doesn't concern me, but as packaged for Ubuntu, 
Quanta depends or recommends CVS, which seems a bit antiquated. Looks 
like it recommends cervisia, which is apparently a CVS front-end. I 
guess this is a side effect of the recent Ubuntu policy change where 
they automatically install recommended packages. I didn't think that 
change would bother me, but now I'm having second thoughts...

Quanta is pretty insistent about its recommended packages. I removed 
cervisia and on startup it put up a dialog warning me that it was 
absent, and also complaining that KImageMapEditor (oddly not in the 
recommended list) was absent. So I guess Ubuntu packaging doesn't get 
all the blame for being too inclusive.


> Still, it has an auto-save feature.  I wasn't able to check if it
> does it on an unnamed buffer - but I'm 90% sure that it does.

Easy enough to test. Lets see...I started it, opened a couple of 
buffers, typed some text in each, waited a few minutes, and then killed 
the process. On restart it prompted me with a dialog asking if I wanted 
to restore /Untitled1 and /Untitled2. I said yes, and it worked.

Apparently the files are stored in ~/.kde/share/apps/quanta/backups/, 
which gets disclosed in the title bar for the restored files.

I took a look at that directory after the restore, and it was empty. 
Good that it cleans up after itself, but...killing the process and 
restarting it resulted in the files being lost. That seems like a bug.

I created another new buffer with some text and watched the backup 
directory. It took a few minutes for a file to appear. I didn't see any 
obvious setting in the preferences to control the autosave frequency.


I'll play around with Quanta some more, but it is striving to be a web 
developer's IDE, which gives it a cluttered UI. I'm looking for a fairly 
light weight general purpose editor.


Kevin D. Clark wrote:
> How about:
> xemacs -vanilla /tmp/unamed-file-created-on-`date '+%Y-%m-%d-%H-%M-%S'`

Saving the file in /tmp would be a bad idea if you want it to survive a 
system crash (reboot), but it's not a bad idea in general. This kind of 
commend could be executed from a desktop icon, and should work with just 
about any editor (providing it has traditional autosave functionality). 
You just need to train yourself to use the icon instead of File|New when 
creating new files.

Where it falls short is in the area of housekeeping. A properly 
implemented feature integrated into the editor will automatically get 
rid of the temporary file when the unnamed buffer gets saved under a 
real name. Here you'd have to periodically sift through the temp files 
manually, or come up with some heuristics for identifying what's orphaned.


Jerry Feldman wrote:
> [In xemacs and GNU emacs] if you want to create a buffer ^x^f lets
> you...create a buffer with a file name. And at that point, a save file is
> created in the current directory.
> ...if you start vi (eg. vim) and start editing, a .swp file is
> created, since there is no file name associated.

Thanks for the tip, but I'm trying to steer clear of the stone-age 
editors for this need. :-)

Though you have to give them credit for having a feature that is sadly 
absent from most modern GUI editors.

Crashes are inevitable. Seems silly that we don't design most software 
to anticipate that and automatically guard against it.

Someone ought to create a Linux desktop centered around the idea of 
crash proofing and state preservation. It wouldn't have to be a whole 
new desktop. It could be a patched GNOME, KDE, or whatever, and a suite 
of applications that have all been tested that they comply.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/





More information about the Discuss mailing list