[PATCH] Add option to disable copying newline at EOL for vi(1) mode

[Thomas Egerer]

Signed-off-by: Thomas Egerer <hakke[underscore]double-oh-seven[at]gmx.de>
---
Hello *,

the changes introduced in git-commit
00ac1af Copy newline when at EOL in vi(1) mode, from Balazs Kezes.
have been driving me up and down the wall during the last couple of
days. I often use the 'copy-line' command to copy command line
statements. When such a buffer is then pasted the statement is
immediately executed. This is very unpleasant.
It might be just me, but if you too think the attached patch is worth
applying to your repository, I would be thrilled if you did.

Regards,
Thomas

options-table.c | 5 +++++
tmux.1 | 7 +++++++
window-copy.c | 3 ++-
3 files changed, 14 insertions(+), 1 deletion(-)

[Nicholas Marriott]

Hi

There is no way we are adding an option for this, sorry. Does the
current behaviour match vi(1)?

Post by Thomas Egerer
Signed-off-by: Thomas Egerer <hakke[underscore]double-oh-seven[at]gmx.de>
---
Hello *,
the changes introduced in git-commit
00ac1af Copy newline when at EOL in vi(1) mode, from Balazs Kezes.
have been driving me up and down the wall during the last couple of
days. I often use the 'copy-line' command to copy command line
statements. When such a buffer is then pasted the statement is
immediately executed. This is very unpleasant.
It might be just me, but if you too think the attached patch is worth
applying to your repository, I would be thrilled if you did.
Regards,
Thomas
options-table.c | 5 +++++
tmux.1 | 7 +++++++
window-copy.c | 3 ++-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/options-table.c b/options-table.c
index 2b12324..c4731f5 100644
--- a/options-table.c
+++ b/options-table.c
@@ -556,6 +556,11 @@ const struct options_table_entry window_options_table[] = {
.default_num = 1
},
+ { .name = "copy-newline",
+ .type = OPTIONS_TABLE_FLAG,
+ .default_num = 1
+ },
+
{ .name = "force-height",
.type = OPTIONS_TABLE_NUMBER,
.minimum = 0,
diff --git a/tmux.1 b/tmux.1
index a277248..c0d3d9f 100644
--- a/tmux.1
+++ b/tmux.1
@@ -2813,6 +2813,13 @@ Set clock colour.
.Xc
Set clock hour format.
.Pp
+.It Xo Ic copy-newline
+.Op Ic on | off
+.Xc
+With vi key bindings defines whether the last selected newline is copied. The
+default is
+.Ic on .
+.Pp
.It Ic force-height Ar height
.It Ic force-width Ar width
Prevent
diff --git a/window-copy.c b/window-copy.c
index 6447a2d..4050f48 100644
--- a/window-copy.c
+++ b/window-copy.c
@@ -1475,7 +1475,8 @@ window_copy_get_selection(struct window_pane *wp, size_t *len)
free(buf);
return (NULL);
}
- if (keys == MODEKEY_EMACS || lastex <= ey_last)
+ if (keys == MODEKEY_EMACS || lastex <= ey_last ||
+ !options_get_number(&wp->window->options, "copy-newline"))
off -= 1; /* remove final \n (unless at end in vi mode) */
*len = off;
return (buf);
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/tmux-users

[Nicholas Marriott]

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.

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? Isn't it a surprise for vi users if it doesn't?

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. Perhaps some other
vi users will weigh in.

Hi Nicholas,

Post by Nicholas Marriott
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.

Post by Nicholas Marriott
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

[Balazs Kezes]

Post by Nicholas Marriott
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. Perhaps
some other vi users will weigh in.

I wanted it because I haven't found a way to copy a line with its
newline without also copying the next line's first character. You got
either the next character or no newline.

This was especially annoying when I was trying to copy multiple lines.
In such cases I usually expect to have newlines at the end of all lines
but alas there was no way for that in vi mode.

Thomas, could you try the emacs mode? It does exactly the thing you want
albeit with different default keybindings.

[Thomas Egerer]

Post by Balazs Kezes

Post by Nicholas Marriott
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. Perhaps
some other vi users will weigh in.

I wanted it because I haven't found a way to copy a line with its
newline without also copying the next line's first character. You got
either the next character or no newline.

That's true. I didn't notice that before. I could not find it in the
commit message either. I can totally understand your point now. This
is why I'm not convinced about my patch anymore, an exclusion of the
copy-line command would do (but I guess that's out of the question
here...)

Post by Balazs Kezes
This was especially annoying when I was trying to copy multiple lines.
In such cases I usually expect to have newlines at the end of all lines
but alas there was no way for that in vi mode.
Thomas, could you try the emacs mode? It does exactly the thing you want
albeit with different default keybindings.

