New key: alt+"!", to swith to bare display (same key to come back to
standard display).
New options:
- weechat.look.bare_display_exit_on_input (default: on): by default
any changes in input will return to standard display
- weechat.look.bare_display_time_format (default: "%H:%M"): the format
of time used in bare display.
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).
The bug is when all buffer lines are unread (so "last_read_line" pointer
is NULL), and that the option weechat.look.read_marker_always_show is on.
The read marker was displayed at bottom after switch to the buffer.
Thanks to Nils Görs.
On OpenBSD, the variable "tv_sec" in struct timeval has type "long"
(type "time_t" under Linux).
So we need to copy this value to a temporary variable before using its
pointer with function localtime().
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.
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)
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.
Sebastien Helleu