Now that pasting text doesn't cause it to be sent immediately, but
rather inserted in the input line, the paste confirmation isn't really
necessary anymore for small pastes. If you paste by mistake you can just
press ctrl-_ to undo it.
Large pastes may cause weechat to hang for a while, so keep the paste
confirmation for those.
If you don't use bracketed paste you would still want to keep it at 1,
because it's not detected as a paste otherwise, but as far as I know
basically all terminal emulators support bracketed paste, so I think
it's fine to disable the confirmation by default.
This option existed so that you could edit the last line of a multiline
paste before it was sent. Now that pasting multiple lines don't cause
the lines to be sent immediately anymore, this option isn't useful
anymore since you can always edit pasted text before it's sent.
Since pasting doesn't send the line now, it's more practical to always
remove the final newline so you don't end up with an empty line at the
end of the input buffer.
Fixes a part of #1498
Instead of replacing newline/tabs when paste is started, do it when the
paste is accepted instead. This makes a difference if you paste again
while the paste confirmation is active, where instead of running it
again for each paste, it will now be run for all the text at the end.
For now this doesn't make a practical difference, but the next commit
will remove the final newline when multiple lines are pasted too, which
we only want to do for the final paste.
This makes pasted text appear in the input bar, instead of each line
being sent. This allows you to edit the text before sending it, and it
makes multiline paste supported in buffers with input_multiline on.
It also replaces \r with \n in pasted text because most terminals (e.g.
xterm and urxvt) print lines separated by \r when pasting as if return
was pressed between each line, even though the copied text uses \n. The
text sent to the buffer should use \n, not \r, so we have to replace it.
Note that this only works when bracketed paste is enabled or the paste
confirmation as shown, because non-bracketed paste with no paste
confirmation is not detected as a paste.
Fixes a part of #1498
When in paste pending mode, the bracketed paste escape sequence should
still be interpreted, so that if you paste while in paste pending the
same things as when pasting in normal mode still happens, i.e. the
escape sequence is removed, ctrl-y/n is not interpreted and newline/tabs
are replaced.
When the bar name already exists, the function `bar_new` returns the pointer to
the bar (instead of NULL) and sets the default value for all options with the
values received.
When raw code and alias for a key are both matching, the raw code must always
have higher priority.
This commit fixes this behavior and gives priority to raw code.
Changes:
- add function gui_key_debug_print_key
- change message "no key" by "no key binding"
- remove messages ""insert into input" / "ignored"
- add color for delimiters
Now when fset plugin is loaded, the keys are displayed in fset buffer.
In core commands like /set or /key, the fset plugin is not mentioned as WeeChat
can run without it.
Keys added in mouse context were already hidden, so it makes sense to not
display keys in default context as well.
These keys added by the default plugins are documented anyway.
Trygve Aaberge