This fixes a bug where if you had multiple lines in the input and
pressed ctrl-w when the cursor was after the first word of any line but
the first, it would delete both the word before the cursor and the last
word on the preceding line.
It seemed strange to me to have word_end_offset point to the last
character in the word, rather than the character after the word,
especially now with the word stopping before a newline character which
meant word_end_offset would be -1 if there was no characters before the
newline character.
The new rendering of multiline lines had some issues with colors at
certain positions not being applied. The color would not be applied if
the color code was at either of these positions:
- At the start of a line after a newline character
- At the end of a line after a space and before a newline character
- At a line by itself before a newline character
The way I had done it by considering newline characters as a word in
gui_chat_get_word_info with a variable specifying that it's newline
characters became messy and didn't really make sense, so rather than
doing this, I changed gui_chat_get_word_info to stop before the first
newline character. That way, we can just check if we are at a newline
character at the start of the loop, and don't need any more special
handling.
Fixes#1928
The status PRIVMSG and NOTICE are now displayed the same way for outgoing and
received messages:
Msg(alice) -> @#test: message for ops
Notice(alice) -> @#test: notice for ops
And any message like this is displayed with these tags if the nick is self
nick (case of a bouncer or if capability "echo-message" is enabled):
"self_msg", "notify_none", "no_highlight".
For example typing this on core buffer:
/t1
/t2
was not executing the two commands but sent the text to the buffer instead.
This is because WeeChat thinks it's a path, and the newline should indicate
it's not (like a space before the next slash: "/t1 /t2" is a command, not a
path, but "/t1/t2" is considered a path).
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).
Trygve Aaberge