Hi Nicholas, *, On 01/18/2015 09:54 PM, Nicholas Marriott wrote: > We're not adding an option for every obscure little behaviour change, we > would quickly be coming down with options and there are already far too > many. Options are not free, they are a maintenance burden and a steeper > learning curve for new users. Sounds very reasonable, even though I'm not too happy with the verdict in this particular case. > > So, we pick one behaviour. For vi mode, generally the policy is to > follow vi. Why does it make sense for vi to copy newlines and not for > tmux? Because pasting a single line in vi does not (if it's a command line for example) automatically execute it. BTW vi very well distinguishes between LINE and CHAR mode. While the first one copies newlines, too, the latter does not (as their names suggest). > Isn't it a surprise for vi users if it doesn't? It's not so much the vi user in me who is suprised it's rather the tmux and (former) GNU screen user. The behavior changed (for reasons that I very well understand after Balasz explained). However, for this one particular case, copying the whole line, in my opinion it makes more sense to omit the trailing newline. I've changed my mind in this respect, so my original patch is rubbish anyways. I think more of excluding copy-line from the copy-newline-at-EOL policy. You might object that it's neither consistent nor vi-compatible, but I think it's what one would expect from a copy-line command. > > This is tricky for me because I don't care about vi mode, but the person > who sent this change wanted it and yours is the only comment on it in 7 > months, so I'm not inclined to revert it immediately. Yes, Balasz made it clear why he wanted the behavior changed, and it's generally a good idea (I didn't see the original purpose of the patch, the commit somewhat lacked this informtion, so I'm glad Balasz explained it). For the other part of your argument, the missing comments in 7 months. It depends on a couple of facts: - how many users utilize this particular copy-line command - how many users complain about it (many might just fear the effort to complain [pardon my English]) - and lastly and most importantly (this renders true for *all* Debian based Linuxes, for BSDs I cannot tell): they are all shipped with tmux <= 1.9. So it's very likely the haven't even noticed yet. > Perhaps some other vi users will weigh in. Hopefully.
To sum it up: I have somewhat changed my mind. I think reverting Balasz's patch doesn't make sense. Neither does my first patch because it breaks what Balasz's patch fixed. So I'm trying to convince you to compromise here: Any chance you/we could exclude copy-line from the vi-inherent 'copy-newline-at-EOL' policy? I'd happily try and hack the changes if they had any chance of getting it upstream. Cheers, Thomas > > > On Sun, Jan 18, 2015 at 09:09:40PM +0100, Thomas Egerer wrote: >> Hi Nicholas, >> >> On 01/18/2015 09:16 AM, Nicholas Marriott wrote: >>> Hi >>> >>> There is no way we are adding an option for this, sorry. >> Any explaination why? 'Sorry' really does not help me here. >> The newly introduced behavior makes the otherwise great tool >> less usable for the idea of being completely compatible with >> what you cannot be completely compatible with. I don't >> understand why you're ruling out to add the patch (because >> you didn't tell it). It would not harm anyone, and the >> default setting wouldn't change the default behavior of >> tmux at all. It would however free people (and it's not >> just me, trust me), from the burdon of rebasing the patch >> again and again on top of each new tmux release. >> >>> Does the current behaviour match vi(1)? >> This is like comparing pears and apples. vi(1) is an editor >> while tmux is a terminal multiplexer with the option of >> copying text to buffers. It makes great sense to copy newlines >> within a block of selected text. It does not make sense to >> copy a newline at the end of a line when copying only a >> *single* line or at the end of a selection (even if that >> is what vi does). >> >> Thomas ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
