| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
Key Alt+K (upper K) is removed as well as commands `/input grab_raw_key` and
`/input grab_raw_key_command`.
|
|
|
|
|
|
They are used in completion of commands `/filter disable` and
`/filter enable`.
|
|
|
|
plugins, add info "auto_load_scripts"
This fixes an issue with IRC URL given on command line when it starts with
`ircs://` or `irc6://`: the server is not created at all (only `irc://` works
fine).
|
|
|
|
|
|
no spaces
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).
|
|
`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).
|
|
#1820)
|
|
weechat.color.chat_status_enabled (issue #1820)
|
|
|
|
Default values changed:
- weechat.color.chat_delimiters: green -> 22
- weechat.color.chat_highlight_bg: magenta -> 124
- weechat.color.chat_inactive_window: default -> 240
- weechat.color.chat_nick_colors: add many colors
- weechat.color.chat_nick_offline: default -> 242
- weechat.color.chat_nick_offline_highlight_bg: blue -> 17
- weechat.color.chat_prefix_buffer: brown -> 180
- weechat.color.emphasized_bg: magenta -> 54
- weechat.color.nicklist_away: cyan -> 240
|
|
Default values changed:
- weechat.look.prefix_suffix: "|" -> "│"
- weechat.color.chat_prefix_suffix: green -> 24
|
|
Default value changed:
- weechat.color.separator: blue -> 236
|
|
Default value of option weechat.color.status_name_tls is set to white instead
of lightgreen.
Now all servers/channels connected with TLS are white, and those without TLS
are lightmagenta.
|
|
available in terminal (issue #1920)
|
|
|
|
This reverts commit 2b7f7453692d2325e27e2464e4796b150c708aa4.
Parameters removed are still used in scripts, and it's OK to keep them for a
while.
|
|
Parameters removed:
- jump_smart
- jump_last_buffer
- jump_last_buffer_displayed
- jump_previously_visited_buffer
- jump_next_visited_buffer
- hotlist_clear
- hotlist_remove_buffer
- hotlist_restore_buffer
- hotlist_restore_all
- set_unread_current_buffer
- set_unread
- switch_active_buffer
- switch_active_buffer_previous
- zoom_merged_buffer
|
|
to v2
|
|
|
|
Ref: https://github.com/weechat/weechat-relay/pull/3
|
|
|
|
weechat.color.status_name_tls (issue #1903)
|
|
|
|
|
|
|
|
|
|
|
|
docs (closes #1901)
|
|
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`).
|
|
|
|
|
|
parameter `--doc-gen`
Changes:
- build of doc now requires weechat-headless, translations and all plugins
- convert docgen.py to C
- remove `autogen_*` files from repository
- add command line parameter `--doc-gen` in `weechat-headless` to build
autogen files
- build .mo files with directories like the installed ones
(eg: "<lang>/LC_MESSAGES/weechat.mo")
- remove javascript chapter from user's guide
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
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.
|
|
This was caused by commit 66571a0b634ef28307f6d6ceef1ba29c091ca524.
|
|
|
|
|
