... > isn't going to happen now, since I'm about > to cut a release for 1.8. Uhm ok.
> But adding in your changes now -- even by delaying 1.8 by a few days -- > simply is not an option. Because? > We would need much more time to ensure new code > isn't going to introduce bugs Much more time? The code is simple. > I don't want [..] > I don't want [..] That's the kind of objective reasoning noone can object to. >something which could have waited. Who decides? > So no. You're going to have to wait. > (and thanks for hijacking this thread, BTW) I didn't mean to spoil any parties, I just really think the release should not be done without at least the rename - if there's no auto-migration logic in place. Which I also sent a patch in for that was rejected because of either "we don't do renames, ever" or "we never guarantee backwards-compatibility" >> - renaming mode-mouse to mouse-copy-mode (multiple incidents of >> confusion because of the too-general name) > > Why is the name changing anyway? Point me at a thread I can go back and > read again, by all means. There is no thread. May I refer to my reply to Nic's inquiry couple of minutes ago. > To do this "properly", we'd have to maintain a > separate deprecation table to perform old->new command-name lookups to > ensure people's configurations do not break. I did sent that in before. > This adds code-bloat for no > real reason, and whilst I can understand there's a few naming-nits with some > commands, we're by-and-large stuck with what we have. So this is a remedy we don't need because it can handle a situation we actually have. I see. I don't like being stuck, do you? >> - pane-active-border-mark option to indicate current pane (as an option >> to the horrible half-line indicator that was committed 12 days ago) > > Opinions notwithstanding, it seems as though this is just another variant on > this half-border solution. I don't care either way, but the half-border > solution has been chosen for now. As a new horrible default that is to be forced upon AT LEAST seven thousand users (http://qa.debian.org/popcon.php?package=tmux) starting tomorrow. They will have to cope with it for a couple of months - at least if they are dependent on stable releases. That's a really good idea. >> - mouse wheel scrolling emulation (yes, it is ready since long) >> - fix of unwanted side effects of new osdep_get_cwd() behaviour > > What is this new osdep_get_cwd() change and how has it affectef your > scrolling wheel patch? Never said there was a connection between them. The new osdep_get_cwd() code only gets the HOME dir for some programs (like the "less" pager), while the old one will get the real current dir just fine. Wanted to fix that by falling back to the old behaviour in these cases but have to test until satisfied first. Anyway, got to run. Real life™ troubles to care for. #Best Regards!Marcel. ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
