Re: [PATCH v2 2/3] gitk: write only changed configuration variables

[Paul Mackerras <paulus@samba.org>]

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 <max@max630.net>

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.