>> First usage instance is the renaming of the mode-mouse option.
> Hmm. I am not sure I'm too keen on this approach.
a) Please elaborate.
b) Do you have a better idea to warrant config file backwards compability?
c) More opinions needed!
> What happens when/if
> mode-copy-mouse also needs renaming due to some other functionlity change?
In that case, one line needs to be appended to the renamed_options_table[]:
{ "mouse-copy-mode", "new-name", 0, 0 }
> I think rather than split this out, mode-mouse's semantics should probably
> change.
Like in the previous patch? That changes mode-mouse's semantics,
effectively breaking most existing config files.
> That's slightly less disruptive than providing replacement
> synonyms, and doesn't then require we augment the option-table code with
> bloat.
I don't quite understand this.
And how is a general mechanism to handle option/value string changes
gracefully bloat? Can you do it with less code?
#Regards!Marcel
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
