| Age | Commit message (Collapse) | Author |
|---|
|
This pointer is the first argument received by callbacks, and the
existing argument "data" is now automatically freed by WeeChat when the
object containing the callback is removed.
With this new pointer, the linked list of callbacks in scripts has been
removed. This will improve speed of scripts (using a lot of hooks),
reduce memory used by scripts and reduce time to unload scripts.
Following functions are affected in the C API:
* exec_on_files
* config_new
* config_new_section
* config_new_option
* hook_command
* hook_command_run
* hook_timer
* hook_fd
* hook_process
* hook_process_hashtable
* hook_connect
* hook_print
* hook_signal
* hook_hsignal
* hook_config
* hook_completion
* hook_modifier
* hook_info
* hook_info_hashtable
* hook_infolist
* hook_hdata
* hook_focus
* unhook_all_plugin
* buffer_new
* bar_item_new
* upgrade_new
* upgrade_read
|
|
windows functions
|
|
|
|
|
|
|
|
set to "merged" (closes #199)
|
|
A flag "closing" has been added in buffers. It is set to 1 when the buffer
is closing, and then no more printf is allowed in the buffer (a message
printed on relay buffer was causing a crash when it is closed).
|
|
|
|
|
|
|
|
|
|
remove a buffer from hotlist)
|
|
|
|
merged buffer is zoomed) (task #12845)
There was a bug with "num_displayed" in buffers when they are merged and
that one buffer is zoomed: now the num_displayed is > 0 for the active buffer,
and it is set to 0 for all merged non-active buffers (only in case of zoom).
A variable "zoomed" has been added in buffers to know if a buffer with this
number is zoomed or not (possibly another buffer).
|
|
|
|
in function buffer_search (bug #34318)
|
|
|
|
some buffers in layout
Now when a layout is applied, the buffers in layout are inserted/sorted
first in the new list. Then the other buffers (not in layout) are added
after this loop, and then they are added after all layout buffers.
|
|
This commit fixes a problem when computing the value of "num_displayed"
in all buffers. For merged buffers (with same number), the num_displayed
of each merged buffer must be incremented (and not only the current
active buffer).
|
|
|
|
created and merged
|
|
irc.look.highlight_tags to irc.look.highlight_tags_restrict
The buffer property "highlight_tags" is renamed to "highlight_tags_restrict".
New behavior for buffer property "highlight_tags": force highlight on tags.
Option irc.look.highlight_tags is renamed to irc.look.highlight_tags_restrict.
|
|
and buffer property "highlight_tags"
The logical "and" is made with the separator "+".
Example: "irc_notice+nick_toto,nick_test"
will match a notice from nick "toto" or any message from nick "test".
|
|
|
|
|
|
|
|
The value of option can be:
- "end": buffer is added after the end of list (number = last number + 1)
- "first_gap": buffer is added at first number available in the list
(after the end of list if no number is available)
|
|
in specific buffers
|
|
The problem happened because we used a pointer to a
"struct t_gui_buffer_visited" for the switch to another buffer,
when the buffer is closed. This is executed in all windows displaying
the buffer, but on each switch to buffer, the visited buffers are
updated and therefore the address can change. The pointer becomes
invalid, and WeeChat still uses it on next windows for the buffer
switch.
It happened rarely because the visited buffer is freed and allocated
immediately after, so the address is often the same in memory.
Thanks to silverd for the tests on OS X to track the problem.
|
|
between 1 and INT_MAX - 10000)
|
|
|
|
Now the bar item "buffer_count" displays the number of opened buffers
(each merged buffer counts 1).
|
|
New option: weechat.look.buffer_auto_renumber, boolean which is on by
default, so the behavior is the same: no gap is allowed in numbers,
they start at number 1 and they are auto-renumbered after each command
like /buffer move, /buffer merge, ...
A new option "renumber" has been added in command /buffer, to renumber
a range of buffers (or all).
Changes when the option weechat.look.buffer_auto_renumber is off:
- command "/buffer move":
- the current number will be left free for use, and the
target number can be any number >= 1 (possibly higher than the
current last buffer number)
- the value can be "-" (which moves the buffer to number 1)
or "+" (which moves the buffer to the end, ie last number + 1)
- command "/buffer swap":
- now the buffers are swapped in the list without being "moved"
- comand "/buffer [+/-]N":
- it is now working with gaps in buffer numbers
- command "/buffer merge":
- it can now merge a group of merged buffers into another buffer
(or buffers merged themselves)
- layout can restore buffer numbers with gaps in numbers
|
|
in buffer_set
This reverts commits 14cf7bd20fb3f00b18343464c175a0c4e3556149 and
262dff4b87ebf14a11fe83899fe168bc5a72ffe6.
The initial fix was for a problem with irc autojoin and layout: the
current window has not appropriate buffer (as defined in layout) if it
is not the latest channel in "autojoin" option.
So the way to fix this problem is to set the value of option
irc.look.buffer_switch_autojoin to off.
|
|
irc.look.buffer_switch_autojoin is on
|
|
a new search, select where to search (messages/prefixes)
Key changed in search context:
- ctrl+"r": switch search type: string/regex
New keys in search context:
- alt+"c": case (in)sensitive search
- tab: search in messages/prefixes/both
|
|
buffers with lot of lines)
The update of variables "buffer_max_length" and "prefix_max_length" in struct
t_gui_lines is now delayed and made during the main refresh (in main loop).
For a buffer with 50K lines, it is up to 3300 times faster to clear/close it.
For a buffer with 4096 lines (default limit), it is up to 120 times faster.
|
|
completion when command line is updated
|
|
The item is now cleared after any action that is changing content of command
line and after switch of buffer.
|
|
|
|
|
|
|
|
This was causing a bug in relay plugin (weechat protocol): when a buffer was
closed, local variables were removed after buffer name, and when signal is sent
to client, the buffer name was wrong (already freed).
|
|
A size of 32 will use a little more memory but will reduce collisions in key
hashs, and then length of linked lists inside hash structure (faster search in
hashtable).
|
|
|
|
|
|
|
|
|
|
to it (bug #37593)
|
|
|
