From: Paul Mackerras Date: Thu, 30 Oct 2014 09:55:13 GMT Subject: Re: [PATCH v2 2/3] gitk: write only changed configuration variables Message-ID: <20141030095513.GE16472@iris.ozlabs.ibm.com> In-Reply-To: <1410726959-20353-3-git-send-email-max@max630.net> On Sun, Sep 14, 2014 at 11:35:58PM +0300, Max Kirillov wrote: > When gitk contains some changed parameter, and there is existing > instance of gitk where the parameter is still old, it is reverted to > that old value when the instance exits. > > Instead, store a parameter in config only it is has been modified in the > exiting instance. Otherwise, preserve the value which currently is in > file. This allows editing the configuration when several instances are > running, and don't get rollback of the modification if some other > instance where the configuration was not edited is closed last. > > Since trace(3tcl) can send bogus events, doublecheck if the value has > really been changed, but once it is marked as changed, do not reset it > back to unchanged ever, because if user has restored the original value, > it's the decision which should be stored as well as modified value. > > Treat view list especially: instead of rewriting the whole list, merge > individual views. Place old and updated views at their older placed, add > new ones to the end of list. > > Do not merge geometry values. They are almost always changing because > user moves and resises windows, and there is no way to find which one of > the geometries is most desired. Just overwrite them unconditionally, > like earlier. > > Signed-off-by: Max Kirillov I like the idea here but the implementation seems a bit more complicated than it needs to be. It seems to me that we need the trace only for the non-array configuration variables; the array case is only for the view definitions, and I think we could just set the changed flag for a view explicitly in [newviewok]. That would simplify things quite a bit. I'm also not convinced we need all the uses of upvar. Why do we need to use upvar to rename viewname, viewfiles etc. to current_viewname, etc.? If you're concerned about what might possibly be in the .gitk when you source it, perhaps doing the source inside a namespace would be a cleaner approach? Paul.