settings changes aren't saved until quit

[tim_k]

This has been a problem forever, but it's finally pushed me over the edge. Any changes made to the way SE behaves are not truly saved until you quit. Things like language options, toolbar settings, lists of recent files, even the current project are not saved. So when SE goes POOF, so do your changes. This is MADDENING! Can you PLEASE PLEASE PLEASE make the "OK" button in the options window write the changes to whatever files they belong in immediately!? And when I change active projects/workspaces - write it to wherever that belongs too!

I usually have SE open for days at a time. In that time, network connections come and go (I'm on a laptop), ftp sessions come and go, and workspaces get changed frequently. Sometimes SE crashes (more than I'd like), and when it does the least I lose is the current project and the recent files list. It gets worse from there in a hurry.

Please fix this.

-Tim

[Graeme]

Hi Tim
For configuration options there's a setting in tools -> options -> application options -> exit  - set "save config" to save immediately.  You can also call save-config at any time. 

For the stuff that goes in vrestore.slk, you can call save-window-config to get it updated.  If you want I could write you a macro to call save-window-config automatically once a minute or something.  I think it updates automatically sometimes but I don't know what triggers it.  For updating the workspace I think _workspace_save_state could probably be used.

I haven't had a crash for a while but I close slick probably several times a day.  I have auto save set to save every ten seconds just in case.  I could probably write you a macro to automatically close slick at 3am every day if you want, with a 30 second warning.

[tim_k]

Thanks Graeme! I never knew that was there. Now for the obvious questions - why isn't save immediately the default option? And under what circumstances would a user not want to save immediately, but save on quit with no interaction? I can see if there was some revert button in the options UI, so if you wanted to test things without committing you could get back with a button push. But as far as I can tell, there isn't a way to do that. So what am I missing?

I'd be interested to see the macro for saving the config periodically. I haven't done anything with timed macros, or manipulating the state of SE. All my macros have been file content manipulation.

 Thanks,

-Tim

[Clark]

The primary reason the config isn’t saved immediately is the state file. It’s very large (~12meg) and it sometimes has to be written. These days the OS disk cache is very good and many machines have SSDs. You’d be surprised how many SlickEdit customers have horrible machines and/or are forced to work on slow remote networks so their system administrator has less work to do.

UPDATED: Now that "def_XXX" macro variables and profile properties are stored in user.cfg.xml, the state file isn't saved quite so often. Macro/menu/dialog/icon changes require the state file to be saved. Also, if there is no local state file, the state file is saved. I use an undocument configuration where def_cfgfiles is set to 0 (this is intended for use only by the SlickEdit dev team) which seems to require that the state file be written all the time (this code could be improved).

[JeffB]

Couldn't there be an option so the user could choose whether to take the hit?  For me the two biggest annoyances around this is getting settings changed across several open projects - without having to shutdown all instances of vs - and losing the buffers that are open.  After so many years, I've accepted the first issue and manually manage any changes to settings, but losing the buffers when vs crashes is really annoying because I can't just restart it and pick back up where I left off.  After an active session of code browsing, search, and editing, a crash is a real set-back.

[Clark]

Hi Tim
For configuration options there's a setting in tools -> options -> application options -> exit  - set "save config" to save immediately.  You can also call save-config at any time. 

There is an option as Graeme mentioned.

[tim_k]

Hi Clark,

I thought you might chime in. I get the slow network problem, all too well. And the crappy machine too, though not presently, thankfully. I've already implemented Graeme's options suggestion, thanks. I had no clue that was there. Does the save-config command save windows & files too, or just the options?

[Clark]

Just the options. The save_window_config writes the vrestor.slk file. I don’t think there’s an option to save that on a timer. Auto save saves it but only if files are modified.

[Graeme]

Couldn't there be an option so the user could choose whether to take the hit?  For me the two biggest annoyances around this is getting settings changed across several open projects - without having to shutdown all instances of vs - and losing the buffers that are open.  After so many years, I've accepted the first issue and manually manage any changes to settings, but losing the buffers when vs crashes is really annoying because I can't just restart it and pick back up where I left off.  After an active session of code browsing, search, and editing, a crash is a real set-back.

Are you still using both Windows and Linux?  How often do you get crashes and are they on both Windows and Linux?  Lee recently mentioned here https://community.slickedit.com/index.php/topic,16122.msg61891.html#msg61891
that for Windows it could help to send in a mini-dump.  You can create a minidump with task manager.

Have you considered using multiple configuration folders?  I guess if each instance of slick has a different workspace open, then when you close that instance and re-open that workspace in another instance, all your previously open buffers get restored.  I'm not exactly sure what goes in vrestore.slk and what goes in the workspace file but if the config folder is shared between instances, they will be competing for what goes in vrestore.slk. 

Slick has undocumented commands save_named_state and load_named_state (they call save_window_config and the data goes in windowstate.slk in the config folder) that allow you to save "sessions".  In a couple of days I might try writing some code to save configuration and workspace info every one minute or so.  Would automatic saving of workspace info help you recover from a crash?  If you have multiple instances sharing vrestore.slk it may be that only one of them gets to update vrestore.slk.

If you had multiple configuration folders, you could use options export/ import and an options group that maybe excluded tool windows and toolwindow options.  I suspect the importing could be partly automated if you had a master configuration folder that other instances monitored.

[JeffB]

99% work is using the Linux version.  Crashes lately are frequent when tagging.  My workspaces typically have 1-2 projects and 100k-150k files.  The other day it took 5-6 tries restarting vs to get the tag file to finish.  This wasn't typical 6 months ago...not sure what changed.  But those crashes are generally not a huge problem for config/buffers saving because I just start vs and let it build the tag file.  If it crashes, the worst is just that if I don't notice it to restart vs, it may take a long time to eventually get the tags built.

