git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Paul Mackerras <paulus@samba.org>
Date
Oct 30, 2014, 09:55 UTC
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:
Show 25 quoted lines
> 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.
Previous: Max KirillovNext: Max Kirillov
Message 5 of 7 in “gitk: save only changed configuration on exit”
  1. 0/3 gitk: save only changed configuration on exitMax Kirillov, Sep 14, 2014
  2. 1/3 gitk refactor: remove boilerplate for configuration variablesMax Kirillov, Sep 14, 2014
  3. Paul MackerrasOct 30, 2014
  4. 2/3 gitk: write only changed configuration variablesMax Kirillov, Sep 14, 2014
  5. Paul MackerrasOct 30, 2014
  6. Max KirillovOct 30, 2014
  7. 3/3 gitk: synchronize config writeMax Kirillov, Sep 14, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.