| Age | Commit message (Collapse) | Author |
|---|
|
`command_options` when input_multiline is set to 0
The API functions `command` and `command_options` (when `split_newline` = 0,
which is the default value) don't split on newline and then the first line is
executed and the subsequent lines (after "\n") are ignored.
There are no changes when the input has multiple lines filled by the user: the
split is done and multiple commands are executed (for example if the user is
pasting multiple commands to execute).
|
|
weechat.color.chat_status_enabled (issue #1820)
|
|
input_multiline is not set in buffer
|
|
set in buffer
|
|
Default values changed:
- weechat.bar.status.color_bg: blue -> 234
- weechat.bar.status.color_bg_inactive: darkgray -> 232
- weechat.bar.title.color_bg: blue -> 234
- weechat.bar.title.color_bg_inactive: darkgray -> 232
|
|
available in terminal (issue #1920)
|
|
switch to core buffer is performed (closes #1917)
|
|
If you have a chat line with multiple lines that were scrolled so that
part of it is rendered at the bottom of the chat area, and part of it
falls below the chat area, there was a bug where the prefix_suffix would
be displayed at the end of the last line.
Looks like this happens because the gui_chat_display_prefix_suffix is
called for the line below the last line displayed in the chat area. So
we have to add a check for this so we don't add the prefix_suffix. This
check is copied from gui_chat_display_word which checks for the same.
Fixes #1912
|
|
|
|
Fixes #1913
|
|
This contains the single line that you focused on, like _chat_word
contains the word that you focused on. This will be equal to
_chat_line_message if the chat line only contains a single line, but if
the chat line has multiple lines, _chat_line_message will contain all of
them, but _chat_focused_line will only contain the single line that was
focused.
Fixes part of #1913
|
|
(stterm) (closes #1882)
|
|
input_multiline is not set in buffer
|
|
except if buffer has no lines
|
|
If we have chat lines with multiple lines in buffers without
input_multiline set, there can be an issue if a trigger is run on that
line. If the trigger runs a command which includes the message, then the
command is split (since input_multiline isn't set), and if any of the
lines in the message starts with a command, that command is executed.
To prevent this, only avoid splitting on newlines in printf if
input_multiline is set, so only such buffers can have chat lines with
newline characters.
See https://github.com/weechat/weechat/pull/1909 for more details.
|
|
With support for rendering newline characters as new lines, we don't
need to split the message on newline characters anymore in
printf_date_tags. This allows you to print a line with multiple lines.
|
|
If a chat line message contains a newline character (\n) it was
previously rendered as J with reverse video. This commit makes it
render as an actual newline instead, so messages with multiple lines
become supported.
The rendering is fixed in normal mode as well as bare mode both when
scrolled to the bottom and when scrolled up (which is different code
paths). Focus events has also been updated to support this (except for
_chat_line_y which returns -1 for all lines, but the docs says this
variable is only for buffers with free content).
Currently, the only way to include a \n in a chat line message is with
hdata_update because printf splits on \n and creates multiple separate
lines, but hopefully either printf can be changed to not split on \n, or
a new command which doesn't split can be added.
|
|
|
|
|
|
|
|
It seems no terminal return such codes any more for pgup/pgdn, and `meta-[I` is
conflicting with the xterm terminal "focus in" key code.
The keys are also removed from config when converting old keys, but only if
they are bound to the default command (`/window page_up` for `meta2-I` and
`/window page_down` for `meta2-G`).
|
|
This does the same as the lead_linebreak option in multiline.pl. That
is, when the input contains more than one line, the first line will be
displayed beneath the previous items in the bar. This is practical
because all the lines in the input will be aligned.
Related to #1498
|
|
|
|
and `right` (issue #1503)
|
|
#1503)
|
|
This changes the commands delete_beginning_of_line, delete_end_of_line,
delete_line, move_beginning_of_line and move_end_of_line to operate on
the current line instead of the whole input. The commands
delete_beginning_of_input, delete_end_of_input, delete_input,
move_beginning_of_input and move_end_of_input are added with the
previous implementations that the line commands had.
Additionally, the commands move_previous_line and move_next_line are
added which moves the cursor to the previous/next line and keeps the
horizontal position in the line.
The meta-r key is changed from delete_line to delete_input to keep the
behavior, and because you probably want to delete the whole input more
often than the line. The meta-R key is added for delete_line.
The home, end, ctrl-u and ctrl-k keys are kept to the same commands,
which means that they change behaviour. This is because having them
operate on the line is consistent with other applications (vim, zsh),
and I also think it's more practical.
These new bindings are added:
shift-home: /input move_beginning_of_input
shift-end: /input move_end_of_input
shift-up: /input move_previous_line
shift-down: /input move_next_line
meta-R: /input delete_line
meta-ctrl-u: /input delete_beginning_of_input
meta-ctrl-k: /input delete_end_of_input
Relates to #1498
|
|
The previous commit e385eec1d6116b8c87889fc1d829aa1c5192156f fixed default
value for bar added by plugins and option "items" in all bars.
This commit fixes the default value of all bar options.
|
|
|
|
Since pastes are now inserted into the input instead of sent, and blank
lines are preserved in the input, they should now be counted too.
|
|
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.
|
|
key_name_alias are the same
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(closes #1895)
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
