Shared strings are stored in a hashtable with pointer for keys (values are not
used).
The key has a reference count + the string.
The initial reference count is set to 1 and is incremented each time the same
string is asked.
When removing a shared string, the reference count is decremented.
If it becomes 0, then the shared string is removed from the hashtable (and then
the string is really destroyed).
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.
The key hash has been changed from unsigned int to unsigned long, and now the
callback can return any value (not only between 0 and size-1), the modulo is
computed after the call to the callback by the hashtable functions.
Functions hashtable_set and hashtable_set_with_size were returning 1 if OK,
0 if error. Now they return pointer to hashtable item, or NULL if error.
The hashtable is created on first call to eval_expression with pointers == NULL.
On next calls, the hashtable is cleared, then used again.
The hashtable is freed on exit.
A symbolic link weechat-curses -> weechat is now created (by both cmake and
configure), so that the /upgrade will work from an old version.
However, if you upgrade from an old version, it is recommended to force the use
of the new binary name with the command: `/upgrade /path/to/weechat` (replace
the path accordingly).
A regression was introduced by commit bee56c3b7fa6ef0ce820a8f0a7e5e51b95aa3fab
(/window scroll_beyond_end).
Scenario to reproduce the problem, for example on an IRC channel with a long
history (more than two pages):
/window page_up
/window page_down
<type some text and send to channel>
It will display -MORE(1)- instead of automatically scrolling to bottom of
buffer.
If user gives no passphrase (for example one space when prompted), the encrypted
data read in sec.conf will be stored in a separate hashtable.
While this hashtable contains something, it is not allowed to do any operation
on passphrase or secured data (and it is not allowed to reload sec.conf).
The user can decrypt data with /secure decrypt <passphrase>.