My issue with configuration is more with concurrent instances of vs.  I want them all to have the same configuration, and if I change a setting, I want it to apply to all of them.  What I'd really like is a single cloud configuration DB and all instances (home, work, Linux, Windows..) constantly stay up-to-date with that version.  If I find the need to change a setting, I shutdown all instances of vs (typically, I have 3-5 open) but one, make the setting change, shutdown the last instance (I could do "save-config"), and then start them all back again.  I've been doing that for years, swear it sucks every time I do it, and just move on.  So I really want don't want multiple configuration folders.

General crashes are somewhat random, and really not that frequent.  Infrequent enough where I don't bother saving my config/buffer state often, so when they do happen, I typically lose my recent browsing/work history (w/regards to files I was browsing).  Since this is infrequent, I'd say it is much more of an annoyance than a problem; however, auto-saving the current file list just seems like such an easy thing to do, when it happens I'm always baffled why I have to run into this problem at all.

[Graeme]

Attached is a slick C file that does regular saves of the workspace state file (*.vpwhist) and vrestore.slk.  If you have multiple instances of slick open a lot then you might want to comment out the #define SAVE_VRESTORE_SLK so that you don't have more than one instance of slick trying to update vrestore.slk.

The _cbsave_xupdate_state function immediately saves the workpsace history file and also vrestore.slk.  Any function starting with _cbsave_ is automatically called whenever any buffer is saved.  This might be all you need in which case you can modify the code to not use the timer callback mechanism.  If you have an SSD you probably won't notice the extra saves being done.  If the edit cursor hasn't moved from where it was when the last save was done, the workspace state file won't get re-written.

Code: [Select]

#include "slick.sh"


#pragma option(strictsemicolons,on)
#pragma option(strict,on)
#pragma option(autodecl,off)
#pragma option(strictparens,on)


#define SAVE_VRESTORE_SLK

static int xline, xcol;
static _str xbuf_name;
static int count_secs;
static boolean save_needed;
static int count_times;
static int xupdate_state_timer_handle;
static boolean save_now;

static void xupdate_state_timer_callback()
{
   if (!_use_timers || xupdate_state_timer_handle < 0)
      return;

   if ( _no_child_windows() )
      return;

   if ((_mdi.p_child.p_line == xline) && (_mdi.p_child.p_buf_name == xbuf_name) && (_mdi.p_child.p_col == xcol))
   {
      if (save_now  ||  (++count_secs > 2) ) {
         count_secs = 0;
         if ( save_now || save_needed )
         {
            save_needed = false;
            save_now = false;
            // see _srg_workspace
            _workspace_save_state(!def_prompt_unnamed_save_all/*_workspace*/ && (def_restore_flags & RF_PROJECTFILES));
         }

         #ifdef SAVE_VRESTORE_SLK
         if ( ++count_times > 4 ) {
            count_times = 0;
            save_window_config();
         }
         #endif

      }
   }
   count_secs = 0;
   xline = _mdi.p_child.p_line;
   xcol = _mdi.p_child.p_col;
   xbuf_name = _mdi.p_child.p_buf_name;
   save_needed = true;
}

void _switchbuf_xupdate_state()
{
   save_now = true;
   xline = _mdi.p_child.p_line;
   xcol = _mdi.p_child.p_col;
   xbuf_name = _mdi.p_child.p_buf_name;
}


// _cbsave_xupdate_state is called automatically whenever any buffer is saved
void _cbsave_xupdate_state()
{
   _workspace_save_state(!def_prompt_unnamed_save_all/*_workspace*/ && (def_restore_flags & RF_PROJECTFILES));
   save_window_config();
}



void _buffer_add_xupdate_state()
{
   _switchbuf_xupdate_state();
}


void _on_load_module_xupdate_state(_str module_name)
{
   _str sm = strip(module_name, "B", "\'\"");
   if (strip_filename(sm, 'PD') == 'xupdate_state.e') {
      _kill_timer(xupdate_state_timer_handle);
      xupdate_state_timer_handle = -1;
   }
}


definit() {
   if (arg(1) == 'L') {
      _kill_timer(xupdate_state_timer_handle);
   }
   xupdate_state_timer_handle = _set_timer(1000, xupdate_state_timer_callback);
}



[JeffB]

Thanks for the macro Graeme.  I tried it, but it didn't work.  I don't have time to debug it right now, but here's the use-case if you are interested:
Start vs project (ensure macro is loaded via "List user-loadable macros") with about 25 files opened. Close a couple of files shown in the "Files toolwindows-Buffers Tab" list.  Wait a 5-10 sec. "kill -9 <vs pid>".  Re-open project, the files I closed are still listed in the Buffers list.

Thanks,
Jeff

[Graeme]

ok, I've added a _cbquit2_ function - it should get called when a buffer is closed.
Thanks for the report.

[JeffB]

Thanks, Graeme..no joy. The files in the list of buffers I close before killing vs still come back in the list.

[Graeme]

oh, ok.  I found a slight logic error; aka bug.  I didn't really test it properly, sorry.  Here's another version.  This time I've added some debug code - if it still doesn't work you could uncomment #define DEBUG  -   it results in some output to the slick debug window when a save is done.  If a buffer is closed you should see "xupdate cbquit2".  If a buffer is saved you should see "xupdate cbsave". If the current cursor line or column changes you should see "xupdate timer save" 3 seconds after the cursor stops moving.  Actually if a buffer is closed you see all three messages but too many is better than too few, maybe.

[Edit] There might be a problem with this macro.  Use with caution.
https://community.slickedit.com/index.php/topic,16155.msg62106.html#msg62106