No offense, but no thank you. HJKL is my lifestyle. I'd rather hack tmux
myself and rebase the patch with each new tmux build I do.

Cheers,
Thomas

[Thomas Egerer]

Hi Nicholas, *,

Post by Nicholas Marriott
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.

Post by Nicholas Marriott
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).

Post by Nicholas Marriott
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.

Post by Nicholas Marriott
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.

Post by Nicholas Marriott
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

Post by Nicholas Marriott

Hi Nicholas,

Post by Nicholas Marriott
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.

Post by Nicholas Marriott
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

[Balazs Kezes]

Post by Thomas Egerer
the changes introduced in git-commit
00ac1af Copy newline when at EOL in vi(1) mode, from Balazs Kezes.
have been driving me up and down the wall during the last couple of
days. I often use the 'copy-line' command to copy command line
statements. When such a buffer is then pasted the statement is
immediately executed. This is very unpleasant.

Hey! Sorry about that. The idea was to make the vi mode just as vim
which does copy the newlines if you yank at the end of line. You could
go back a character (press 'h') before copying. Would that work? Or
maybe using the emacs mode would fit your use case better? It's the
mode-keys option, I believe and that won't copy the last character just
like emacs (but you might need to rebind some keys to get back to the
same state).

Thanks!

[Thomas Egerer]

Hi Balasz, *,

Post by Balazs Kezes

Post by Thomas Egerer
the changes introduced in git-commit
00ac1af Copy newline when at EOL in vi(1) mode, from Balazs Kezes.
have been driving me up and down the wall during the last couple of
days. I often use the 'copy-line' command to copy command line
statements. When such a buffer is then pasted the statement is
immediately executed. This is very unpleasant.

Hey! Sorry about that. The idea was to make the vi mode just as vim
which does copy the newlines if you yank at the end of line. You could
go back a character (press 'h') before copying. Would that work?

Unfortunately the copy-line mode does not give this option. It
preselects the whole line from start to end (including \n in vi mode)
and copies it to a buffer.

Post by Balazs Kezes
Or
maybe using the emacs mode would fit your use case better? It's the
mode-keys option, I believe and that won't copy the last character just
like emacs (but you might need to rebind some keys to get back to the
same state).

Never mind, I think your patch is fine. So I'm a bit in a predicament
here, I can understand Nicholas as well as you. However in my opinion
copy-line is still broken. I'm not very confident Nicholas will consent
to exclude it from the 'copy-newline-at-EOL' policy. When worse comes to
worse I will somehow manage to maintain a local patch on top of my most
recent tmux build. Git makes these things rather easy.

Post by Balazs Kezes
Thanks!

Cheers,
Thomas

[Balazs Kezes]

Post by Thomas Egerer
Unfortunately the copy-line mode does not give this option. It
preselects the whole line from start to end (including \n in vi mode)
and copies it to a buffer.

I actually did not know about this feature! It does sound quite nice and
yes, I get your point now: if that also copies the newline, then that's
annoying. I'm happy not having newline there for this command.

Do you have a patch around? I'm thinking something along the lines of

case MODEKEYCOPY_COPYLINE:
window_copy_cursor_start_of_line(wp);
/* FALLTHROUGH */
case MODEKEYCOPY_COPYENDOFLINE:
window_copy_start_selection(wp);
for (; np > 1; np--)
window_copy_cursor_down(wp, 0);
+ if (/*emacs mode*/) {
- window_copy_cursor_end_of_line(wp);
+ window_copy_cursor_end_of_line(wp);
+ } else if (/*vi mode*/) {
+ /*copy without the newline*/
+ }
window_copy_redraw_screen(wp);

Would that work?

[Stroller]

... I often use the 'copy-line' command to copy command line
statements. When such a buffer is then pasted the statement is
immediately executed.

I'm sorry if I'm not understanding exactly what you're doing, but it _sounds like_ you're copying using the command-line / keyboard and pasting with the mouse.

Is it possible the problems you're seeing could be avoided with a different workflow - e.g. retrieving the contents of the buffer with `tmux show-b -b 0` or `tmux save-b -b 0 file.txt`?

For example, if you're using Bash's vi-mode to edit shell commands, you can just press the escape key followed by `v` to open a new text editor window in which to edit your command. You can then read the command from file (`:r file.txt` in vi) or paste with the mouse before editing it - the saved command will be executed when you edit the text editor.
I apologise if this suggestion is unhelpful, but I don't understand how you're pasting if not with the mouse, and I find that a bit incongruous.

Stroller.