[Geany-Devel] [geany] document: show informational doc message after first reload (#672)

[Matthew Brush]

On 15-10-31 02:08 AM, Thomas Martitz wrote:
> Am 31. Oktober 2015 02:52:01 MEZ, schrieb Matthew Brush <notifications at github.com>:
>>> [...] so unless there are actual problems I don't see an evidence to
>> keep the off default.
>>
>> I mentioned a number of issues with it in the mailing list thread
>> linked from the PR you made to disable it by default.
>>
>> I don't think we should cram this in just because of string freeze,
>> especially with the open issues, the UI issues, and that we will be
>> releasing again in a few months. I'm not opposed to the feature, I'm
>> opposed to the implementation (re-using an existing feature to do
>> something else, something unexpected of the existing feature, as well
>> as the infobar without a checkbox that can be hidden from the user
>> without ever seeing it).
>>
>> ---
>> Reply to this email directly or view it on GitHub:
>> https://github.com/geany/geany/pull/672#issuecomment-152685983
>
> Carrying this discussion to the ML.
>
> Can you elaborate on the issues you see?
>

Mostly the stuff I mentioned in the previous mailing list thread on this 
subject. The semantics of the Reload feature have changed and no longer 
does reload mean "drop everything about this file and load it again" it 
means, "store another copy of this file in RAM and load it again". I 
feel like it's not a good idea to re-use the File->Reload feature like 
this, and under not uncommon scenarios, Geany is no longer "lightweight" 
with respect to RAM usage.

To give an example, if someone opened a big log file and Reloads it, or 
if they have many files from version control open and switch branches, 
every reload will "leak" the size of each document worth of memory, 
making Geany use much more RAM than before. Scintilla's undo mechanism 
just isn't designed to efficiently handle the case of the entire 
document being replaced. The only workaround to regain all the memory 
wasted by Geany is to close all the files and start over.

I think the new preference is fine, I just don't think it ought to be 
enabled by default, or else it ought to be associated with a new (Edit, 
not File) action altogether as opposed to changing the semantics of the 
existing feature as everyone is used to.

> As to the UI. It's important that we get any UI for 1.26, therefore we had to manage before string freeze. [...]
>

Why is it important to rush it in before 1.26? One of the points of the 
accelerated release cycle is so that people would stop wanting to cram 
stuff in right before release. It's only a few months until next 
release, so there's no need to keep trying to rush in controversial stuff.

Cheers,
Matthew Brush