[Geany-devel] Separating session file lists from config (again)
mbrush at xxxxx
Mon Oct 1 22:26:45 UTC 2012
On 12-10-01 03:05 PM, Colomban Wendling wrote:
> Le 01/10/2012 23:15, Matthew Brush a écrit :
>> On 12-10-01 07:43 AM, Colomban Wendling wrote:
>>> Le 10/09/2012 06:36, Lex Trotman a écrit :
>>>> Hi All,
>>>> Its about that time of year when we have our annual discussion on
>>>> separating session data from config/project data :)
>>>> By session data I mean the list of currently open files and MRU list.
>>>> The advantages (that I can see):
>>>> 1. Save config/project as its changed and not rushed at quit time (and
>>>> the quit save doesn't happen in the absence of a working, portable,
>>>> session management capability)
>>> TBH until proper multi-instance configuration sharing, I don't see
>>> what's so great with "not rushing at quit time" since we already also
>>> save one pref/project-prefs apply.
>> Open your favourite project in Geany and open a specific set of files
>> you need to work on a task, get the order of the files just right,
>> adjust the Geany window position and size and then get your find dialogs
>> positioned just perfect on your second screen. Now unplug your computer.
>> You will see :)
>> For me it takes more time to get Geany back in order (finding project
>> file since it's not saved in the recent project list, finding open
>> files related to current task, since they aren't saved in recent files
>> list, etc.) than it does to restart the whole computer.
>> P.S. My workaround (because my computer crashes a lot due to Flash) is
>> to get everything set up how I want for the current task, and then to
>> close Geany normally to force saving of all settings and then to reopen
>> it :)
> As I read Lex's sentence, he spoke about settings, not open files. And
> anyway, I don't see what separating file list from the rest of the
> config change in that matter. It doesn't magically brings
> immediate/periodical saving of the file list, and we can very well save
> everything *including the file list* without that. So I don't see why
> it's an argument in favor (or against) $subject.
It's an argument in favour of "not rushing at quite time" (ie.
periodically saving the .conf file(s) instead of only on closing) since
you said you didn't see what was so great about it.
More information about the Devel