[squeak-dev] The Trunk: Tools-cmm.823.mcz

Eliot Miranda eliot.miranda at gmail.com
Tue Jun 26 20:28:31 UTC 2018


Hi Chris,

> On Jun 25, 2018, at 4:46 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> Hi Eliot,
> 
> Your hack is safe and still working as implemented.  My change is only
> to be restore the legacy behavior with:
> 
>   Debugger rememberExtent: false
> 
> because, as I reported to you days ago, it does not work as designed
> and, as a result, has made life in the IDE unpleasant.

But I do not think it does.  Because you’re using SavedExtent for both the flag that enables the facility and the value, nilling SavedExtent, or leaving it nil when the class var gets added, the facility is hence off by default.  That is a change from my code which enabled the facility by default.  A better approach would be to set SavedExtent to a special value, such as -1 at -1, to turn off the facility, or use a distinct flag.

> 
>> I don't get this.  You've added this but I don't see it sent anywhere.
> 
> Sent by the user / developer.  It's a "undocumented preference" for
> now until some fix / solution acceptable to everyone can be found.
> 
>> And what of the default 33%@95% height?  What if the display is  2560 at 1440 ?
>> Isn't there some sensible maximum here?
> 
> Does it matter?  It's just for the first open, after that it'll
> remember whatever you sized it to...
> 
>> I wish instead someone would extend RealEstateManager so that this all but
>> essential feature is available to all system tool windows.  Yes, things need
>> resetting or updating on display extent change (for example, scan,ling saved
>> extents by the change in display extent).
> 
> I took a brief look and considered a "mini-project" to take your idea
> further, but the development time required combined with the risk of
> community rejection and low reward payback made such a consideration
> totally unteneable.
> 
>> ... snip
>> 
>> and the below is broken.  If SavedExtent is nil, it won't remember anything.  Look, is remembering the last open extent of the debugger a huge improvement or not?  I find it a huge improvement.  You've just negated that.
> 
> It isn't broken.  I apologize if my commit notes aren't clear, I tried
> to make them so.  I also considered writing you a reassuring note, but
> after considering that you might ignore it, too, I didn't bother.
> 
>> Look, is remembering the last open extent of the debugger a huge improvement or not?  I find it a huge improvement.  You've just negated that.  You consistently protest/alter/reject my contributions.  It's getting tedious.
> 
> Eliot, the timestamp of the Version in trunk is within 5 minutes of
> the method timestamps.  I Clearly it was not tested, because it
> doesn't work at all, but it's still there as you put it in.  After you
> ignored my initial inquiry, the only thing I could do was make this
> bypass, after which I also wrote you a long private email, which you
> also ignored.
> 
> I do not wish for you to feel working with me is tedious, but I
> extended way beyond normal because of who you are.  I cannot force you
> to interact with me, all I can do is try to keep things peaceful by
> fixing the problem without blowing up your change.  Please spend at
> least that much time looking at my change, reading my commit notes, my
> prior emails to you before getting upset.
> 
> Best,
>  Chris
> 


More information about the Squeak-dev mailing list